Is it possible become root through a broken symlink owned by root and globally writeable?

Question

I'm looking for a vulnerability on a server. I'm looking in the /var directory and I get something like this:

drwxr-xr-x  3 root root 4.0K Aug 14 21:02 kerberos
drwxr-xr-x 12 root root 4.0K Nov 11 05:04 lib
drwxr-xr-x  2 root root 4.0K Jun 10  2014 local

lrwxrwxrwx  1 root root   11 Aug 14 21:00 lock -> ../run/lock     <-- CHECK THIS

drwxr-xr-x  3 root root 4.0K Aug 14 21:05 log
lrwxrwxrwx  1 root root   10 Aug 14 21:00 mail -> spool/mail
drwxr-xr-x  2 root root 4.0K Jun 10  2014 nis
drwxr-xr-x  2 root root 4.0K Jun 10  2014 opt
drwxr-xr-x  2 root root 4.0K Jun 10  2014 preserve
lrwxrwxrwx  1 root root    6 Aug 14 21:00 run -> ../run
drwxr-xr-x  4 root root 4.0K Aug 14 21:00 spool

If I look at the permissions of the lock "file" I see that the permissions for others is rwx. I suppose it is therefore possible for another user who is not the owner (root in this case), to read, execute and write this "file", so I check what kind of file lock is:

file lock
lock: broken symbolic link to `../run/lock'

stat lock

File: ‘lock’ -> ‘../run/lock’
  Size: 11          Blocks: 0          IO Block: 4096   symbolic link
Device: fb01h/64257d    Inode: 6424574     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2015-11-14 00:18:52.218518690 +0000
Modify: 2015-08-14 21:00:52.000000000 +0000
Change: 2015-11-11 04:56:35.543404826 +0000
 Birth: -

According to this information, is it possible to get root, use this permission to access other information or execute commands?

For instance I tried:

echo  "ls /etc" >> lock

But I get Permission denied.

Some questions:

1. Is my interpretation about the lock permissions correct?

2. Can I do something to get an advantage with this broken symlink?

3. What kind of questions must be ask with this broken symlink?

Answer 1

The permissions on a symbolic link are mostly meaningless. If you don't have read permission, you can't see where it points, and if you don't have write permission, you can't retarget it, but that's all -- and actually creating a link with permissions other than 0777 is quite the trick. The permissions on the target of the link determine what you can do with the target: if you were to replace the target of a root-owned broken link with a file you created, the target would be owned by you, and would act appropriately regardless of whether you accessed it directly or through the link.

Answer 2

No, it is usually not possible to get root using such links.

To answer to your more specific questions:

1. Is my interpretation about the lock permissions correct?

If this "file" was an actual file and not a symbolic link, your interpretation would correct, but it is not.

Symbolic links (aka. symlinks) permission are nearly always ignored: symlinks inherits their actual permissions from the file they point to, the rwxrwxrwx permission shown can be considered merely as stuffing. This is so true that the POSIX standard does not even define which permission the OS should show for the symlink:

The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-2008 shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified.

Some system show all permission bits sets (rwxrwxrwx, as in your case), some other show the permission on the linked file if it exists, some do some more fancy stuff (like a bitwise and operation between the link and the target permissions...).

I said above that these permission are nearly always ignored, this is because it is not completely true on an handfull of OSes. For instance Mac OS X systems deviates from the POSIX standard quoted above and the read permission controls the link resolution ability, which has very few impact (either good or bad) in term of security (it just make the system somewhat harder to maintain).

So, with all that in mind, what is your current permission with this broken link? It is the same as the target if it exists. However, since the target does not exist, you can do no operation with the link, even if you would have enough parameter (that's why it's broken: it just doesn't work).

2. Can I do something to get an advantage with this broken symlink?

Broken links by themselves are not abnormal and do not present any security weakness. You will often find such broken links in environments using chroot or network share, where the symlinks will successfully resolve only one you use the right root or have mounted the right network share.

3. What kind of question must be ask with this broken symlink?

You have a link whose path is /var/lock which points to the non-existing directory /run/lock. It is enough for you to be able to tamper with just one of those two path to take-over the /var/lock path.

• Do you have write permission on the target's parent directory or on a directory composing it's path? If yes, you will be able to create and take-over the missing directory. If not, you will not be able to tamper in any way with the missing target directory: it will stay missing.
• Do you have write permission on the link's parent directory or on a directory composing it's path? Is yes, you will be able to replace the link by another one, pointing to directory you own (pointing to /home/myuser/fakelock for instance), thus controlling all locks that an application would try to put in the var/lock path.

If you have write permission on none of these directories, then you're screw and just have to go on with your investigation: there is nothing to exploit here.