Vulnerabilities in systrace

At the First USENIX Workshop on Offensive Technologies, Robert Watson gave a presentation outlining vulnerabilities in systrace which he summarizes in this blog post:

A paper on the topic of compromising system call interposition-based protection systems, such as COTS virus scanners, OpenBSD and NetBSD's Systrace, the TIS Generic Software Wrappers Toolkit (GSWTK), and CerbNG. The key insight here is that the historic assumption of "atomicity" of system calls is falacious, and that on both uniprocessor and multiprocessing systems, it is trivial to construct a race between system call wrappers and malicious user processes to bypass protections.

I demonstrated sample exploit code against the Sysjail policy on Systrace, and IDwrappers on GSWTK, but the paper includes a more extensive discussion including vulnerabilities in sudo's Systrace monitor mode.

The moral, for those unwilling to read the paper, is that system call wrappers are a bad idea, unless of course, you're willing to rewrite the OS to be message-passing. Systems like the TrustedBSD MAC Framework on FreeBSD and Mac OS X Leopard, Linux Security Modules (LSM), Apple's (and now also NetBSD's) kauth(9), and other tightly integrated kernel security frameworks offer specific solutions to these concurrency problems. There's plenty more to be done in that area.

Todd Miller (millert@) clarifies the impact with sudo:

"The sudo systrace support is part of an experimental feature ("monitor mode") not present in any of the real sudo releases (though the code is available via anonymous cvs). Given the deficiencies of systrace (and ptrace) it is unlikely that this feature will be present in any future sudo release."

The Sysjail project is recommending against using sysjail:

"Due to handling semantics of user/kernel memory in concurrent environments, the sysjail tools, in inheriting from systrace(4), are vulnerable to exploitation. Details available here. Many thanks to Robert Watson for discovering these issues! Until these problems have been addressed, we do not recommend using sysjail (or any systrace(4) tools, including systrace(1)). All versions are vulnerable on all architectures.

Specifically, the bind(2) and sysctl(3) (and possibly other) functions may have their arguments re-written after being examined by the sysjail. This, in effect, leads to a total bypass of the prison."

It should be noted that systrace "has been integrated into NetBSD, OpenBSD and OpenDarwin" and has been ported to GNU/Linux, Mac OS X and FreeBSD.

To protect yourself from the shortcomings of systrace, know and understand what it does for you and make sure that systrace is not your only line of defense.

Just so it is clear, systrace is just a tool included in the distribution. It is not used by anything in the base system by default but be wary of using this tool as it stands. There has been long-standing skepticism around the effectiveness of systrace, including the difficulty in writing effective policies (Theo: "Establishing solid policies for daemons is not actually trivial.") and the unpredictable consequences of changing the semantics of the Unix privilege model (Marc Espie). Since 2002, the systrace(1) man page included a warning in the BUGS section about the possibility of escaping the policy enforcement because of the behavior of certain system calls.

Robert's paper and presentation are available on his site.