Here's a list of workarounds (not solutions) which can help to mitigate
the issue:
1. Use the following in your proftpd.conf:
<Global>
RootRevoke on
</Global>
This causes proftpd to drop all root privileges after the client has
authenticated. The "Roaring Beast" exploit requires root privs for
attaching to a root-running process on the FreeBSD box; by using
"RootRevoke on", you prevent the exploit from attaching to that root-owned
process. (Root privs are kept in order to satisfy the RFC-mandated
requirement to use L-1 as the source port for an active data transfer,
where L is the control port. Using "RootRevoke on" will cause active data
transfers not to work, if your proftpd uses a control port below 1025.)
2. Try to prevent the necessary exploit directories from being created via
FTP, by using <Directory> and <Limit> sections, i.e.:
# For non-<Anonymous> chrooted logins, use this.
#
# NOTE: it ASSUMES that you are using "DefaultRoot ~" to chroot users to
# their respective home directories. If you use a different chroot
# directory, replace '~' with that chroot directory in the configs
# below.
<Directory ~/etc>
<Limit ALL>
DenyAll
</Limit>
</Directory>
<Directory ~/lib>
<Limit ALL>
DenyAll
</Limit>
</Directory>
# And for <Anonymous> logins where uploads are allowed, use:
<Anonymous ...>
...
<Directory etc>
<Limit ALL>
DenyAll
</Limit>
</Directory>
<Directory lib>
<Limit ALL>
DenyAll
</Limit>
</Directory>
</Anonymous>
3. I'll be working on a module which takes a configurable list of files;
the module will periodically check for the existence of these files (e.g.
with the chrooted session) and if present, delete them.
For the benefit of others with this issue, please report back to the list
if you use one (or both) of the above configurations, and how well it
appears to be working. I will keep the list apprised of progress on the
file-deleting module.
TJ
It won't affect you current FTP users/settings, unless 
