Remote code execution vulnerability in ProFTPD
| From: | John Morrissey <jwm-AT-proftpd.org> | |
| To: | proftpd-announce-AT-proftpd.org | |
| Subject: | CVE-2006-5815: remote code execution in ProFTPD | |
| Date: | Mon, 27 Nov 2006 11:37:30 -0500 | |
| Cc: | proftpd-users-AT-proftpd.org, proftpd-devel-AT-proftpd.org, bugtraq-AT-securityfocus.com | 
======= Summary ======= On 6 November 2006, Evgeny Legerov <admin@gleg.net> posted to BUGTRAQ[1], announcing his commercial VulnDisco Pack for Metasploit 2.7[2]. One of the included exploits, vd_proftpd.pm, takes advantage of an off-by-one string manipulation flaw in ProFTPD's sreplace() function to allow a remote attacker to execute arbitrary code. This vulnerabillity, identified as CVE-2006-5815[3], is believed to affect all versions of ProFTPD up to and including 1.3.0, but exploitability has only been demonstrated with version 1.3.0rc3. The demonstrated exploit relies on write access via FTP for exploitability, but other attack vectors may make exploitation of a read-only FTP server possible. This vulnerability has been patched[4] in the latest release of ProFTPD, 1.3.0a, which is available from the ProFTPD web site, http://www.proftpd.org/. Mitigation techniques have also been developed for use until a patched version can be installed. ======== Timeline ======== 10 November - security@proftpd.org receives a message from a ProFTPD user inquiring about a fix for the vulnerability announced in GLEG's product. 10 November - ProFTPD core team attempts contact with admin@gleg.net. 15 November - Second contact attempt with admin@gleg.net. 16 November - Contact established, vulnerability details transferred. 20 November - Disclosure date coordinated. 27 November - Coordinated disclosure. Given the Thanksgiving holiday, the ProFTPD core team chose to perform a coordinated disclosure the following Monday, to allow affected users and vendors ample opportunity to perform patching operations. Unfortunately, erroneous information on the location and nature of this flaw has disseminated from unofficial sources. Some vendors have already released patches that attempt to address CVE-2006-5815 based on reports that a bug in ProFTPD's CommandBufferSize processing is its cause. To the best of the core team's knowledge, the CommandBufferSize bug in ProFTPD is not exploitable. Vendors are welcomed and encouraged to contact security@proftpd.org to exchange information on announced vulnerabilities, and we endeavor to work to the best of our abilities with those contacting the core team. Given that we had no information about this vulnerability until several days after it was published and a CVE issued, we attempted to address it to the best of our abilities. Constructive criticism is welcome on how to better handle similar situations should they arise in the future. ========== Mitigation ========== Some users may not be able to immediately patch their ProFTPD installations. Until they are able to install a patched version, the following steps can mitigate the impact of this flaw: - Remove DisplayConnect, DisplayLogin, DisplayChdir, DisplayFirstChdir, DisplayFileTransfer, AccessDenyMsg, and WrapDenyMsg directives from your ProFTPD configuration. - Avoid using variable substitutions/magic cookies/%-style escapes in /etc/shutmsg, when specifying a warning message with the ftpshut(8) command, or in RewriteRule directives. - Add a DenyFilter directive to your configuration to limit FTP command arguments to only characters that you require. For example: 'DenyFilter [^A-Za-z0-9_.-]' limits FTP command arguments (such as filenames) to alphanumeric characters, the underscore, period, and dash. [1] http://seclists.org/bugtraq/2006/Nov/0094.html [2] http://gleg.net/vulndisco_meta.shtml [3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5815 [4] http://proftp.cvs.sourceforge.net/proftp/proftpd/src/supp...
      Posted Nov 28, 2006 16:34 UTC (Tue)
                               by arjan (subscriber, #36785)
                              [Link] (6 responses)
       
 
      
           
     
    
      Posted Nov 28, 2006 16:57 UTC (Tue)
                               by bronson (subscriber, #4806)
                              [Link] (4 responses)
       
Actually, it looks like Edgy has SSP already...  https://launchpad.net/distros/ubuntu/+spec/gcc-ssp 
     
    
      Posted Nov 28, 2006 18:25 UTC (Tue)
                               by danpb (subscriber, #4831)
                              [Link] (1 responses)
       
http://people.redhat.com/drepper/nonselsec.pdf 
ProFTPD in RHEL is also constrained by SELinux policy. Be interesting to know just which (if any?) of these countermeasures would stop the exploit. 
      
           
     
    
      Posted Nov 29, 2006 10:57 UTC (Wed)
                               by drag (guest, #31333)
                              [Link] 
       
     
      Posted Nov 29, 2006 10:51 UTC (Wed)
                               by arjan (subscriber, #36785)
                              [Link] 
       
     
      Posted Nov 29, 2006 13:53 UTC (Wed)
                               by skx (subscriber, #14652)
                              [Link] 
       Most 2.6.x kernels include randomization these days, unless you explicitly disable it with: 
     
      Posted Nov 29, 2006 13:39 UTC (Wed)
                               by PaXTeam (guest, #24616)
                              [Link] 
       
     
      Posted Nov 28, 2006 17:03 UTC (Tue)
                               by stevenj (guest, #421)
                              [Link] (1 responses)
       
     
    
      Posted Jan 11, 2007 15:41 UTC (Thu)
                               by ORF.at (guest, #18855)
                              [Link] 
       
     
      Posted Nov 28, 2006 18:33 UTC (Tue)
                               by Dom2 (guest, #458)
                              [Link] (1 responses)
       
     
    
      Posted Dec 2, 2006 11:34 UTC (Sat)
                               by Wills (guest, #1813)
                              [Link] 
       
     
      Posted Nov 28, 2006 19:31 UTC (Tue)
                               by ballombe (subscriber, #9523)
                              [Link] (1 responses)
       
I guess it makes the vulnerability less serious than if it could be expoited by a script kiddy close to you. 
     
    
      Posted Nov 28, 2006 19:33 UTC (Tue)
                               by corbet (editor, #1)
                              [Link] 
       
     
      Posted Nov 28, 2006 21:44 UTC (Tue)
                               by job (guest, #670)
                              [Link] (1 responses)
       
     
    
      Posted Nov 29, 2006 10:13 UTC (Wed)
                               by k8to (guest, #15413)
                              [Link] 
       
     
    
      I wonder if this is actually exploitable on a modern linux distro (eg one with non-executable stack/heap, randomization, glibc internal checks and even compiler assisted bufferoverflow checks such as -fstack-protector and -D_FORTIFY_SOURCE=2) .....Remote code execution vulnerability in ProFTPD
      
      But are there any distros that ship with all that turned on?  Especially something based on Debian/Ubuntu.Remote code execution vulnerability in ProFTPD
      
      
          
      Both RHEL & Fedora have had non-executable stack/heap, randomization, glibc internal checks for a couple of releases now. Most recently Fedora Core 5 & 6 and RHEL-5 have the -fstack-protector and -D_FORTIFY_SOURCE=2 bits too. There's more info here....Remote code execution vulnerability in ProFTPD
      
http://people.redhat.com/drepper/defprogramming.pdf
      I'd hope that Redhat/Fedora people have this stuff turned on.. especially since they are the ones largely responsable for getting it into GCC officially in the first place! Remote code execution vulnerability in ProFTPD
      
(after re-working the pre-existing propolice stuff)
      
          
      Both Fedora and openSUSE have this since quite a while, as do the enterprise editions of those distros....Remote code execution vulnerability in ProFTPD
      
      
          Remote code execution vulnerability in ProFTPD
      
sysctl -w kernel.randomize_va_space=0
      
          
      if you're not familiar with the bug in question, this might help: http://marc.theaimsgroup.com./?l=dailydave&m=11646873...Remote code execution vulnerability in ProFTPD
      
      
          
      The recommended DenyFilter should probably be
DenyFilter fix
      
   DenyFilter [^/A-Za-z0-9_.-]
Without "/", it's hard to use most ftp servers.
      
          
      Also "," is very important. e.g. for the PORT command (PORT   DenyFilter fix
      
192,168,0,15,183,38").    
 
      
          
      ProFTPD -- the new wu-ftpd!Remote code execution vulnerability in ProFTPD
      
      
          Remote code execution vulnerability in ProFTPD
      ProFTPD -- the new wu-ftpd!
Ironically, security was one of the main reasons for writing proftpd, so said its author:
Why yet another FTP daemon?
That was in 1998 for proftpd-1.0.3 which came with more than one fully functioning remote code-execution vulnerability. Some things never change.
      
          
   ProFTPD grew out of the desire to have a secure and configurable FTP
   server, and out of a significant admiration of the [3]Apache web
   server. There are currently a very limited number of FTP servers
   running on unix (or unix-like) hosts. The most commonly used server is
   probably wu-ftpd. While wu-ftpd provides excellent performance and is
   generally a good product, it lacks numerous features found in newer
   Win32 FTP servers, and has a poor security history.
      The advisory say 'remote attacker' but the LWN header says 'remote hacker'.remote hacker
      
      
          
      Weird, I normally try very hard to avoid using "hacker" in that way.  First task of the day, I guess; the coffee had not yet taken effect.  I've changed the blurb.
      
          remote hacker
      
      Anyone still using proftpd probably should know better. There are great replacements in vsftpd (simple, probably most secure) and pureftpd (which is featureful).Remote code execution vulnerability in ProFTPD
      
      
          
      Thanks!  I had forgotten that what I am actually running is pureftpd, and not proftpd.  It is so long since I thought about it.  I was briefly in a panic trying to figure out how to deploy this version not currently packaged for my distribution.Remote code execution vulnerability in ProFTPD
      
      
          
 
           