http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/

[Theo de Raadt]

[bcc'd to Dan Goodin @ theregister]

If anyone wants a choice quote from me about the recent Linux holes,
this is what I have to say:

    Linus is too busy thinking about masturabating monkeys, he doesn't
    have time to care about Linux security.

For the record, this particular problem was resolved in OpenBSD a
while back, in 2008.  We are not super proud of the solution, but it
is what seems best faced with a stupid Intel architectural choice.
However, it seems that everyone else is slowly coming around to the
same solution.

The commit message:

CVSROOT:        /cvs
Module name:    src
Changes by:     deraadt@... 2008/06/24 15:24:03

Modified files:
        sys/arch/alpha/include: vmparam.h
        sys/arch/amd64/include: vmparam.h
        sys/arch/arm/include: vmparam.h
        sys/arch/i386/include: vmparam.h
        sys/arch/sh/include: vmparam.h
        sys/arch/sparc/include: vmparam.h
        sys/arch/vax/include: vmparam.h
        sys/arch/sh/sh : trap.c

Log message:
On user/kernel shared page table machines, do not let processes map their
own page 0, as discussed with miod (and many others previously, including
art and toby).  On sparc, make this __LDPGSZ because PAGE_SIZE is non-constant
ok miod tedu

There are four things interesting about this change:

1) The #1 reason why the Linux team has not commited this by default
   is because it breaks Wine, which wants to play with page 0 -- so
   basically they are resisting this for Windows binary compatibility
   Ironic, isn't it?  If anyone else tells you that is not the #1
   reason, they are lying.  We decided we don't care about Wine.

2) At least three of our developers were aware of this exploitation
   method going back perhaps two years before than the commit, but we
   gnashed our teeth a lot to try to find other solutions.  Clever
   cpu architectures don't have this issue because the virtual address
   spaces are seperate, so i386/amd64 are the ones with the big impact.
   We did think long and hard about tlb bashing page 0 everytime we
   switch into the kernel, but it still does not look attractive from
   a performance standpoint.

3) Last week a bug was found in OpenBSD's kernel which was locally
   exploitable before the commit on Jun 24, 2008.  Afterwards that fix,
   it simply becomes a kernel crash; you cannot gain priviledge from
   it.  The reality is that kernel bugs will always exist, no matter
   how hard we try.  Our focus therefore is always on finding innovative
   ideas which make bugs very hard to exploit succesfully.  Bugs will
   exist.  At least they should be more difficult to exploit.

3) Note the date of the commit, 2008/06/24.  Interestingly, this commit
   was done 1 month before Linus posted this:

   http://article.gmane.org/gmane.linux.kernel/706950

   I'm glad we care about security and trying to make things better, and
   I am glad that Linus prefers to write articles about monkey
   masturbation.  In life, everyone should stick to what they know the
   most about.  Because Linus knows dick all about security research.

[Gilles Chehade-5]

On Tue, Nov 03, 2009 at 04:58:25PM -0700, Theo de Raadt wrote:
> [bcc'd to Dan Goodin @ theregister]
>
> If anyone wants a choice quote from me about the recent Linux holes,
> this is what I have to say:
>
>     Linus is too busy thinking about masturabating monkeys, he doesn't
>     have time to care about Linux security.
>

I was considering offering him this:

http://www.wellcoolstuff.com/Merchant2/graphics/00000001/20-Apr-07-05.jpg

But couldn't get my hands on one yet ;-)

Gilles

--
Gilles Chehade
freelance developer/sysadmin/consultant

                   http://www.poolp.org

[Claire beuserie]

Hi,

On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt <deraadt@...>wrote:

> 2) At least three of our developers were aware of this exploitation
>   method going back perhaps two years before than the commit, but we
>   gnashed our teeth a lot to try to find other solutions.  Clever
>   cpu architectures don't have this issue because the virtual address
>   spaces are seperate, so i386/amd64 are the ones with the big impact.
>   We did think long and hard about tlb bashing page 0 everytime we
>   switch into the kernel, but it still does not look attractive from
>   a performance standpoint.
>

I'm confused.

That came out a bit weird: are you saying you knew about the bug for 2 years
but did not fix it?


