Security Blanket Technical Blog: Broken Links in Linux File Systems can be a Security Risk

Broken Links in Linux File Systems can be a Security Risk

BROKEN LINKS in Linux file systems are not just annoying — they can also be a security risk. 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 not 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

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.
Go there...
http://tcs-security-blanket.blogspot.com/2010/06/broken-links-in-linux-file-systems-can.html

I use an App called FSLint to find broken links. I have run across a few problems with them in my Linux Systems over the years. But I never realized that they could also be a Security Problem. Good to know! FSlint has several parameters to search by via the radio buttons at the top. But, I must admit that I haven't learned all of the terms used in the app and  that needs to be understood in order to make full use of this feature. I have used the Find Duplicate Files feature allot. It is a Powerful Tool. But, it can be very Dangerous too. Be careful, if you use FSLint in any mode! You could end up loosing files that you really want or need. And I wouldn't use it in "root" mode at all. You could Accidentally Damage or Break your OS! Still, if your careful. It is a great File System Tool and Cleaner.

One thing, that I'm still wondering about... What the heck are "Tribbles" and what do they have to do with any Operating System!?;)

Thanks for the info, Jamie!:)

Don