Re: The old "." problem

[davidz () IHUG COM AU (David Zverina)]

If I remember correctly the problem was actually with NT (possibly in Win32
API?) not distinguishing correctly between filename, filename., filename..,
etc. as illustrated below. This means that this problem affects every piece
of software under NT which does not take specific steps to prevent it. Same
goes for the "::$DATA" suffix under NTFS which you'll find probably also
allows to bypass checks based on a equivalency of a filename.

Cheers,

Dave/

--- example ---
C:\TEMP>dir x.txt*
 Volume in drive C has no label.
 Volume Serial Number is 1DFF-2C70

 Directory of C:\TEMP

File Not Found

C:\TEMP>echo hi > x.txt

C:\TEMP>type x.txt
hi

C:\TEMP>type x.txt.
hi

---
David Zverina
Engineer - Black Ice Software
"This message transmitted on 100% recycled electrons."

> -----Original Message-----
> From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of
> nblasgen () NICK REFRACT COM
> Sent: Thursday, 14 October 1999 8:31
> To: BUGTRAQ () SECURITYFOCUS COM
> Subject: The old "." problem
>
>
> A while back there was the problem of Windows HTTP servers with CGI and
> other sever parsed pages (ASF, SMX, etc) if you added a "." to the end it
> would give you the raw code in TEXT format.  I understand how that was a
> security problem.
>
> Just noticed that the same problem is true for at least one Windows FTP
> server, Serv-U.  I can't find a problem with being able to request files
> with a extra "." at the end.  I was unable to test the idea of downloading
> files that I had no permissions too.
>
> Nicholas Blasgen
> Refract, LLC