libsafe |
|||
| I have also taken a liking to libsafe recently. I read the OpenBSD announcements about stack protection techniques and dove into propolice. I gave it a good code review and found some issues with the stack_smashing handler. It was fixed and a new version was released. Then along came the file exploit...I became intrigued by it and decided this would be a good test for propolice. I compiled the file program's source and tested it. Propolice did not catch the exploit. Then I decided to check some of the other stack smashing protectors. I tried libsafe and it did not catch the file exploit either. I started looking at the libsafe source code and immediately realized that it could easily be extended to cover other functions. The file exploit is based on the programmer trusting that a value read in from a file truly represents the length of a chunk of data and that it is trusted to be under a certain length. A call to read() then overwrites the buffer and drops in the shell code. I also know that programmers may make the same mistake with several other IO functions and added them. The new & improved version now adds: read, recv, recvfrom, & readlink. My testing shows little or no performance impact. I think this is because most IO goes through a context switch into the kernel, waits for IO to complete, & then another context switch and then maybe delivering a signal, too. With all of this, a quick look around the stack gets lost in the noise. I created a patch and sent it to the libsafe people. I am publishing this code here in
effort to help anyone that's interested until the libsafe team releases their new and
improved version of libsafe. libsafe-2.0-16c.tar,gz
(April 21, 2003). It stops the file exploit dead in its tracks. This page was last updated 21 April, 2003 |
|||