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:BUGTRAQat_private]On Behalf Of > nblasgenat_private > Sent: Thursday, 14 October 1999 8:31 > To: BUGTRAQat_private > 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 >
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:07:36 PDT