Log in

Robert Watson on System Call Wrappers - James Morris
August 7th, 2007
09:53 pm


Previous Entry Share Next Entry
Robert Watson on System Call Wrappers
Even though it is fairly well known that system call wrappers are dangerous, many security schemes continue to use them, including several well-known commercial security products from major vendors.

Briefly, the technique involves intercepting user requests at the system call level, then performing some security function and perhaps failing the call. A common example is re-vectoring the system call table so that a virus scanner is invoked when a file is opened. The Linux system call table was unexported long ago to discourage such use, although there's no way to actually prevent it.

There are many problems with such techniques. One significant class arises from the combination of concurrency, and gaps in time between when an object is checked and when it is used. For example, an application may subvert the security mechanism by passing clean data to be checked, then replacing it with malicious data before it is used. This is called a Time of Check to Time of Use race, or TOCTTOU.

Robert Watson, of FreeBSD and TrustedBSD fame, recently presented a good paper on the topic, which he discusses here: USENIX WOOT07, Exploiting Concurrency Vulnerabilities in System Call Wrappers, and the Evil Genius.

In the paper, problems with system call wrapping are comprehensively detailed, while the slides also include several examples of exploit code.

One interesting case, which I think would surprise many, is the ease with which their sudo could be subverted.

With Sudo on MP systems, the window for execve() arguments was over 430K cycles. We were able to successfully exploit this vulnerability, replacing command lines so that they were incorrectly logged, masking all further attacker activity in the audit trail.

The paper also discusses ways to mitigate the problem, including not using system call wrapping at all, and instead directly integrating mediation into the kernel; which is what SELinux does.

(5 comments | Leave a comment)

Date:August 9th, 2007 02:47 pm (UTC)

no actual sudo release affected

Keep in mind that the sudo example only affects an experimental version that was never actually released outside the cvs tree.
Date:August 9th, 2007 05:46 pm (UTC)

Re: no actual sudo release affected

Amusing that this happens on the very same day another firm endorses sudo on its list of highly recommended applications.


From: james_morris
Date:August 9th, 2007 06:30 pm (UTC)

Re: no actual sudo release affected

That's why I wrote "their" sudo.

I did have a look through the Fedora rpm source, and noticed some changelog entries about things like tightening race conditions, although with no useful information on exactly what broken, what was fixed or how "tight" the fix was.

As a principle, it's interesting, in that people would likely not expect sudo to have any problems, but it has some fundamental issues due to it operating at such a coarse level.
Date:March 22nd, 2009 06:21 pm (UTC)

How does selinux prevent this?

Does selinux take a copy of syscall arguments or does it do heavy handed locking and block all programs on all CPUs from running until both the check and the start of the syscall are done to prevent someone changing the memory that the a pointer is pointing to? If it's working with a copy, did selinux explicitly have to make this copy or was there a copy all along?
From: james_morris
Date:March 22nd, 2009 09:11 pm (UTC)

Re: How does selinux prevent this?

SELinux is hooked into the right places to be able to make the security decision without copying or races.
James Morris Powered by LiveJournal.com