Abusing Symbolic Links Like It's 1999
An anonymous reader writes with this snippet from James Forshaw's recent post at Google's Project Zero, which begins For the past couple of years I've been researching Windows elevation of privilege attacks. This might be escaping sandboxing or gaining system privileges. One of the techniques I've used multiple times is abusing the symbolic link facilities of the Windows operating system to redirect privileged code to create files or registry keys to escape the restrictive execution context. Symbolic links in themselves are not vulnerabilities, instead they're useful primitives for exploiting different classes of vulnerabilities such as resource planting or time-of-check time-of-use. Click through that link to see examples of this abuse in action, but also information about how the underlying risks have been (or can be) mitigated.
If it's proprietary, there are implied warranties on it
Since when?
Microsoft excludes all implied warranties and conditions, including those of merchantability, fitness for a particular purpose, and non-infringement.
Bolded in the eula itself.
--
BMO
I never realized that Windows uses a unix-like file hierarchy.
According to the article, drive C: is actually a symbolic link to \Device\HarddiskVolume4, COM3 is \Device\Serial0 and so on.
I'm surprised, frankly. My exposure to Windows is pretty much nil (and I like it that way) but I always assumed that the the C: drive and COM: stuff was a completely different way of accessing the devices and whatnot than what Unix uses. Apparently, it's actually quite similar once you get under the hood.
Learn something new every day....
If you're a zombie and you know it, bite your friend!
It's a symlink into a systemd managed ntwork configuration repository, until the user breaks the link deliberately or accidentally with a text editor or configuration tool like puppet, cfengine, Chef, BladeLogic, Tuttle, or anyone else's homebrew server configuration tools, and then it *stays* broken permanently. See https://wiki.archlinux.org/ind...
Once gain, Mr. Pottering fails to understand the File System Hierarchy and why you don't dink with other people's stable tools.