Full Disclosure mailing list archives
Re: Linux Kernel CIFS Vulnerability
From: Andreas Bogk <andreas () andreas org>
Date: Fri, 10 Apr 2009 13:27:30 +0200
Dear Moustache, I very much appreciate your attempt to make me sleep better at night. Unfortunately, I know too much already about the harsh reality for your attempts to be successful. Take the PageExec approach for instance. It may seem to the uninitiated that making data pages, especially the stack, non-executable, might protect against exploitation of overflow conditions. However, as any seasoned hacker will be able to tell you, there is the return-to-libc approach. But what if there is no ready-made routine that does what the attacker wants, you might ask? Especially since we're dealing with the kernel here, which doesn't feature a libc? There has been a solution to this problem for some years now, based on the insight that one doesn't necessarily have to call whole functions when one can call function epilogues, carefully chosen to provide the desired function such as loading or storing registers and doing calculations, and then chain them by placing their addresses next to each other on the stack. Writing exploits like this might seem like a tedious task. However, once you realize that you can treat function epilogues as a sort of virtual machine, the road is open to write a compiler that targets this VM. Mr. Shacham, a distinguished scholar, has demonstrated the feasibility of this approach, and presented a merge sort payload written in this manner in his BH talk: https://media.blackhat.com/bh-usa-08/video/bh-us-08-Shacham/black-hat-usa-08-shacham-return-oriented-programming-hires.m4v Non-executable data pages do not make me sleep better at night, no. As for the ASLR component of PageExec: in kernel space, which is what we're talking about here, it only applies to the stack, and locating the address of my stack is not only trivial, but even required in the absence of ASLR too. So it doesn't make a difference. As for the gotroot access control and kernel hardening: I don't quite understand how those are going to help me when I'm pwning the kernel at ring 0. As for the choice of which of the four evils is the least evil, it somehow feels like being asked whether you want your shit served with strawberries or whether you prefer your shit with honey topping. It's still brown and smells bad. In the presence of fundamental architectural braindeadness (and remember, UNIX and C were designed so that two bearded freaks at AT&T wouldn't have to explain their bosses why they burned valuable and accounted processor time on a Multics machine for a process named "SpaceWars"), the saner disclosure policy actually can make a difference. In the long run, my bet is on Midori. And the Open Source people better get off their high horses and lazy asses, and start a comparable project, or whither and die. Bonus 0day for those who kept reading through all this: the patch to the CIFS vuln is wrong, and the current kernel is still vulnerable. The length parameter we're getting passed is the number of characters in a UCS2 string, and the target string format is UTF8. *2 is not enough, *3 + 1 should be. Yours faithfully, Andreas Valdis' Mustache schrieb:
Andrea, Do not be alarmed! At the time of this writing, my owner is fervently developing a response on this topic! It is a response which I have no doubt will apply a virtual salve to all of your bugbears, and assuage other tangential (and even unrelated) concerns as well. Nonetheless, I feel compelled ejaculate on this topic myself - albeit prematurely - since my response predates the presumably forthcoming warnings soon to issue from the varied and sundry organisations who bundle the Linux kernel distribution with their own customized versions of Tuxpaint and SameGnome. On to the point. I must assert that despite the sadly DeRaadtian handling of this bug, a choice to run the Linux kernel and related software bundled with it still remains a sound choice from a security standpoint. This remains especially veritable if the Linux kernel in question is improved with the addition of the excellent PageExec extensions, as developed by an anonymous (and rumors have it, bemustached) gentleman in Eastern Europe, and the unfortunately-named GotRoot access control and kernel hardening modules, authored by a lovable misfit ensconced somewhere in the bowels of a sanitarium in Maryland. While the whims of Finns remain - as ever - unfathomable and abstruse, this mustache stands firm as a believer that the selection of Linux is the lesser of the four evils (BSD, Linux, Windows, and, least of all, Apple) servicably available for my hairy computing choices. Your Humble Servant, A bajusz a Valdis On Thu, Apr 9, 2009 at 9:52 AM, Andreas Bogk <andreas () andreas org> wrote:Thierry Zoller wrote:AB> Neither the Linux kernel team, the CIFS maintainers nor any of AB> the commercial Linux distributors bothered to send out an advisory. AB> I'm at loss for words other than "irresponsible, arrogant AB> assholes". Linux 2009 == Microsoft 2002. I second that, the reason is intersintg too; linus considers security bugs as nothing else than normal bugs.I don't mind his policy of "just fixing the bug". But I do mind when the changelog doesn't clearly state "hey, we're fixing a security issue here".The door closes slowly for Linux in enterprises.So true, and so sad. I remember a time when using Linux was giving actual security benefits over using Windows. These times are over. And the security gap between MS and Open Source products will continue to widen. The only OS project I know about that seriously tried to improve fundamental architectural security issues was BitC and CoyotOS. BitC is a programming language designed to combine the speed of C with the soundness of strongly typed fundamental languages, thus preventing a lot of bug classes from the start, and enabling correctness proofs across the code. The project won't be finished, since the main author, Jonathan Shapiro, will soon hold a "fairly senior position" in the Midori project at MS. Andreas _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Linux Kernel CIFS Vulnerability Andreas Bogk (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Andreas Bogk (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Valdis' Mustache (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Andreas Bogk (Apr 10)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Raj Mathur (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Nick Boyce (Apr 09)
- Re: Linux Kernel CIFS Vulnerability Marcus Meissner (Apr 10)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 10)
- Re: Linux Kernel CIFS Vulnerability Marcus Meissner (Apr 10)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 10)
- Re: Linux Kernel CIFS Vulnerability Eugene Teo (Apr 11)
- Re: Linux Kernel CIFS Vulnerability Andreas Bogk (Apr 13)
- Re: Linux Kernel CIFS Vulnerability Eugene Teo (Apr 13)
- Re: Linux Kernel CIFS Vulnerability Thierry Zoller (Apr 10)