> 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, though, > > 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 rights > 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 > access. 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. -- Michael Wojcik Principal Software Systems Developer, Micro Focus
