The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
In order to use the
chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within
/lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real
/lib directories on the system -- but within the
chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary
/etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
/lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such
/lib directories when chrooted, to mitigate such attacks.