Broken Links in Linux File Systems Can Be BAD

Sunday, October 10, 2010

Jamie Adams

4085079c6fe0be2fd371ddbac0c3e7db

BROKEN LINKS in Linux file systems are not just annoying — they can also be a security risk in some cases.

In a previous post, I discussed the potential dangers of unowned files and in this post I will talk about those annoying, resource consuming broken links usually considered simple file system “lint”.

I recently spoke to a Security Blanket® customer and they asked me, "Why does Security Blanket report on these broken links?" I responded with a typical, technical explanation of...

It [Security Blanket] was trying to determine the file's existing access controls by using stat(2) not lstat(2). This call was unsuccessful because the target file was non-existent therefore, we want you to be aware of this 'lint'.

Although I could not see their face, I am sure their eyes were rolling at my somewhat cryptic response. Later that day, I contemplated the existence of broken links and realized they are a potential security risk — in the form of a Trojan Horse.

Common Uses of Links

First of all, what is a link? Most desktop users use "shortcuts" but in the underlying file system they are actually links.

For example, "File A" resides in the document folder and "File B" is created on the desktop but actually points to "File A".

Another common implementation is for backward compatibility. Consider an application which was compiled and associated with a specific shared library.

When a new version of the library is installed, the older application still looks for the previous shared library.

The new shared library has all of the objects as before but to keep the older application from barfing a link is created. Consider the following:

# cd /usr/lib
# ls -l libxml2.so*
lrwxrwxrwx 1 root root 16 Jun 1 12:08 libxml2.so.2 -> libxml2.so.2.7.1
-rwxr-xr-x 1 root root 1385248 Aug 7 2009 libxml2.so.2.7.1

The earlier libxml2.so.2 library is linked to libxml2.so.2.7.1 — indicated by the "l" in the first character of the mode field and the "->" in the name field.

Another scenario links entire directories. This is typically done by system administrators to compensate for legacy applications or even an inability to properly configure applications to utilize existing directory structures.

For example, consider a homegrown application which stores its data in /usr/local/myhomegrownappdata. Now, there is no more space on the /usr file system and there is no more disk space to create a new file system. However, there is plenty of space on /home.

Unfortunately, the homegrown application's data directory is hard-coded so the system administrator can't configure it to use a different path.

So, the quick-and-dirty is to create the directory /home/myhomegrownappdata and link /usr/local/myhomegrownappdata/ to it. Ugh. The horror.

A Trojan Horse — The Trouble With Tribbles

A broken link is created when the source (target) file is removed but the link remains. Consider the above example of "File A" in the user's document folder and "File B" on the desktop which is linked to it. If "File A" is removed, "File B" is a broken link. Let's see this action at the command line:

greenlantern:~# cd /tmp
greenlantern:/tmp # touch jamie
greenlantern:/tmp # ln -s jamie adams
greenlantern:/tmp # ls -li jamie adams
2859232 lrwxrwxrwx 1 root root 5 Jun 11 09:22 adams -> jamie
2859231 -rw-r--r-- 1 root root 0 Jun 11 09:22 jamie

I created a file "jamie" with the touch(1) command and then created a symbolic link from "adams" to "jamie". Then I used the ls(1) command with the -i option to show their inodes (first column). Now, if I remove the "jamie" file:  

greenlantern:/tmp # rm -f jamie
greenlantern:/tmp # test -r adams; echo $?
1
greenlantern:/tmp # find -L . -type l -ls
2859232 0 lrwxrwxrwx 1 root root 5 Jun 11 09:22 ./adams -> jamie

After removing the file jamie, the return code ($?) of the test(1) command shows that I am unable to read "adams" because it was linked to "jamie". A useful technique to find all broken links, is to use find(1)'s -L option as shown above.

Now, a Trojan Horse could potentially be introduced if a target file "jamie" is created in the same path. Below I did just that:

greenlantern:/tmp # echo "Dangerous Stuff" > jamie
greenlantern:/tmp # ls -li jamie adams
2859232 lrwxrwxrwx 1 root root 5 Jun 11 09:22 adams -> jamie
2859233 -rw-r--r-- 1 root root 16 Jun 11 09:32 jamie
greenlantern:/tmp # test -r adams; echo $?
0

Note that the previous file "jamie" had an inode of 2859231 but this new file's inode is 2859233. The link doesn't care because it is path-based. Using the test(1) command I can read the link again.

Even if this is a result of non-malicious actions, the fact remains that the user or application is no longer using the original file.

Systems using Security Enhanced Linux (SELinux) in enforcing mode would have an advantage since the mandatory access controls applied to the file is inode-based. Despite discretionary access controls on a newly created file, it would not result in access to the process following the link — until the appropriate security contexts have been manually re-established.

Where do these troublesome “Tribbles” come from?

When installing software, many packages contain a "post-install" and a "pre-uninstall" routine. This means, when a package is installed the "post-install" routine may add additional links to provide backward compatibility.

However, since these links were created during the "post-install" they are not part of the package's manifest. When packages are removed, only files in the manifest are deleted unless there is some special clean up functions in the "pre-uninstall". However, few packagers include such clean up routines.

Then there is the notorious sharing-caring community of users which may all link to one user's resource files. Then one day, that user is removed and the community is left with broken links.

Regardless of their origins, broken links are not only annoying little Tribbles which consume file system resources they also pose a security risk in the form of a Trojan Horse.

A good system administrator will try to control these little Tribbles by using best practices, common sense, and educating their users.

Security Blanket's baseline feature can assist in detecting removed files or ones which have been replaced by using cryptographic hashes. For more information, visit our website.

Cross-posted from Security Blanket Technical Blog

Possibly Related Articles:
14513
Operating Systems
Information Security
Operating Systems Linux
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.