c.b-

[Gonzalo Lionel Rodriguez]

2009/11/3 Claire beuserie <claire.beuserie@...>:
> Hi,
>
> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt
<deraadt@...>wrote:

>
>> 2) At least three of our developers were aware of this exploitation
>>   method going back perhaps two years before than the commit, but we
>>   gnashed our teeth a lot to try to find other solutions.  Clever
>>   cpu architectures don't have this issue because the virtual address
>>   spaces are seperate, so i386/amd64 are the ones with the big impact.
>>   We did think long and hard about tlb bashing page 0 everytime we
>>   switch into the kernel, but it still does not look attractive from
>>   a performance standpoint.
>>
>
> I'm confused.
>
> That came out a bit weird: are you saying you knew about the bug for 2

years
> but did not fix it?
>
>
> c.b-
>
>

Linux way.

[Cor-7]

My interpretation is that yes, they identified it as a possibility, but
due to limitations of the Intel platform, there wasn't an obvious,
clean, "correct" way to fix it.

I don't think this is a "primary" exploit, however.  You would have to
have a buffer overflow or something in some other app first.  Fixing
this, as someone stated, mitigates the consequences of other primary
exploits.  But feel free to correct me if I'm wrong (do I really need to
say that? :)

C2

Claire beuserie wrote:

> Hi,
>
> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt <deraadt@...>wrote:
>
>  
>> 2) At least three of our developers were aware of this exploitation
>>   method going back perhaps two years before than the commit, but we
>>   gnashed our teeth a lot to try to find other solutions.  Clever
>>   cpu architectures don't have this issue because the virtual address
>>   spaces are seperate, so i386/amd64 are the ones with the big impact.
>>   We did think long and hard about tlb bashing page 0 everytime we
>>   switch into the kernel, but it still does not look attractive from
>>   a performance standpoint.
>>
>>    
>
> I'm confused.
>
> That came out a bit weird: are you saying you knew about the bug for 2 years
> but did not fix it?
>
>
> c.b-

[Aaron Mason]

On Wed, Nov 4, 2009 at 1:04 PM, Gonzalo Lionel Rodriguez
<gonzalo@...> wrote:

> 2009/11/3 Claire beuserie <claire.beuserie@...>:
>> Hi,
>>
>> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt
> <deraadt@...>wrote:
>>
>>> 2) At least three of our developers were aware of this exploitation
>>>   method going back perhaps two years before than the commit, but we
>>>   gnashed our teeth a lot to try to find other solutions.  Clever
>>>   cpu architectures don't have this issue because the virtual address
>>>   spaces are seperate, so i386/amd64 are the ones with the big impact.
>>>   We did think long and hard about tlb bashing page 0 everytime we
>>>   switch into the kernel, but it still does not look attractive from
>>>   a performance standpoint.
>>>
>>
>> I'm confused.
>>
>> That came out a bit weird: are you saying you knew about the bug for 2
> years
>> but did not fix it?
>>
>>
>> c.b-
>>
>>
>
> Linux way.
>
>

What a knob.  It makes me sad to say I used his crap now if he has
that much contempt for those who value security before practicality.

It's good to see Theo et al stick to their guns on this issue.  I'd
rather have a machine that is secure than one that can run Windows
binaries.

Wine is a good idea, but it's stifling an even better idea - making
applications compatible across multiple OSes, something that hasn't
needed to be done in the M$ world because of the stranglehold they
had/have over the consumer market.

Let's put this into perspective: Linux would absolutely jump in
popularity if Valve ported Steam and the Source engine to it, meaning
games like the Half Life series, Left 4 Dead and Team Fortress 2 could
run natively - not to mention that it would prompt other games that
sell their wares through the Steam CDS to port their games as well -
but since most of the games run just fine in Wine these days, there's
no incentive.

Linus is shooting himself in the foot and he has no idea.  Linux tries
to be everything to everyone, and by doing it the way is does, it
greatly limits its potential.

OpenBSD does one thing and does it well - being secure.  That's all
there is to it.

--
Aaron Mason - Programmer, open source addict
- Oh, why does everything I whip leave me?

[Tobias Ulmer]

