Message-ID: <49DF2D22.30907@andreas.org>
Date: Fri, 10 Apr 2009 13:27:30 +0200
From: Andreas Bogk <andreas@...reas.org>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Linux Kernel CIFS Vulnerability

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@...reas.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/

Powered by blists - more mailing lists