Description of problem:
The directory /var/lock is writable by unprivileged processes
with the "lock" groupid, for example, processes that execute
the set-gid /usr/sbin/lockdev command.
Scripts in /etc/init.d create and remove files as root, under
subdirectories of the /var/lock directory (see listing below).
This is a latent privilege escalation vulnerability. If the set-gid
/usr/sbin/lockdev command has a vulnerability, then an unprivileged
user on the system can symlink /var/lock/subsys to a directory with
critical files (such as /etc), and trick the /etc/init.d scripts
into creating or removing files as root in that directory.
-rwx--s--x 1 root lock 17336 Sep 25 2009 /usr/sbin/lockdev
drwxrwxr-x 5 root lock 4096 Apr 12 15:50 /var/lock
drwxr-xr-x 2 root root 4096 Oct 16 07:46 /var/lock/dmraid
drwx------ 2 root root 4096 Apr 12 19:44 /var/lock/lvm
drwxr-xr-x 2 root root 4096 Apr 12 19:45 /var/lock/subsys
Other attacks may be possible, such as attacks that replace
the directories /var/lock/dmraid or /var/lock/lvm by symlinks to
critical directories, but these have not been investigated.
Why this is privilege escalation
This is privilege escalation, because an unprivileged user who can
subvert the lockdev program would be able to symlink /var/lock/subsys
to some other directory (such as /etc), and trick the /etc/init.d
scripts into creating or removing files as root in that directory.
In other words, by making /usr/sbin/lockdev set-gid, it is given
much of the power of a set-uid root program.
Why this is a latent vulnerability
This is a latent vulnerability, as long as there is no known exploit
a) Do not make /var/lock group-writable. This is the configuration
of, for example, Ubuntu 9.10, It appears to break no functionality,
and is the simplest solution.
b) Do not create/remove files as root, when a directory is writable
by non-root processes. This requires changes to all the /etc/init.d
c) Use a safe pathname resolver as discussed in Chari et al.'s NDSS
paper, see "additional information" below. This involves changes
to the library or file system code.
Version-Release number of selected component (if applicable):
Fedora Core 12 and 11. Similar file permissions are found with older
releases such as RedHat 7.3, but these systems haven't been analyzed.
Exploitation requires a vulnerability in the set-gid /usr/sbin/lockdev
command, to escalate "lock" group privilege to "root".
Steps to Reproduce:
This example exploits the commands in the /etc/init.d/killall script,
which executes at system shutdown (or reboot) time. Other exploitation
(for example, at system start-up time) may also be possible but has
not been investigated.
1. As an unprivileged user, exploit a vulnerability in the set-gid
2. Having acquired group "lock" privileges, replace /var/lock/subsys
by a symlink to /etc.
3. Wait until the system shuts down (or reboots). The system will
execute the script /etc/rc0.d/S00killall (or /etc/rc6.d/S00killall),
which is symlinked to /etc/init.d/killall. The commands in this
script will be executed as root.
The main body of this script is:
for i in /var/lock/subsys/* ; do
# Check if the script is there.
[ -f "$i" ] || continue
# Get the subsystem name.
# Networking could be needed for NFS root.
[ $subsys = network ] && continue
# Bring the subsystem down.
if [ -f /etc/init.d/$subsys.init ]; then
elif [ -f /etc/init.d/$subsys ]; then
rm -f "$i"
For example, if /var/lock/subsys is symlinked to /etc, then this
script will remove any file named /etc/FOO for which no script file
exists named /etc/init.d/FOO or /etc/init.d/FOO.init.
File destruction. Other exploits may create files in unexpected
places, but this has not been investigated.
An exploit in a set-gid program should never allow random users
to create or delete files as root.
Suresh Chari. Shai Halevi Wietse Venema. Where Do You Want to Go
Today? Escalating Privileges by Pathname Manipulation. 17th Annual
Network & Distributed System Security Conference (NDSS 2010).
Thanks for report.
Adding lockdev maintainer to cc to know his opinion about the change to 755 ... I think you have other possibilities - like lowering capabilities for lockdev setgid binary, some SELinux rules for /sbin/lockdev . Basic unix file rights are not perfect anyway (as they do depend on UID/GID numbers, which may differ on various systems). I'll investigate it a bit more ...
(In reply to comment #0)
> Possible solutions
> a) Do not make /var/lock group-writable. This is the configuration
> of, for example, Ubuntu 9.10, It appears to break no functionality,
> and is the simplest solution.
/usr/sbin/lockdev is a set-gid binary that creates lock files for e.g. ttyS0 in
/var/lock so regular users don't need write access there.
AFAIK Debian/Ubuntu do not ship this set-gid binary like Fedora.
Liblockdev1 package in Debian/Ubuntu ships only the shared library.
I looked into Debian testing / Ubuntu 10.04 and
/var/lock is group-writable there:
drwxrwxrwt 2 root root 4096 2010-04-15 07:47 /var/lock
I'm sorry, but I still don't understand how the set-gid lockdev could create lock files in /var/lock when we make /var/lock not group-writable.
I'll be thinking about some lowering capabilities for lockdev.
Thanks, Jiri ... I think it should be kept group writable. Lowering capabilities in lockdev seems to be good compromise for me. Reassigning to lockdev, I'm not going to reduce permissions on /var/lock in filesystem package. If you still think that it is better way to lower the permissions on /var/lock, feel free to propose it on devel.org list to know opinion of wider audience.
[Wietse Venema here - sorry my name did not show up in the bugzilla signup procedure]
The real problem is that /etc/init.d/* scripts create/remove files as root under a directory that is under control by an unpriviliged user (in this case a group).
There are two types of fixes: "type 1" fixes that address the underlying problem, and "type 2" fixes that address specific symptoms.
A clean "type 1" fix is to change the lockdev program so that it creates application locks in a new directory /var/lock/lockdev. Then, /var/lock can be made writable only by root. This eliminates not only the problem that init.d scripts create/delete files under a directory that is group writable, but it also eliminates any problem with creating or removing files as root under the other /var/lock/* directories.
A simple "mixed type 1 and 2" fix is to make /var/lock sticky and to rely on the system to create /var/lock/subsys etc. at boot or install time. Then, no-one except root can replace /var/lock/subsys etc. by a symlink, and cause /etc/init.d/* to blow away files as documented in the initial bug report. This fix is more fragile due to the use of special directory permissions.
An example of the "symptom only fix" is to complicate the lockdev program with extra configuration for capabilities, selinux, etc. That seems even more fragile than setting the sticky bit.
In case this is not 100% clear: with
> A simple (part symptom, part fundamental) fix is to make /var/lock sticky
> and to rely on the system to create /var/lock/subsys etc. at boot or
> install time.
I mean ADD the sticky bit, KEEP the root and group write permission, i.e. drwxrwxr-t root lock /var/lock
Making /var/lock 1775 was already proposed and was rejected CANTFIX - see https://bugzilla.redhat.com/show_bug.cgi?id=145264 - and e.g. http://marc.info/?l=linux-security-audit&m=96441626707601&w=2 which problems might be caused by sticky bit.
And what are your thoughts about the better fix: having lockdev create locks under its own directory?
drwxr-wr-x root root /var/lock <<<<=== No group write permission
drwxr-xr-x root root /var/lock/dmraid
drwxrwxr-x root lock /var/lock/lockdev <<<=== Group write permission here
drwxr-xr-x root root /var/lock/subsys
Now, the subsys directory is "safe" and my privilege esclation exploit no longer works. This also addresses any problems with creating/deleting files as root under the /var/lock/drmraid etc. directories or any directories that might be added in the future.
With this, the lockdev program no longer has write permission on the parent of /var/lock/subsys, /var/lock/dmraid, and so on.
Filesystem Hierarchy Standard
doesn't say, that lock files have to be stored directly in /var/lock, but
"Lock files should be stored within the /var/lock directory structure."
drwxr-xr-x root root /var/lock <<<<=== No group write permission
drwxrwxr-x root lock /var/lock/lockdev <<<=== Group write permission here
looks like a solution to me.
Lockdev now (lockdev-1.0.3-5.fc14) creates it's own
drwxrwxr-x root lock /var/lock/lockdev
directory during installation.
Lock files are placed into this directory,
so /var/lock doesn't need to be group-writable anymore.
Built as filesystem-2.4.35-1.fc14 ... permissions on /var/lock are now 755:root:root
I agree that this solution solves the problem at its root cause. Now, can someone undo the change that was made to the subject of this report? The idea to solve the problem by playing with capabilities is a mistake, as it addresses a symptom (lockdev can do nasty stuff to root) and not the cause (lockdev should not have write permission to a path that is used by root).