On Wed, Nov 04, 2009 at 02:57:59AM +0100, Claire beuserie wrote:

> Hi,
>
> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt <deraadt@...>wrote:
>
> > 2) At least three of our developers were aware of this exploitation
> >   method going back perhaps two years before than the commit, but we
> >   gnashed our teeth a lot to try to find other solutions.  Clever
> >   cpu architectures don't have this issue because the virtual address
> >   spaces are seperate, so i386/amd64 are the ones with the big impact.
> >   We did think long and hard about tlb bashing page 0 everytime we
> >   switch into the kernel, but it still does not look attractive from
> >   a performance standpoint.
> >
>
> I'm confused.
>
> That came out a bit weird: are you saying you knew about the bug for 2 years
> but did not fix it?

It's not "the bug", it's a class of vulnerabilities that allows to
exploit a NULL pointer dereference under certain circumstances.

http://packetstorm.linuxsecurity.com/poisonpen/8lgm/ptchown.c
is commonly cited as the oldest public source (1994). Use google for
more.

>
>
> c.b-

--
Sent from my noname server.

[Scott McEachern]

Theo de Raadt wrote:
>    http://article.gmane.org/gmane.linux.kernel/706950
>
>
>  
I replaced Linux around '01 or '02 with OpenBSD both at companies I've
worked for since and at home.  I don't really care what other people use
for their needs, and I've been neutral in my opinion about Torvalds and
Linux (mostly because I don't pay any attention to what he or anyone
else in the Linux crowd have to say.)  I didn't move to, or stick with,
OpenBSD as an anti-Linux (or anti-anything) statement.

My opinion changed today when I read Linus' email from Theo's link.

Linus seriously thinks that any random bug in any app that causes a
crash is just as important as a security hole that gets your box rooted?

Now I don't just think he's an idiot, I know it.  Now I understand the
background to the disparaging comments Theo has made about Linus now and
then.

--

-RSM

http://www.erratic.ca

[Theo de Raadt]

> Theo de Raadt wrote:
> >    http://article.gmane.org/gmane.linux.kernel/706950
> >
> >
> >  
> I replaced Linux around '01 or '02 with OpenBSD both at companies I've
> worked for since and at home.  I don't really care what other people use
> for their needs, and I've been neutral in my opinion about Torvalds and
> Linux (mostly because I don't pay any attention to what he or anyone
> else in the Linux crowd have to say.)  I didn't move to, or stick with,
> OpenBSD as an anti-Linux (or anti-anything) statement.
>
> My opinion changed today when I read Linus' email from Theo's link.
>
> Linus seriously thinks that any random bug in any app that causes a
> crash is just as important as a security hole that gets your box rooted?
>
> Now I don't just think he's an idiot, I know it.  Now I understand the
> background to the disparaging comments Theo has made about Linus now and
> then.

Don't tell us; we know.

Tell linus.  You can google for his email address.

Not that he'll care.  He's too busy watching monkey porn instead of
building researching last-year's security technology that will stop an
exploit technique that has been exploited multiple times.  He's got
redhat to try to cover for that now, they're a public company filling
his bank account, and the best way to increase his stock is to accuse
other people of having the wrong standards.

Security technology?  Why does he need to bother.  He's got NSA to
write that code for him!  (a previous exploitable hole using this
exploit mechanism was in NSA-donated code.  And God bless America.)

[Bob Beck-4]

2009/11/3 Gilles Chehade <gilles@...>:

> On Tue, Nov 03, 2009 at 04:58:25PM -0700, Theo de Raadt wrote:
>> [bcc'd to Dan Goodin @ theregister]
>>
>> If anyone wants a choice quote from me about the recent Linux holes,
>> this is what I have to say:
>>
>>     Linus is too busy thinking about masturabating monkeys, he doesn't
>>     have time to care about Linux security.
>>
>
> I was considering offering him this:
>
> http://www.wellcoolstuff.com/Merchant2/graphics/00000001/20-Apr-07-05.jpg
>
> But couldn't get my hands on one yet ;-)

God damn Gilles.. And you didn't find one to bring to us at a hackathon!

Linus doesn't *deserve* one of those - I thought because I work on
OpenBSD only I do!

I will be deeply offended if Linus gets one of those before OpenBSD
developers do..  Well, the hell with the rest of you.. *I* at least
want one first.. Proudly!  Linus doesn't deserve one 'till he has a
commit in our tree. ;)

