504527 - treatment of alternate NTFS streams in NSPR calls

Status: NEW

(NSPR :: NSPR, defect, P5)

Description

[Julien Pierre]

Many Win32 system calls made by NSPR allow alternate streams to be specified as part of the filename. An example is at http://support.microsoft.com/kb/105763 with CreateFile .
Also see the better doc at http://www.alex-ionescu.com/NTFS%20Alternate%20Data%20Streams.pdf .
I don't know of a good doc from Microsoft on this.

I believe we didn't intend for NTFS ADS to be supported in NSPR, but they are accessible anyway due to values being passed from NSPR to Windows system calls.

The main problem here is not that we allow access to alternate streams. It is that the regular filename data stream can be opened with two different names - either the normal filename, or filename::$DATA .

This presents security issues to an application - if it protects access to one filename form, but not another form for example.
See what happened to the Microsoft IIS web server at http://support.microsoft.com/kb/197464 , for example.

Similarly, alternate data streams can be access with either filename:stream or filename:stream:$DATA . I am not really sure what the value of supporting the "$DATA" syntax is, since it seems to be always implied. It's a question I would love to ask Microsoft.  I don't see the rationale at this point, unless filename:<optional stream>:$SOMETHING_ELSE is also supported. I wish this was better documented by Microsoft.

While application themselves could address this issue and filter filenames before invoking NSPR calls, I believe the issue should best be addressed in NSPR, since we are trying to provide a platform-independent API, and requiring highly platform-specific additional code would be a burden on many applications .

There are several changes we can do at the NSPR level .
1) rejecting any filename ending with "$DATA". This would resolve the problem at hand, I believe . I think we should at least do this.

2) also forbid references to alternate streams - any filename ending with ":stream", not ending with $DATA .

The rationale for this would be that there is no provision in the current NSPR API for treatment of platform-specific features such as NTFS ADS, Mac HFS file forks, OS/2 extended attributes, etc. I'm not saying we should necessarily lock ourselves forever into the "lowest common denominator", but IMO if we want to support those extra features in some way, we should probably give it some more thought and extend the NSPR API.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

> I don't know of a good doc from Microsoft on this.
http://msdn.microsoft.com/en-us/library/aa364404(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa362667(VS.85).aspx

Comment 2

[Julien Pierre]

Thanks, Nelson . My google searches did not turn this up. I wish one could search on $DATA , but I haven't figured out how to do it - $ always gets dropped no matter what I use.

Comment 3

[Julien Pierre]

Wan-Teh, what do you think we should do about this issue ?
In particular the proposals in comment 0 .

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

The PR_GetFileInfo64 function in versions of NSPR produced before NSPR 4.7 
in January 2008 did NOT recognize filename::$DATA as being equivalent to filename.  NSPR 4.7 and later do.  

The behavior change is a direct result of the fix for bug 285157.  The old code
effectively enumerated the names of the files in directories, and reported no
file found if the requested name was not found there.  The new code gives the
name to Windows, and Windows replies positively for filename::$DATA if filename
exists.  

So, one view of this is that, originally, on Windows, PR_GetFileInfo would not
respond positively for any file whose name was not found in the directory, 
and now, it does.  Sadly, I think a pretty good case can be made that this is 
a regression.  

The questions are:

a) do we agree that this is a regresion?
b) if so, what do we do about it?  

Julien has proposed that, on Windows only, PR_GetFileInfo64 should detect 
that a file name ends in :$DATA and report file-not-found in that case.  
I didn't like that idea at first, but I see no way of resolving the perceived 
regression without doing so.  Is that agreed?  

That proposal does not prevent PR_GetFileInfo64 from being used to get information about named streams of type $DATA, but only requires that such 
info be gathered without the trailing :$DATA stream type specifier.

A related question is: if we do this for PR_GetFileInfo64 (which imples that
it is also done for PR_GetFileInfo, which calls PR_GetFileInfo64), do we also
want to change PR_Open and other NSPR functions that take file names as 
arguments so that they likewise dishonor names that end in :$DATA?  

If a strong case can be made that the change in PR_GetFileInfo64's behavior
introduced by the fix for bug 285157 is NOT a regression, someone PLEASE 
make that case ASAP.

This is a burning issue for us, considered a security vulnerability, because people can append ::$DATA to file names to bypass some server access controls.  
We'd like to get consensus on a plan ASAP.

Wan-Teh, we'd like you to "weigh in" on this subject.  Thanks.

Comment 5

[Wan-Teh Chang]

Julien's proposal is fine by me.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Taking.

Comment 7

[Josh Aas]

No need for this to remain closed. Double-checked with WTC.

Comment 8

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months and this bug has priority 'P2'/severity 'critical'.
:KaiE, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 9

[Kai Engert (:KaiE:)]

server side issue that doesn't seem high priority any more