95

In linux every user can create symlinks, but in Windows I need an admin command line, or mklink fails. Why is that?

ripper234
  • 1,126
  • 1
  • 8
  • 11
  • 1
    Indeed, why? Might be the references, by default enabled in programming languages like MS C#, is a vulnerability?! – Val Mar 08 '13 at 19:44
  • 13
    What's worse, hard links and directory junctions *can* be created by regular users AFAIK, just not symlinks. This restriction seems really arbitrary. – Ajedi32 Oct 30 '15 at 15:44
  • 2
    See also: http://superuser.com/questions/10727/why-cant-normal-users-on-windows-create-symbolic-links – Ajedi32 Oct 30 '15 at 15:44
  • 3
    A good answer should give an example how the SeCreateSymbolicLinkPrivilege can be exploited or abused. What is the risk involved? How does it soften security? Give a specific exploit example. – user643011 Jun 08 '18 at 15:34
  • 3
    @user643011 , most likely some **** simply didn't implement permission check when application tries to access data by symlink. microsoft just can't hire competent developers for some reason. – Victor Yarema Feb 13 '20 at 12:04

5 Answers5

32

By default, only administrators can create symbolic links, because they are the only ones who have the SeCreateSymbolicLinkPrivilege privilege found under Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\ granted.

From Microsoft TechNet: Security Policy Settings New for Windows Vista:

Symbolic links (symlinks) can expose security vulnerabilities in applications that aren't designed to handle symbolic links.

StackzOfZtuff
  • 17,783
  • 1
  • 50
  • 86
