[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Samba Remote Zero-Day Exploit
> From: Stefan Kanthak [mailto:stefan.kanthak@xxxxxxxx]
> Sent: Monday, 08 February, 2010 16:33
> Michael Wojcik wrote:
> >> From: Stefan Kanthak [mailto:stefan.kanthak@xxxxxxxx]
> >> Sent: Saturday, 06 February, 2010 08:21
> >> Since Windows 2000 NTFS supports "junctions", which pretty much
> >> resemble Unix symlinks, but only for directories.
> >> See <http://support.microsoft.com/kb/205524/en-us>
> > And at least since Vista, it also supports symlinks, which are
> > designed
> s/at least//
> [ well-known facts snipped ]
So ... your original note about junctions did not cover "well-known
facts", but my note about other reparse point types did?
> > The Windows SMB server apparently won't cross reparse points,
> > so there's no equivalent vulnerability.
> NO, Windows SMB server crosses reparse points!
Not in my testing, at least not for junctions and symlinks. User with
requisite authority could traverse the junctions and symlinks locally,
but not remotely via a share.
> But as Dan Kaminsky pointed out, you need to have administrative
> to remotely create a junction on an SMB share, so the non-admin user
> cant get himself access to files outside a share he's allowed to
Unless the reparse point already exists.
This particular exploit happened to involve a remote user creating a
symlink. That doesn't mean there are no other imaginable vulnerabilities
stemming from filesystem objects that violate the notional tree
structure of the directory hierarchy.
The obvious one: someone shares a branch of the directory tree in the
belief that clients only have access to that part of the tree, but the
tree already contains a convenience symlink (Unix) or reparse point
(Windows) that points elsewhere in the hierarchy. That's one reason why
Samba has had the "wide links=no" option since, what, the mid-1990s.
Principal Software Systems Developer, Micro Focus