-Bob

[ropers]

From http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/ :

> or desktop environments such as Wine

For some definitions of "desktop environments".

[Artur Grabowski]

Claire beuserie <claire.beuserie@...> writes:

> That came out a bit weird: are you saying you knew about the bug for 2 years
> but did not fix it?

Yes. Because the solution sucks. And all others we tried were just not
workable.

Just like we knew that executable stacks can be used for exploits and
didn't fix that for many years.

//art

[Otto Moerbeek]

On Wed, Nov 04, 2009 at 02:57:59AM +0100, Claire beuserie wrote:

> Hi,
>
> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt <deraadt@...>wrote:
>
> > 2) At least three of our developers were aware of this exploitation
> >   method going back perhaps two years before than the commit, but we
> >   gnashed our teeth a lot to try to find other solutions.  Clever
> >   cpu architectures don't have this issue because the virtual address
> >   spaces are seperate, so i386/amd64 are the ones with the big impact.
> >   We did think long and hard about tlb bashing page 0 everytime we
> >   switch into the kernel, but it still does not look attractive from
> >   a performance standpoint.
> >
>
> I'm confused.
>
> That came out a bit weird: are you saying you knew about the bug for 2 years
> but did not fix it?

Allowing a mapping at address zero is not a bug per se, but it opens a
door for other bugs to be exploited more effectively. This door has
been closed, but only after hard thinking went into how to close it.

        -Otto

[Donald Allen]

On Wed, 4 Nov 2009 at 1:46 PM, Aaron Mason
<simplersolution@...> wrote:

>On Wed, Nov 4, 2009 at 1:04 PM, Gonzalo Lionel Rodriguez
><gonzalo@...> wrote:
>> 2009/11/3 Claire beuserie <claire.beuserie@...>:
>>> Hi,
>>>
>>> On Wed, Nov 4, 2009 at 12:58 AM, Theo de Raadt
>> <deraadt@...>wrote:
>>>
>>>> 2) At least three of our developers were aware of this exploitation
>>>>   method going back perhaps two years before than the commit, but we
>>>>   gnashed our teeth a lot to try to find other solutions.  Clever
>>>>   cpu architectures don't have this issue because the virtual address
>>>>   spaces are seperate, so i386/amd64 are the ones with the big impact.
>>>>   We did think long and hard about tlb bashing page 0 everytime we
>>>>   switch into the kernel, but it still does not look attractive from
>>>>   a performance standpoint.
>>>>
>>>
>>> I'm confused.
>>>
>>> That came out a bit weird: are you saying you knew about the bug for 2
>> years
>>> but did not fix it?
>>>
>>>
>>> c.b-
>>>
>>>
>>
>> Linux way.
>>
>>
>
>What a knob.  It makes me sad to say I used his crap now if he has
>that much contempt for those who value security before practicality.
>
>It's good to see Theo et al stick to their guns on this issue.  I'd
>rather have a machine that is secure than one that can run Windows
>binaries.
>
>Wine is a good idea, but it's stifling an even better idea - making
>applications compatible across multiple OSes, something that hasn't
>needed to be done in the M$ world because of the stranglehold they
>had/have over the consumer market.
>
>Let's put this into perspective: Linux would absolutely jump in
>popularity if Valve ported Steam and the Source engine to it, meaning
>games like the Half Life series, Left 4 Dead and Team Fortress 2 could
>run natively - not to mention that it would prompt other games that
>sell their wares through the Steam CDS to port their games as well -
>but since most of the games run just fine in Wine these days, there's
>no incentive.
>
>Linus is shooting himself in the foot and he has no idea.  Linux tries
>to be everything to everyone, and by doing it the way is does, it
>greatly limits its potential.
>
>OpenBSD does one thing and does it well - being secure.  That's all
>there is to it.

