login
Search
This article is about recent exposures of many OpenBSD kernel level vulnerabilities
and advances in their exploitation which leads to trusted and robust exploits.
We will focus on 2 recent vulnerabilities in the OpenBSD kernel as our case studies. Out of the these we will mainly concentrate on exploitation of the select() system call buffer overflow. The setitimer() arbitrary memory overwrite vulnerability will be explained in the code section of this
article (as inline comments, so as not to repeat what we have already covered whilst exploring the select() buffer overflow).
This paper should not be viewed as an exploit construction tutorial, my goal is, rather, to explore and demonstrate generic ways to exploit stack overflows and signed/unsigned vulnerabilities in kernel space.
Case studies will be used to demonstrate these techniques, and reusable *BSD "kernel level shellcodes" -- with many cool features! -- will be presented.
cool
secure by default .... ????? ;-)
Nice article !
Of course these problems are
Of course these problems are fixed in 3.2 and 3.1-stable:
errata 015
errata 014
Old news
Of course these problems are fixed in 3.2 and 3.1-stable:
errata 015
errata 014
doest matter
what is interesting is the easy way to beak chroot / securelevel and such things. if ever in the future an exploit is found, we can easily get full control. so we should think twice about security... too many ppl think they are secure because the os manufacturer tellt them and uses such cool-sounding techniques like securelevel ;-)
Eugene
fixed in NetBSD more than 6 years ago
What i find interesting is that this same bug was fixed in NetBSD more than 6 years ago (1996/09/05), after OpenBSD was forked. Well, then how come it was not spotted during The (kernel) Security Audit(tm) OpenBSD people are so proud of?
software verifycation
...isnt possible. thats a fact some ppl seem to ignore. no kernel can be 100% secure, (if it has at least some lines of code) ;-)
so, just one more time one can state "do backups", do "security checks", do "updates" regularily and with some care...
Eugene
Well, it is possible for code
Well, it is possible for code to be correct. I think it is certainly conceivable that a kernel and OS could be 100% secure against the type of attacks described here. The complexity of modern operating systems makes it very difficult to eliminate all such attacks, but that doesn't mean that security breaches are inevitable.
It is possible, but unprovable
To prove that:
#include
int main() {
printf("Hello World\n");
}
is correct, you have to check the libraries that the corresponding binary is linked against are also totally safe, in all cases.
A kernel (don't know details of OpenBSD) is
100s of thousands of lines of code. Okay, so a kernel tends to include its own library code, but the point is the interactions of the different chunks of code, more than the code itself.
So you don't just have to check printf (in this example), you have to check that each call of printf() is calling it in the expected manner - for which, you have to document the expected manner, along with every assumption made in the printf() function.
With the really simple, and the really complex, calls, this is difficult. The intermediate are, I suspect, the easier to prove correct (less frequently used, and used in more controlled ways).
Provable correctness
What's more, to prove that even the most simple of programs is correct not only in source, but also in compiled form, you'll also have to verify the compiler you are using - both the source code and the machine code, too, btw, as was shown in 1984 already (I think). The Verifix Project aims to implement provably correct compilers etc., for example.
--
schnee
Even that has a bug
You forgot to return a value in the range of 0-255 from main.
typo
you probably meant:
printf("Hello World\n");
;)
"Hello World(n+1)"
"Hello World(n+1)"