search

codenote / google-security-research

Automatically exported from code.google.com/p/google-security-research
0 stars 0 forks source link

Windows: SMBv2 Symlink to Local File Vulnerability #138

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
Windows: SMBv2 Symlink to Local File Vulnerability
Platform: Windows 7, 8.1 Update 32/64 bit
Class: Security Bypass/Information Disclosure

SMBv2 supports symlinks on remote file systems by returning a special status 
code (STATUS_STOPPED_ON_SYMLINK) when a symlink is encountered on the remote 
share. It also returns a symlink reparse data buffer to be processed to 
determine where to redirect the request. While this is supported functionality 
by default Windows 7+ is configured to not follow symlinks from a server. This 
includes remote->remote and remote->local, presumably for security reasons. The 
verification of the remote->local or remote->remote is done within the object 
manager during a reparse operation. 

Unfortunately even though [MS-SMB2] states that the reparse buffer must be of 
type IO_REPARSE_TAG_SYMLINK no code (such as in MRXSMB20.sys) actually checks. 
The only checks on the buffer is a call to FsRtlValidateReparsePointBuffer in 
MRXSMB20.sys, which is happy to validate IO_REPARSE_TAG_MOUNT_POINT buffers. 
This causes a reparse to occur in the IO manager, and because it isn't a 
symlink the source device is not considered, instead only the destination 
device (which can be a disk drive) is checked. Exploiting this allows a 
malicious SMBv2 server to force a client to open arbitrary local files. For 
example it might be possible to serve a HTML file from the share and use 
XMLHttpRequest to access local files through this vulnerability. Also even 
though mount points are supposed to only be used with directories once the 
buffer is in the object manager it doesn't make such a distinction, so this can 
be used to open files or directories. 

It's also interesting that no effort is made to verify the header values either 
(either the length or the SymLinkErrorTag), although it isn't obvious this 
would cause any security issues. 

Demonstrating the issue isn't trivial, it can be done either by modifying the 
reparse buffer in a kernel debugger or instead using a modified samba server. 
I've attached a patch for samba 4.1.13 which sends back the reparse point 
response when the file "badgers.txt" is requested from the share. The reparse 
point buffer redirects the request to \??\c:\windows\win.ini. When a request is 
made for the filename it will instead open the local file. 

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

Original issue reported on code.google.com by fors...@google.com on 27 Oct 2014 at 4:56

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 27 Oct 2014 at 9:05

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 28 Nov 2014 at 9:23

GoogleCodeExporter commented 9 years ago

Original comment by fors...@google.com on 2 Dec 2014 at 11:11

GoogleCodeExporter commented 9 years ago 
Correspondance Date: 29 Oct 2014

< Microsoft say they are investigating.

Original comment by fors...@google.com on 13 Jan 2015 at 12:40

GoogleCodeExporter commented 9 years ago 
A bit more detail on the potential exploitability of this issue. The most 
obvious exploitation method is for information disclosure. If you could 
convince a user to browse to a HTML page on a malicious SMB server in IE it's 
possible to use MSXML XMLHttpRequest to read any local file (with respect to 
the security settings of the browser such as the sandboxing mode). This can be 
achieved by requesting a file from the server from the current directory and 
redirecting the request to a local file.

It could also be exploited to write files to disk if the user could be 
convinced to open a document or other file on the malicious server which then 
writes to the current location. For example Word will write out temporary files 
to the current location for recovery purposes, this could be hijacked to write 
the temporary file to anywhere the user has permissions to write (and as it can 
know the username due to the SMB auth it can guess their user's directory). 
While the malicious server couldn't directly specify the contents of the file 
it might be able to do so indirectly (for example the temporary file example).

Original comment by fors...@google.com on 13 Jan 2015 at 12:54

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Correspondance Date: 16 Jan 2015

< Microsoft have concluded that the issue does not meet the bar of a security 
bulletin.  They state that it would require too much control from the part of 
the attacker and they do not consider group policy settings as a security 
feature.

Marking as WontFix and removing view restriction as the MSRC case is closed.

Original comment by fors...@google.com on 16 Jan 2015 at 7:55