77

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

  • 1
    Indeed, why? Might be the references, by default enabled in programming languages like MS C#, is a vulnerability?! – Val Mar 8 '13 at 19:44
  • 12
    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: superuser.com/questions/10727/… – 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 8 '18 at 15:34
  • 2
    @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 at 12:04
26

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.

| improve this answer | |
  • 9
    @ripper234 Maybe something like this. – ordag Dec 29 '11 at 11:53
  • 78
    I wonder how people buy "this is not allowed because this is not allowed" as the answer to the question "why this is not allowed?". When you say that SeCreateSymbolicLinkPrivilege rule prohibits this, you give exactly this stupid answer. Might be this is "Rule of law" mentality: when people hear a rule they stop thinking. – Val Mar 8 '13 at 19:23
  • 29
    @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
  • 12
    From what I understand, Symlink Racing is a vulnerability that was patched at the kernel level in Linux some time ago: 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
  • 22
    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 7:00
8

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
| improve this answer | |
  • 20
    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 9 '18 at 15:19
5

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.

| improve this answer | |
  • Interesting. Any idea why Windows couldn't patch this at the kernel level like Linux did? (github.com/torvalds/linux/commit/…) Also, why aren't hardlinks vulnerable? – Ajedi32 Jan 3 '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 3 '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 at 8:43
3

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.

| improve this answer | |
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.

| improve this answer | |
  • 13
    And this is a problem because...? – jamesdlin Nov 1 '17 at 2: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 at 12:54
  • Unix systems handle this just fine. Why is NTFS so arbitrarily crappy? – Ti Strga Oct 21 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 at 8: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 at 17:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.