I think that sells OpenBSD unintentionally short. Yes, the attention
to security is of enormous value, but the care and intelligence that
characterizes the whole effort results in a system that is extremely
stable, very easy to administer, and very well documented. It is the
only system I know of, and I've tried almost all of them, that pays
attention to the things that really matter. The result is an
environment where you do your work, rather than fighting with your
tools. I replaced Linux on three laptops and a workstation with
OpenBSD (after a quick divorce from FreeBSD -- too many bugs) that I use
for general computing tasks including a lot of software development
and database work, and you couldn't pay me to go back.

I realize that I'm preaching to the choir -- you know all this. But I
think it's a mistake for (especially) the OpenBSD community to speak
of OpenBSD as just about security, when it's so much more than that.

/Don Allen

>
>--
>Aaron Mason - Programmer, open source addict
>- Oh, why does everything I whip leave me?

[Stefan Wollny]

> -----Urspr|ngliche Nachricht-----
> Von: "Donald Allen" <donaldcallen@...>
> Gesendet: 04.11.09 14:23:04
> An: misc@...
> Betreff: Re:
http://www.theregister.co.uk/2009/11/03/linux_kernel_vulnerability/

<Don Allen wrote>
...

> I realize that I'm preaching to the choir -- you know all this. But I
> think it's a mistake for (especially) the OpenBSD community to speak
> of OpenBSD as just about security, when it's so much more than that.

I second that - it is the attitude of how the devs (and Theo in particular)
strive for a clean code and fight the temptation to implement a 'twist' only
to allow some poorly written app to run on OpenBSD. Remember the outcry some
years ago when a change broke backward compatibility disabling some poorly
written apps to run under OpenBSD since then? 'Security' is just another
result out of this firm stand for their believes.

BTW: Anyone around who has not yet bought his set of CDs? Believe me - this is
a clever investment in future development and a fine way saying THANK YOU!

STEFAN

Mail: stefan@...
GnuPG-Key ID: 0x9C26F1D0

[Egon E. Braun Filho]

On Wed, 4 Nov 2009 13:46:26 +1100
Aaron Mason <simplersolution@...> wrote:

> Wine is a good idea, but it's stifling an even better idea - making
> applications compatible across multiple OSes, something that hasn't
> needed to be done in the M$ world because of the stranglehold they
> had/have over the consumer market.
>

Microsoft will not follow free standanrds, Linux will follow
Microsoft/IBM/Intel/W3C/bullshit_human_slaving_private standards.

And I believe that is not portability in no way. That is just
assassinating legacy and freedom.

> Let's put this into perspective: Linux would absolutely jump in
> popularity if Valve ported Steam and the Source engine to it, meaning
> games like the Half Life series, Left 4 Dead and Team Fortress 2 could
> run natively - not to mention that it would prompt other games that
> sell their wares through the Steam CDS to port their games as well -
> but since most of the games run just fine in Wine these days, there's
> no incentive.

This will happen. We just have to wait for Linus/Redhat/Suse/etc to sign
more NDAs.

Look after your kids.

--
Egon E. Braun Filho <egonbraun@...>

[MUNDOALEM.com]

On Wed, 4 Nov 2009 13:46:26 +1100
Aaron Mason <simplersolution@...> wrote:

> Wine is a good idea, but it's stifling an even better idea - making
> applications compatible across multiple OSes, something that hasn't
> needed to be done in the M$ world because of the stranglehold they
> had/have over the consumer market.
>

Microsoft will not follow free standanrds, Linux will follow
Microsoft/IBM/Intel/W3C/bullshit_human_slaving_private standards.

And I believe that is not portability in no way. That is just
assassinating legacy and freedom.

> Let's put this into perspective: Linux would absolutely jump in
> popularity if Valve ported Steam and the Source engine to it, meaning
> games like the Half Life series, Left 4 Dead and Team Fortress 2 could
> run natively - not to mention that it would prompt other games that
> sell their wares through the Steam CDS to port their games as well -
> but since most of the games run just fine in Wine these days, there's
> no incentive.

This will happen. We just have to wait for Linus/Redhat/Suse/etc to sign
more NDAs.

Look after your kids.

--
Egon E. Braun Filho <mundoalem@...>

[henry.sieff]

On Wed, Nov 4, 2009 at 5:18 AM, Donald Allen <donaldcallen@...> wrote:

