Windows Symbolic Link Mitigations | Hacker News Reader

Windows Symbolic Link Mitigations

googleprojectzero.blogspot.com

59 points2510c39011c515 comments

Backwards compatibility is such a headache.

Got to give it to Microsoft for their dedication to never breaking old code. I cannot imagine several of these scenarios happening more than in one or two programs given how niche they are.

On modern UNIX (Linux, BSD, et al) when you create a symlink do you need write access into the target directory, or do they suffer from this same sandbox escape?

You don't need write access to the target. A symlink is simply a file with a special attribute set, so all you need is the ability to write to the symlink's location (as opposed to its target).

e.g.:

  $ mkdir secrets
  $ ls -l
  drwxr-xr-x  2 ajf  staff      68 28 Aug 15:17 secrets
  $ chmod -rwx secrets
  $ ls -l
  d---------  2 ajf  staff      68 28 Aug 15:17 secrets
  $ touch secrets/foo
  touch: secrets/foo: Permission denied
  $ ln -s secrets lies
  $

Hmm on Windows it will check the permissions for both the source and the target on NTFS junctions.....

Yeah, I assume Windows's junctions work differently.

Sometimes I get the feeling that, although good in theory, that dedication to keeping alive old code is also a big source of cruft and bugs in Windows. They didn't drop 16 bit support until Windows Vista! I mean, was there aby big chance of a 286 running Windows XP?

I know, old (DOS-era) systems were being run inside WinXP, but having DOSbox take care of that was a way better solution -- which is what happened with those systems once they lost support from the OS.

> They didn't drop 16 bit support until Windows Vista! I mean, was there aby big chance of a 286 running Windows XP?

XP didn't run on 16-bit, it just allowed running 16-bit apps. Why? Well, loads of applications still used 16-bit installers, for instance. If it ain't broken, don't fix it, etc.

Also, Microsoft didn't drop 16-bit support deliberately. The Virtual 8086 mode (a CPU feature) doesn't work on x86-64.

> If it ain't broken, don't fix it, etc

which leads to MS being unwilling to break things and idiots being unwilling to update them because "it ain't broken"

You can still run 16 bit applications on Windows 7|8|10, as long as you use the x86 (i.e. 32 bit) flavor of the OS. I'm fairly certain that there are still enterprises large and small that depend on running 16 bit code, because replacing it costs money.

It really comes down to "Enterprise code better work or we won't upgrade". Its a straight migration issue, and that makes them an easy choice for an enterprise platform. It is amazing how many little programs cannot be broken.

Now, I do wish they had done a "classic" emulation with a go forward API of .NET, but I guess that would have been hyper-difficult given the players.

It's quite true. About ten years ago I came across a system still running dos 3.1, not windows, dos. It controlled a microscope. They withheld upgrading because the licensing was significant for the small subdepts budget and while very antiquated, the system still worked, albeit inefficiently.

Why did it exactly work inefficiently? There are plenty of legacy systems out there, scientific and engineering equipment is a very common place to find them, i still got couple of scopes that are running DOS they are very good and very cheap why should i care?

On a side note one of the big drivers dictating the shuttle decommission final date was that NASA ran out of 8086 chips they ran out of them in 2002, and there wasn't a big enough supply to push servicing them beyond 2012... The chips were apparently part of the pre-launch diagnostic module for the SRB's and there was an 8 months delay in shuttle missions in the early 2000's until NASA found a fresh batch some where. Since reading about that 13 years ago I still haven't heard of a cooler job at NASA (other than actually flying to space ;)) it's like being a modern day Indiana Jones hunting for new old hardware to keep their current missions in play...

The International space station is probably running out of their 486DX's these days if some one has a hook on a good supply of fresh one's they might make a killing :)

Because it was not network connected.

NTFS symbolic links were introduced with Windows Vista and are there to provide the Windows POSIX compliance (at a laughable point Vista with it's POSIX services was actually more compliant than Mac OS). NTFS Junctions (folder level symlinks) were introduce with Windows 2000, so while you can call it legacy code it's not that old...

The POSIX compliance in windows is due to a US government regulation (FIPS 151-2) it was introduced in various forums from Windows NT3.5 to Windows 7, it was dropped from Windows 8 (no idea why, maybe regulation changes) but it seems like it will be back with Windows 10 for enterprise users.

"There are three types of symbolic links .. Object Manager Symbolic Links, Registry Key Symbolic Links and NTFS Mount Points .. a fourth type, NTFS Symbolic Links"

How did Unix ever manage with only the one type of symbolic link

Because Unix uses the file system for everything Windows uses the object manager. Windows maps parts of the object manager to pre-existing concepts, like drive letters, for backwards compatibility. And, well, Windows has a registry, for better or for worse.

Reply on news.ycombinator.com