On Thu, 14 Aug 2003 13:37:06 -0600 Theo de Raadt <deraadtat_private> wrote: > I believe the best protection (at this time) is to combine ProPolice with > a W^X technology. > > W^X is more than just stack protection. It means that all pages that > are writeable are also marked as not executable. At least, it means > this is how the system by default operates, until some process asks > for something that has both write and execute permission. yes, and ? > W^X is more than just stack protection. It means that the data segments > are not executable. Nor is malloc'd memory. > > But W^X goes even further than this, since we consinder it a principle > that objects which are used should be protected as much as possible. > > For instance, we've gone further and also modified ld.so so that the > PLT and GOT tables follow the W^X principle as well. Whenever ld.so > has to make modifications to these tables, it must add W permission, > modify them, and then remove W permission again. They continue as > before, but are not vulnerable to modification. > > Why does the linker create .ctor and .dtor segments that are writeble? > These have been fixed so that they cannot be modified. > We've modified atexit() too. It's table of exit functions maintained > by this is no longer writeable by a regular process. The atexit() API > maintains write-protected pages of pointers to exit functions. Ok so it really restrict a lot the possibility of arbitrary code execution when we have vuln_function(); exit(); (since atexit / .dtors are executed after exit() or when main() return).... Well, I just see such vulnerability scenario in some vuln.c made for fun... > And there are other applications of this principle. > All of this serves to make processes more robust in the face of a bug. > > (My main point here is that stack protection by itself might be less > than useful, but add together all the other details above, and you > have created significant constraints for a person trying to take a > regular bug and escalate it towards exploitability) Well, all these protection add a layer of security, but it s still bypassable in 90% of bug. Let's take concret example. So, for me, the last "big" vulnerability release were : - wuftpd remote shell bug - sendmail remote shell bug - openssl remote shell bug I won't covert more issue since we have here a .bss overflow, a heap overflow, and a stack off by one bug. Before continuing, W^X protection don't block exploitation of buffer overflow, they block execution of code on data segment such as stack/heap... ... execution of code is still possible by returning into GOT / PLT / LIB.... so wuftpd permit to overwrite in some case the lsb of the saved_ebp. I don't know much about propolice (I just heard about some method to bypass it;), but lets say that it will block the saved_ebp overwriting... You still can overwrite local variable in other function, and this lead to being able to upload file not only as user anonymous, but as root.... so in this vuln there is a way to cheat. This way isn't generic at all, and some can argue it's very special case, but I believe that such a case can be found in most of vuln exploitation. We just usually to think about it because overwriting a saved_ebp appear more ... erhm ... common way. With this we then can overwrite /bin/ls or any file in ftp that can then lead to arbitrary code execution... For sendmail hole, we can overwrite a function pointer, so we can use ret2libc to mprotect memory and execute shell (seems the easier way)... For openssl code we can overwrite function pointer and use ret2libc too... In all these case exploitation can be done using "targetless" method, so we don't care about what exact version the remote is using... Finnally openbsd protection can all be defeat, and I am sure that in the futur, exploit coders will found some tricks and will still bypass your protection... To finish, PaX ASLR (+grsec) is actually the best protection even written against buffer overflow, even if it is here again bypassable in some way... just take a look at phrack article, or look this : http://mapage.noos.fr/hrchallenge/bpax.tgz And I am not talking here about partial overwriting of pointer or using a bug to create infoleak (read the two good phrack article who explain how to do in the two most common buffer overflow : the stack overflow and the heap overflow). To conclude, all your protection are a good new security layer, but it just stay one security layer, not a full protection... And each time vulnerability will be found in OpenBSD running server, openbsd will be affected as well.... Best regards, Nicolas Brito
This archive was generated by hypermail 2b30 : Thu Aug 14 2003 - 18:10:20 PDT