Here are the usual tricks used to escape a chroot environment.
There are two ways one may escape from a chroot environment. One is to setup a block device special file, open it with some user-land file system browser. At this point, you are bypassing both the chroot restriction and all file system access control.
This does not work on a vserver because the special device are not created in /dev and the CAP_SYS_MKNOD capability is disabled. Even root can't create special files in a vserver.
So this hole is plugged.
This is a trick to exploit a flaw in the chroot() system call. The system call is changing the logical root directory for the calling process but does not change the current working directory of the process. So the current working directory is (generally) left behind the new root directory.
The /usr/sbin/chroot command takes care of this flaw by changing the working directory, but the system call does not do that.
So if you process has now a working directory behind (out of scope) the new root, it is allow to change it up to the real root by doing multiple chdir ("..") system call. The process kind of escape from the kernel radar.
This is a common bug found on Unix chroot() and Linux had this flaw also. Kernel 2.4.13 has been tested and does not show this problem.