5

I have been given a security specification document that contains some rules about the product I currently work on (docker containers). One states that:

All broken symlinks must be removed.

My question is, why do broken symlinks pose a security threat?

Please note that the docker containers I am dealing with are linux based.

UPDATE: The symlinks must be removed from the images/containers not from the host.

Hector
  • 10,893
  • 3
  • 41
  • 44
Dimitris Dalianis
  • 51
  • 2
  • 6
    Well: What would happen if unauthorized data is placed at the location that the broken symlink points to? – user Mar 21 '17 at 16:32
  • 1
    do you have a link to the security documentation in question, it could be helpful to see the statement in context . – Rory McCune Mar 21 '17 at 17:10
  • @RоryMcCune Unfortunately it is propriety so I cannot post it online. But the statement is isolated. – Dimitris Dalianis Mar 21 '17 at 17:38
  • hmm, ok, so in terms of context was it symlinks on the host, in the image/container or both that they were referring to? – Rory McCune Mar 22 '17 at 10:53
  • @RоryMcCune In the docker images. I will update the question accordingly. – Dimitris Dalianis Mar 22 '17 at 13:05
  • 2
    hmm well I'm struggling to think of a security justification for this. I guess if you mounted a volume into a container with a symlinked file in it, you could get an unxpected result as it would point to the location relative to the container rather than relative to the host, but that doesn't seem likely to be hugely relevant to the security of the environment... – Rory McCune Mar 22 '17 at 19:03
  • Because fakelinks can be used to bypass permissions. Example: https://www.virtualmin.com/node/19724 – Overmind Dec 19 '17 at 09:47

1 Answers1

2

The risk really depends on where the symlink is and where it points to. In most cases these are harmless - especially in a docker style setup. An example risk -

In many cases webservers are set only to serve files from a given directory but are allowed to follow symlinks. That directory may have locked down permissions - so its safe to assume the content has not been modified by a compromised process (unless privilege escalation has occurred - and in that case its end game anyway).

Now imagine instead you have a symlink pointing to another file in another location. That file has also been set to the same permission setup - but its parent directory hasn't.

If the file is been deleted and the symlink remains there is a risk. A malicious party may hold permissions to create a file at that location. If they can then now your webserver will happily serve the file completely oblivious to the fact it is malicious.

Hector
  • 10,893
  • 3
  • 41
  • 44