ordag
  • 1,338
  • 12
  • 8
  • 5
    I'd love to read more details about these security vulnerabilities. – ripper234 Dec 29 '11 at 10:51
  • 9
    @ripper234 Maybe something like [this](https://en.wikipedia.org/wiki/Symlink_race). – ordag Dec 29 '11 at 11:53
  • 32
    @Val Totally agree. The "SeCreateSymbolicLinkPrivilege" part explains HOW the rule is enforced, it doesn't explain WHY the rule exists in the first place. Now, the "security vulnerabilites" part does explain why admin rights were deemed necessary, and for me that's the only relevant part of this answer. – Pedro Rodrigues Mar 12 '14 at 17:21
  • 5
    Actually that pointer to Symlink race is bogus as at least on Linux you get permission denied when you attempt to do that. Show me a real security vulnerability! – Andrew DeFaria Jul 30 '15 at 18:27
  • 2
    ....but this question isn't about linux... – Mike Ounsworth Jul 30 '15 at 18:31
  • 12
    From what I understand, Symlink Racing is a vulnerability that was patched at the kernel level in Linux some time ago: http://security.stackexchange.com/a/83977/29865 Is Windows still vulnerable? Is that why only admin users have this privilege? If so, why not just fix the problem instead of introducing stupid restrictions like this? – Ajedi32 Oct 30 '15 at 15:34
  • 25
    Even the "Symbolic links ... can expose security vulnerabilities in applications that aren't designed to handle symbolic links." explanation isn't much of an answer. Examples? This is security.stackexchange.com, a Q&A site full of security experts, yet nobody can provide a concrete answer to this question? That seems telling. – jamesdlin Jun 10 '16 at 07:00
9

It is not entirely (see below) the case anymore as of Windows 10 Insiders build 14972 (windows 10 creators update ~ 1703).

However, from the comments below the blog post, concerns about the issues mentioned in the other answers are still there, and to make use of this new behaviour, you need to:

  • enable developer mode on your machine
  • pass a SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE flag to the CreateSymbolicLink API
Martin
  • 1,247
  • 2
  • 12
  • 19
MayeulC
  • 191
  • 1
  • 4
  • 27
    _Sigh_. Once again, the blog post just cites unspecified "security requirements" as the reason for why this isn't enabled by default. Then when people question this in the comments, the author responds by again saying "they introduce very real security risks" and "There are some well documented security concerns with symlinks" without explaining what those risks are. This is ridiculous. – Ajedi32 May 09 '18 at 15:19
7

I found the reason when Vista was launched. The given reason for admins only is very simple. It's not unspecified security problems, it's thousands of pieces of software have to be upgraded to use API calls that literally didn't exist before they were added to avoid gaping security holes when traversing symbolic links.

Windows is horribly vulnerable to symbolic link racing; there are ways to avoid this, kind of, but virtually no applications are using the APIs in such a way at all. Even Microsoft is not accepting security bugs that involve symbolic link racing. I just tried to report one three months ago.

Joshua
  • 1,090
  • 7
  • 11
  • Interesting. Any idea why Windows couldn't patch this at the kernel level like Linux did? (https://github.com/torvalds/linux/commit/800179c9b8a1e796e441674776d11cd4c05d61d7) Also, why aren't hardlinks vulnerable? – Ajedi32 Jan 03 '19 at 14:22
  • @Ajedi32: Because Windows doesn't have a direct equivalent of root, and looking up group membership at path traversal time is stupid and the root of the drive is equivalent to stickty tmp – Joshua Jan 03 '19 at 14:53
  • 1
    @Ajedi32 Also, the Linux patch doesn't fully solve the problem, when dealing with sandboxes rather than fully different users. I found a TOCTOU bug in the broker process for a well-known program's sandbox where you could use a symlink (or junction, or hardlink) to break the broker process' assumptions about the sandboxed-ness of a file that the sandbox could "create", all without breaking the conditions in the Linux protection. This was an arbitrary write from within the sandbox via sandbox race. I've found similar issues in installers/updaters. – CBHacking Oct 22 '20 at 08:43
6

Linux has a compartmentalised file/user structure. What that means is "program A" cannot do "task B" unless it's related to "disk space C". So symlinks don't really affect anything logistically in terms of risk penetration because the entire OS is predicated on the assumption of action->permission.

Or to put it another way, making a gazillion symlinks doesn't help you if you're a hacker with nothing but low-level permissions. So, on Linux or MacOS it doesn't help you.

However, on Windows you don't have a "program A" that runs a program other than the person logged in... so the person logged in can do "task B" to wherever they like. So it DEFINITELY helps you to have penetration to the level of symlinks because you can override commonly found real files with viral payload, and hide that you did it.

So, without the symlink protection level, a virus could infect you, run as its payload a lot of symlinks to, say, redirect "explorer.exe" to a fake "exactly-as-windows-made-it-except-with-a-payload explorer.exe".

Why would you do that? Quite honestly it's the keys to the kingdom. You could recruit that computer reliably into a bot theoretically activating its way into the future etc. There are a million ways why this is better than just "having an infection" because most people remove them when they see them, and this could be hidden.

schroeder
  • 123,438
  • 55
  • 284
  • 319
Mr Heelis
  • 201
  • 2
  • 1
  • Comments are not for extended discussion; this conversation has been [moved to chat](https://chat.stackexchange.com/rooms/115465/discussion-on-answer-by-mr-heelis-why-do-you-have-to-be-an-admin-to-create-a-sym). – Rory Alsop Oct 24 '20 at 11:56
0

Hardlinks and directory junctions are only inside one partition(there cant be a hardlink from one drive to another or even to a network location).

SymLinks on the other hand can also link from a place on the system which seems "safe" to a network location.

StefanA
  • 17
  • 1
  • 13
    And this is a problem because...? – jamesdlin Nov 01 '17 at 02:46
  • 2
    Directory Junctions (`mklink /J`) must be local, but they *are allowed* to point to another disk. You can `mklink /J C:\mylink D:\mydir` without problem. – Martin Jan 22 '20 at 12:54
  • 1
    Unix systems handle this just fine. Why is NTFS so arbitrarily crappy? – Ti Strga Oct 21 '20 at 22:49
  • @TiStrga Sort of OT, but what do you mean "handle this just fine"? You can't hardlink files on different volumes on any OS, that's contrary to the very concept of what a hardlink *is*. Symlinks between volumes work fine, on both NTFS and *nix filesystems. Junctions are a weird legacy in-between (they're not quite directory hardlinks but they're closer than symlinks, and mostly are just legacy from when NTFS didn't have true symlinks in the pre-Vista days). – CBHacking Oct 22 '20 at 08:35
  • @CBHacking yes, I know. I was referring to the supposed "danger" of creating a symlink to something that might be on a remote system which may or may not exist in the future. Windows freaks out, Unix just does it and gets out of the way. – Ti Strga Oct 23 '20 at 17:45
  • @TiStrga Except that's just false, NTFS (and `mklink`) is perfectly fine with creating symlinks to files (currently existing or not) in remote or removable volumes, assuming you have the permission to create them at all. Junctions are more limited, because they're legacy and intended for a limited use case (this was short-sighted of MSFT), but it's not 2000 any more, either. – CBHacking Oct 24 '20 at 00:18
  • No, I just tried creating an NTFS symlink to a remote file. PowerShell gave errors about symlinks not being permitted to do that. \*shrug\* Trying to fight the OS isn't worth the effort. – Ti Strga Jan 14 '21 at 21:52