Either I didn't understand your point, or possibly you didn't follow the
problem.

The vulnerability in question happens when wget tries to get a file with
ftp, named for example "file", and the (rogue) ftp server instead returning
a file named "../../../../../../../../etc/passwd" or similar.

In windows beside that we should also check if the returned filename is (for
example) c:/winnt/calc.exe or c:\winnt\calc.exe which would be interpreted
as a relative directory in unix (no harm, isn't checked currently) but is an
absolute directory path in windows (attack possibility).
Similar we need to check if possible rogue filenames like \\some\thing\here
could be harmfull.

This is different from  wget -O \\server\share\dir or similar.

Heiko Herold

-- 
-- PREVINET S.p.A. www.previnet.it
-- Heiko Herold [EMAIL PROTECTED]
-- +39-041-5907073 ph
-- +39-041-5907472 fax

> -----Original Message-----
> From: Winter Christopher [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 28, 2003 8:50 AM
> To: [EMAIL PROTECTED]
> Subject: AW: Win32 binary without FTP vulnerability
> 
> 
> Hello Heiko,
> 
> in that case you'll lose the ability to write to network shares,
> which don't have a ':' but normally a '/' in that place.
> 
> Regards,
> 
> Christopher
> 
> -----Ursprüngliche Nachricht-----
> Von: Herold Heiko [mailto:[EMAIL PROTECTED]
> Gesendet am: Montag, 25. August 2003 15:46
> An: [EMAIL PROTECTED]
> Betreff: RE: Win32 binary without FTP vulnerability
> 
> However as a matter of fact that could still suffers from a 
> similar direct
> drive access bug (instead of dot dot use driveletter:). I don't think
> anybody ever check if in that case access to an absolute path 
> on another
> drive would be possible or if that would be thwarted later by the file
> renaming routine (which would change ':' to '@').
> 
> I've always wanted to implement a small additional path for 
> that but never
> did it since I don't have a patched rogue ftp server handy to test it.
> 
> What would be needed to be patched is has_insecure_name_p() 
> in fnmatch.c,
> #ifdef WINDOWS check if the second character is ':' .
> 
> Heiko
> 

Reply via email to