[SNIP]

> I realize that I'm preaching to the choir -- you know all this. But I
> think it's a mistake for (especially) the OpenBSD community to speak
> of OpenBSD as just about security, when it's so much more than that.

I think I would rephrase that - OpenBSD is just about security, and
security implies far more than simply patching holes. Stability,
administrative transparency, and thorough documentation are all
critical and overly neglected aspects of security. If you don't know
the proper way to configure feature X, you cannot be sure it is
configured securely.

OpenBSD simply looks at security in a holistic fashion, while every
other OS I have to suffer through views security as a 'feature'.

[Donald Allen]

On Wed, Nov 4, 2009 at 1:48 PM, Henry Sieff <henry.sieff@...> wrote:

> On Wed, Nov 4, 2009 at 5:18 AM, Donald Allen <donaldcallen@...> wrote:
>
> [SNIP]
>
>> I realize that I'm preaching to the choir -- you know all this. But I
>> think it's a mistake for (especially) the OpenBSD community to speak
>> of OpenBSD as just about security, when it's so much more than that.
>
> I think I would rephrase that - OpenBSD is just about security, and
> security implies far more than simply patching holes. Stability,
> administrative transparency, and thorough documentation are all
> critical and overly neglected aspects of security. If you don't know
> the proper way to configure feature X, you cannot be sure it is
> configured securely.
>
> OpenBSD simply looks at security in a holistic fashion, while every
> other OS I have to suffer through views security as a 'feature'.

Perhaps. I don't presume to know enough about what Theo and the other
developers think or how the development is done to have an opinion on
that. But my point is that whether your assertion is true or not, the
net result is the best platform for general computing that I know of,
and not just in situations where security concerns are (or should be)
paramount. OpenBSD has been a type-cast as a smart choice in
high-vulnerability situations (where you certainly wouldn't dare use
Windows or Linux), which is true, but the problem is that the
descriptions tend to *limit* its usefulness or applicability to such
situations, leading to questions like "does OpenBSD run on a laptop?".
My point is that OpenBSD is also the best choice (except if you care a
lot about Flash :-) in situations where you *would* dare to use
Windows or Linux . If I were doing software development on a machine
located in a bank vault with no network connection, that machine would
be running OpenBSD.

/Don

[Tomas Bodzar-4]

Ok to add more idiotic ideas to debate about Linux/MS and
interoperability and so on why not add this one?

http://www.computerworlduk.com/community/blogs/index.cfm?entryid=2620&blogid=
14

EU Wants to Re-define bClosedb as bNearly Openb

'.........While there is a correlation between openness and
interoperability, it is also true that interoperability can be
obtained without openness, for example via homogeneity of the ICT
systems, which implies that all partners use, or agree to use, the
same solution to implement a European Public Service..........'

On Wed, Nov 4, 2009 at 5:39 PM, Egon E. Braun Filho <egonbraun@...>
wrote:

> On Wed, 4 Nov 2009 13:46:26 +1100
> Aaron Mason <simplersolution@...> wrote:
>
>> Wine is a good idea, but it's stifling an even better idea - making
>> applications compatible across multiple OSes, something that hasn't
>> needed to be done in the M$ world because of the stranglehold they
>> had/have over the consumer market.
>>
>
> Microsoft will not follow free standanrds, Linux will follow
> Microsoft/IBM/Intel/W3C/bullshit_human_slaving_private standards.
>
> And I believe that is not portability in no way. That is just
> assassinating legacy and freedom.
>
>> Let's put this into perspective: Linux would absolutely jump in
>> popularity if Valve ported Steam and the Source engine to it, meaning
>> games like the Half Life series, Left 4 Dead and Team Fortress 2 could
>> run natively - not to mention that it would prompt other games that
>> sell their wares through the Steam CDS to port their games as well -
>> but since most of the games run just fine in Wine these days, there's
>> no incentive.
>
> This will happen. We just have to wait for Linus/Redhat/Suse/etc to sign
> more NDAs.
>
> Look after your kids.
>
> --
> Egon E. Braun Filho <egonbraun@...>
>
>

--
http://www.openbsd.org/lyrics.html