RE: Long path exploit on NTFS

["David LeBlanc" <dleblanc () mindspring com>]

> -----Original Message-----
> From: hans.somers () nl abnamro com [mailto:hans.somers () nl abnamro com] 

> > The filepath (drive + folderpath + filename) theoraticly 
> can take up to 32000 charaters if the filesystem in use is NTFS. 
> However, the way in wich Windows NT (4.0, 2000 and XP) access this 
> filesystem a maximum of 256 characters is in place. 

This isn't quite correct. If you RTFM, you find from the documentation
on CreateFile:

Windows NT/2000/XP: In the ANSI version of this function, the name is
limited to MAX_PATH characters. To extend this limit to nearly 32,000
wide characters, call the Unicode version of the function and prepend
"\\?\" to the path. For more information, see File Name Conventions. 

BTW, The Fine Manual can be found at
http://msdn.microsoft.com/library/en-us/fileio/filesio_7wmd.asp?frame=tr
ue

Clicking on the link labeled 'File Name Conventions' gives:

Process a path as a null-terminated string. The maximum length for a
path, including a trailing backslash, is given by MAX_PATH. 
The Unicode versions of several functions permit paths that exceed the
MAX_PATH length if the path has the "\\?\" prefix. The "\\?\" tells the
function to turn off path parsing. However, each component in the path
cannot be more than MAX_PATH characters long. Use the "\\?\" prefix with
paths for local storage devices and the "\\?\UNC\" prefix with paths
having the Universal Naming Convention (UNC) format. The "\\?\" is
ignored as part of the path.

So the bottom line is that you have to use the API correctly if you wish
to deal correctly with long paths, either for creation or opening. This
can pose some difficulties, as not all of the API calls are available if
long paths are used. It also understandably gives anti-virus software
some problems, as those apps probably have a primary target platform of
Win9x/ME.

This issue comes up every few years - it ought to be in a FAQ somewhere.
Perhaps I'll give it some coverage in the next edition of 'Writing
Secure Code".

David LeBlanc
dleblanc () mindspring com