CESA-2009-004 - rev 1

[See all my vulnerabilities at http://scary.beasts.org/security]

[Blog if you want to subscribe to new findings is at http://scarybeastsecurity.blogspot.com/]

Linux kernel "seccomp" facility minor vulnerability

Programs affected: Fortunately, pretty much no-one uses seccomp.
Severity: Syscall policy violation.

This is a specific follow-on from CESA-2009-001 which noted a generic Linux issue with syscall filtering.

The Linux kernel actually has a built-in syscall filtering technology called "seccomp". It permits a process to restrict itself to an extremely restricted set of syscalls -- read(), write(), exit(), sigreturn(). That's very powerful if not quite generic enough for wide use. Check out prctl(PR_SET_SECCOMP, ...).

The confusion with 32-bit vs. 64-bit syscall numbers applies in this context too. The impact is very limited because of the limited number of syscalls which can abuse this mix up. The evil seccomp'ed process can execute these syscalls if it is a 32-bit process:

32-bit syscall / number64-bit syscall the attacker can hit
exit / 1write
read / 3close
write / 4stat
sigreturn / 119setresgid

And if it is a 64-bit process:

64-bit syscall / number32-bit syscall the attacker can hit
read / 0restart_syscall
write / 1exit
exit / 60umask
rt_sigreturn / 15chmod

As can be seen, none of the mappings are too bad apart from the minor leak of filesystem paths with stat(). Perhaps chmod() could also be a hassle depending on how things are set up.

CESA-2009-004 - rev 1
Chris Evans