New issue
Advanced search Search tips
Starred by 5 users

Issue metadata

Status: WontFix
Owner:
Closed: Jan 2015
Cc:



Sign in to add a comment
link

Issue 138: Windows: SMBv2 Symlink to Local File Vulnerability

Reported by forshaw@google.com, Oct 27 2014 Project Member

Issue description

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.
 
samba_symlink_vuln.patch
1.7 KB Download

Comment 1 by forshaw@google.com, Oct 27 2014

Project Member
Labels: MSRC-20919

Comment 2 by forshaw@google.com, Nov 28 2014

Project Member
Owner: forshaw@google.com

Comment 3 by forshaw@google.com, Dec 2 2014

Project Member
Labels: -Product-Windows Product-Windows-Kernel

Comment 4 by forshaw@google.com, Jan 13 2015

Project Member
Correspondance Date: 29 Oct 2014

< Microsoft say they are investigating.

Comment 5 by forshaw@google.com, Jan 13 2015

Project Member
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).

Comment 6 Deleted

Comment 7 by forshaw@google.com, Jan 16 2015

Project Member
Labels: -Restrict-View-Commit PublicOn-2015-Jan-16
Status: WontFix
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.

Sign in to add a comment