NEWS - Hole in the Linux kernel allows root access (buh-by..

"Rick" <nomail RemoveThis @none.invalid> schreef in bericht
news:AaednQ1P-otERGzXnZ2dnUVZ_gli4p2d@supernews.com...
> John Fuhrer wrote:
>> On Wed, 4 Nov 2009 12:42:45 -0500, Ezekiel wrote:
>>
>>> "PeterKöhlmann" <peter-koehlmann RemoveThis @t-online.de> wrote in message
>>> news:hcsdp8$c2p$02$1@news.t-online.com...
>>>> Ezekiel wrote:
>>>>
>>>>> "Peter K�hlmann" <peter-koehlmann RemoveThis @t-online.de> wrote in message
>>>>> news:hcs9j3$hdv$03$1@news.t-online.com...
>>>>>> John Fuhrer wrote:
>>>>>>
>>>>>>> On Wed, 4 Nov 2009 10:54:55 -0500, Ezekiel wrote:
>>>>>>>
>>>>>>>> "John Fuhrer" <fuhrer_spam_no_joh RemoveThis @yahoo.com> wrote in message
>>>>>>>> news:rn8qjdtr4m75$.k2apbnabme3d$.dlg@40tude.net...
>>>>>>>>> On Wed, 4 Nov 2009 09:57:23 -0500, Ezekiel wrote:
>>>>>>>>>
>>>>>>>>>> But Kohltard insisted that it's perfectly legal to dereference a
>>>>>>>>>> NULL pointer so this can't be a real bug, can it?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <quote>
>>>>>>>>>> 4 November 2009, 13:54
>>>>>>>>>> Hole in the Linux kernel allows root access
>>>>>>>>>>
>>>>>>>>>> A null pointer dereference in the Linux kernel can be exploited
>>>>>>>>>> to
>>>>>>>>>> access a
>>>>>>>>>> system at root privilege level. The hole is reportedly contained
>>>>>>>>>> in
>>>>>>>>>> pipe.c
>>>>>>>>>> and can occur in certain circumstances when using the
>>>>>>>>>> pipe_read_open(), pipe_write_open() or pipe_rdwr_open() functions
>>>>>>>>>> while releasing a mutex (mutual exclusion) too early - which
>>>>>>>>>> constitutes a classic race condition.
>>>>>>>>>> So far, the flaw has only been fixed in release candidate 6 of
>>>>>>>>>> the
>>>>>>>>>> forthcoming version 2.6.32.
>>>>>>>>>>
>>>>>>>>>> </quote>
>>>>>>>>>>
>>>>>>>>>> http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-
>>>>>> allows-root-access-850016.html
>>>>>>>>> http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-
>>>>>> allows-root-access-850016.html
>>>>>>>>> Kohlmann got his a$$ seriously kicked in COLA yesterday.
>>>>>>>>> Between the nvidia "just works" with Ubuntu 9.10 and his idiotic
>>>>>>>>> statement
>>>>>>>>> about server Linux vs desktop Linux, it's been a bad day.
>>>>>>>>>
>>>>>>>>> So now he gets rope-a-doped again.
>>>>>>>>>
>>>>>>>>> Poor Peter.
>>>>>>>>> How can we help?
>>>>>>>> Next he'll be telling people that Finale can't do music
>>>>>>>> composition.
>>>>>>>> Oh wait... he did that too.
>>>>>> Well, it can't
>>>>> Don't let little things like the FACT that Finale won 1st place as the
>>>>> best music composition software get in way of your idiotic ramblings.
>>>> It still does not composition. It simply *helps* composers, but it does
>>>> not do composition by itself. *No* music notation software does
>>> Well DUH!!! Your defense is to now claim that all along you were
>>> arguing about the application composing music all "by itself." The
>>> obvious point that it's software that allows musicians to do composition
>>> never occurred to you - you thought the music would just write itself?
>>> Do we also need to point out that it has to be a "live" musician in
>>> order for the software to work and that it can't magically compose music
>>> for Mozart?
>>>
>>>
>>>
>>>> This is true for basically all music notation software.
>>> Yeah - it's basically true that people have to use the software to
>>> compose music. The software can't do it all "by itself."
>>
>>
>> Kohlmann is dancing like a drunk Luftwaffe pilot.
>> Between the nvidia thread, the null pointer thread and his idiotic Finale
>> cock up.
>>
>> He has a serious problem admitting when he is wrong.
>
> ... except that Finale doesn't "do composition" any more than quill, ink
> and paper do.


Your a stupid one, battling with Kohlmann on stupidity, huh!
A gem like Finale for a lousy $600.00
Talk with Marti about your "ink and paper" idiocy, Marti chooses Linux for
his compositions, that's *his* choice.
Marti is a Linux advocate, Kohlmann and you are not and never will be
advocates!, you pigheaded twit!

On Wed, 04 Nov 2009 12:30:00 -0800, Tim Smith wrote:

> In article <hcs4i7$a1b$1@news.eternal-september.org>,
> "Ezekiel" <zeke.TakeThisOut@nosuchdomain.com> wrote:
>
>> But Kohltard insisted that it's perfectly legal to dereference a NULL
>> pointer so this can't be a real bug, can it?
>
> Actually, I believe what he insisted on in the incident you are
> referring to was that the code in question did not dereference a null
> pointer. It was his understanding (or lack thereof) of C that he failed
> on there, not his understanding of the legality of null pointer
> dereferencing.

Props.

--
// This is my opinion.

On Nov 5, 6:36 am, Lusotec <nom....RemoveThis@nomail.not> wrote:
> cc wrote:
> > On Nov 4, 11:49 am, Lusotec <nom....RemoveThis@nomail.not> wrote:
> >> Ezekiel wrote:
> >> > But Kohltard insisted that it's perfectly legal to dereference a NULL
> >> > pointer so this can't be a real bug, can it?
>
> >> In kernel space, it is perfectly legal (and a necessity) to dereference a
> >> NULL (ZERO) pointer or this would not result in a exploit but a
> >> crash/panic/oops.
>
> > How is it a necessity? Since the Linux kernel is written in C, it is
> > legal in the sense that it is undefined behavior, so gcc or whatever
> > implementation you're using to compile could define it however they
> > choose, which is why it results in an exploit and not a crash. Note
> > that a NULL pointer does not have to correspond to address zero, but
> > NULL==0. So if you think it's necessary because the kernel needs
> > access to 0, then you're completely mistaken. So I'm not sure why it's
> > necessary.
>
> NULL is defined as ZERO and the kernel needs to access that part of memory.
> You are right that NULL does not have to be ZERO, but in this case it is,
> thus my comment.
>
> Regards.

It does not matter what it is defined as, a NULL pointer does not have
to be dereferenced to access address 0 (or whatever it is defined as).
Check any number of C FAQs.

Lusotec pulled this Usenet boner:

> Ezekiel wrote:
>> Lusotec wrote:
>>> Chris Ahlstrom wrote:
>>>> Lusotec pulled this Usenet boner:
>>>>>
>>>>> Can anyone check mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) on your
>>>>> Red Hat and/or Debian systems?
>>>>
>>>> Debian squeeze 32-bit: 4096
>>>> Debian squeeze 64-bit: 4096
>>>> Fedora 11 64-bit: 65536
>>>
>>> On all systems I manage: 1048576 (1MiB)
>>> On Mandriva by default: 4096 (4KiB)
>>
>> On two Ubuntu 8.04 installs it's 65536
>>
>> but on Debian 5.0 it's:
>> 0
>> zeke@debian:~$ uname -a
>> Linux debian 2.6.26-2-686 #1 SMP Sat Oct 17 17:59:23 UTC 2009 i686
>
> Thank you, Ezekiel.
>
> It is curious that Debian decided to set mmap_min_addr to zero.

I thought the article said that some Wine functionality needed that setting.

Of course, with Debian, they may have had a brain fart that they corrected
in squeeze.

> If some
> program needs it, then set it only when that program is installed and warn
> the user about it. Setting it to zero by default is a bad idea. The safety
> net provided by mmap_min_addr should not be removed unless absolutely
> needed. These kinds of bugs in the kernel and programs are unlikely to
> disappear any time soon.

Huh? Once found, I'm sure they're fixed rather quickly. I know what you
mean, though.

--
You will win success in whatever calling you adopt.

cc wrote:

> On Nov 4, 11:49 am, Lusotec <nom....TakeThisOut@nomail.not> wrote:
>> Ezekiel wrote:
>> > But Kohltard insisted that it's perfectly legal to dereference a NULL
>> > pointer so this can't be a real bug, can it?
>>
>> In kernel space, it is perfectly legal (and a necessity) to dereference a
>> NULL (ZERO) pointer or this would not result in a exploit but a
>> crash/panic/oops.
>
> How is it a necessity? Since the Linux kernel is written in C, it is
> legal in the sense that it is undefined behavior, so gcc or whatever
> implementation you're using to compile could define it however they
> choose, which is why it results in an exploit and not a crash. Note
> that a NULL pointer does not have to correspond to address zero, but
> NULL==0. So if you think it's necessary because the kernel needs
> access to 0, then you're completely mistaken. So I'm not sure why it's
> necessary.

NULL is defined as ZERO and the kernel needs to access that part of memory.
You are right that NULL does not have to be ZERO, but in this case it is,
thus my comment.

Regards.

Ezekiel wrote:
> Lusotec wrote:
>> Chris Ahlstrom wrote:
>>> Lusotec pulled this Usenet boner:
>>>> <quote>
>>>> However, like previous null pointer dereference issues in the Linux
>>>> kernel, the vulnerability can only be exploited if the kernel's
>>>> mmap_min_addr system variable is set to 0. mmap_min_addr describes the
>>>> lowest virtual address a process can use for mapping. If it is greater
>>>> than 0, exploits that involve a null-valued pointer to this address
>>>> won't
>>>> work. </quote>
>>>> <http://www.h-online.com/open/news/item/Hole-in-the-Linux-kernel-
>>>> allows-root-access-850016.html>
>>>>
>>>> I find it strange that Red Hat would set mmap_min_addr to 0 because of
>>>> Wine or DOSEMU. First, Wine works with a non zero mmap_min_addr, at
>>>> least
>>>> in all systems I ever used Wine. Second, Red Hat is mostly used on
>>>> servers and Wine or DOSEMU have no place there.
>>>>
>>>> Can anyone check mmap_min_addr (cat /proc/sys/vm/mmap_min_addr) on your
>>>> Red Hat and/or Debian systems?
>>>
>>> Debian squeeze 32-bit: 4096
>>> Debian squeeze 64-bit: 4096
>>> Fedora 11 64-bit: 65536
>>
>> Thank you, Chris.
>>
>> On all systems I manage: 1048576 (1MiB)
>> On Mandriva by default: 4096 (4KiB)
>
> On two Ubuntu 8.04 installs it's 65536
>
> but on Debian 5.0 it's:
>
> zeke@debian:~$ cat /proc/sys/vm/mmap_min_addr
> 0
> zeke@debian:~$ uname -a
> Linux debian 2.6.26-2-686 #1 SMP Sat Oct 17 17:59:23 UTC 2009 i686
> GNU/Linux

Thank you, Ezekiel.

It is curious that Debian decided to set mmap_min_addr to zero. If some
program needs it, then set it only when that program is installed and warn
the user about it. Setting it to zero by default is a bad idea. The safety
net provided by mmap_min_addr should not be removed unless absolutely
needed. These kinds of bugs in the kernel and programs are unlikely to
disappear any time soon.

Regards.

Chris Ahlstrom wrote:
> Lusotec pulled this Usenet boner:
>> It is curious that Debian decided to set mmap_min_addr to zero.
>
> I thought the article said that some Wine functionality needed that
> setting.

I run Wine with mmap_min_addr=1MiB without problems.

>> If some
>> program needs it, then set it only when that program is installed and
>> warn the user about it. Setting it to zero by default is a bad idea. The
>> safety net provided by mmap_min_addr should not be removed unless
>> absolutely needed. These kinds of bugs in the kernel and programs are
>> unlikely to disappear any time soon.
>
> Huh? Once found, I'm sure they're fixed rather quickly. I know what you
> mean, though.

These kinds of bugs are very easy to fix once they are found but the problem
is the time between someone with bad intentions finding a way to exploit the
bug and the bug being patched in all the systems. That can be a windows of
time more than enough to cause lots damage.

That is why multiple layers of protection are a must. Even if one or more
protective layers have holes the remaining layers will still protect the
system.

Simply discarding layers for convenience is a bad approach. Setting
mmap_min_addr to a large enough value can easily protect the kernel and
applications from an important class of exploitable bugs. This alone should
be enough for people not to mess with it without a very good reason.

Regards.

On Nov 5, 1:08 pm, Lusotec <nom... RemoveThis @nomail.not> wrote:
> Hadron wrote:
> > Lusotec writes:
> >>> It does not matter what it is defined as, a NULL pointer does not have
> >>> to be dereferenced to access address 0 (or whatever it is defined as)..
> >>> Check any number of C FAQs.
>
> >> If a null pointer is equal to a zero pointer (the most common case) then
> >> directly, or indirectly, a null pointer has to be used to access address
> >> zero, even if the zero pointer is the result of some pointer arithmetic's
> >> or indexing.
>
> > Meanwhile in the real world 99.9999999999999% of compiler/HW
> > combinations the NULL pointer is indeed simply "0".
>
> It is *null* pointer, not "NULL pointer". NULL is a constant.
>
> > I'm not sure what your reason is. The access of address 0 is well known
> > but does not, as you claim, make accessing via a null pointer
> > "necessary".
>
> If a null pointer is equal to a zero pointer then accessing address zero,
> directly or indirectly, uses a null pointer since null and zero pointers are
> exactly the same. How hard is this to understand!


They are not the same. A compiler does not have to compile a pointer
set to 0 (NULL) that is then accessed. A compiler does have to compile
any number of equivalent, but well defined alternatives (memset,
unions).

> > Dereferencing a null pointer in C leads to undefined
> > behaviour. End of story.
>
> Meanwhile in the real world, 99.9999999999999% of compiler/HW
> combinations, dereferencing a null pointer is well defined.
>

Yes, it's defined as undefined behavior. That's why gcc optimized away
a NULL check after a pointer had already been dereferenced, which lead
to a previous kernel exploit.

Hadron pulled this Usenet boner:

> Apparently him and Chris "craft world class code".

Thanks for the vote of confidence, "Hadron", but, no, I have never claimed
to "craft world class code".

To me, the term "craft" refers to taking the time and effort to do things
right. It says nothing about the quality of the code the results... even a
craftsman can be mistaken. And a craftsman can work hard and still produce
code that is not "world class" -- it may be too limited in what it does, or
too non-standard for others to use or to want to use.

I enjoy crafting code. I work hard at it, as you would know if you have
found my publicly posted project and perused the source code, documentation,
and scripts that accompany it.

But in no way do I claim to be a crafter of world-class code. That would be
for someone else to decide.

--
Nothing so needs reforming as other people's habits.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"

Ezekiel wrote:

[snip local root exploit]

FYI: once someone has physical access to a Linux box, they almost always
have root access as well. So this "buh-bye security" story is wildly
exaggerated, to say the least.

The tricky thing is to remotely compromise a Linux box -- which usually
means you have to get users to execute your virus code. This is where Linux
is more secure than Windows, because Linux users do not expect to download
and execute code in order to get something done.
The most common cause of Linux security problems is sloppy maintenance, with
server admins leaving vulnerable scripts in place.

Anyway, until a significant portion of all Linux machines gets compromised
(more than, say, 1%), even an idiot can see that Linux is vastly more
secure than Windows (with a near 60% infection rate worldwide).

Richard Rasker
--
http://www.linetec.nl

cc wrote:
> Lusotec wrote:
>> NULL is defined as ZERO and the kernel needs to access that part of
>> memory. You are right that NULL does not have to be ZERO, but in this
>> case it is, thus my comment.

One correction to what I wrote before. NULL is always defined as ZERO but a
null pointer is not required to be equal to a zero pointer, but usually is.

> It does not matter what it is defined as, a NULL pointer does not have
> to be dereferenced to access address 0 (or whatever it is defined as).
> Check any number of C FAQs.

If a null pointer is equal to a zero pointer (the most common case) then
directly, or indirectly, a null pointer has to be used to access address
zero, even if the zero pointer is the result of some pointer arithmetic's or
indexing.

Regards.

On Nov 5, 4:42 pm, Chris Ahlstrom <ahlstr... DeleteThis @launchmodem.com> wrote:
>
>
> Code like the following looks like a dereference, but won't cause a
> fault, because it is not a dereference:
>
>    int * n = NULL;
>    int * p;
>    p = &*n;
>
> Item 1092 from the same book.

That's in the C standard as well I believe. It's just p=n. What
Lusotec was saying was that any way to get to address 0 was equal, but
that's not true.

int* p=NULL;
int i =*p; /* undefined behavior */

int* p=0;
int i=*p; /* undefined behavior */

union
{
int *u_p;
int u_i;
} p;
p.u_i = 0;
int i = *p.u_p; /* not undefined behavior */

int* p;
memset((void *)&p, 0, sizeof(p));
int i=*p; /* not undefined behavior */


Regardless of the implemenation's value of a null pointer, all of the
above is always true.

Hadron pulled this Usenet boner:

> Meanwhile in the real world 99.9999999999999% of compiler/HW
> combinations the NULL pointer is indeed simply "0".

Wrong.

Debugging implementations that make use of a processor's automatic
hardware checking (if available) of address accesses may have a separate
representation (e.g., offset zero and a unique segment value) for every
null pointer constant in the source. (This enables runtime checks to
trace back dereferences of the null pointer constant to the point
in the source that created the constant.) (item 750)

http://www.coding-guidelines.com/cbook/cbook1_2.pdf

> I'm not sure what your reason is. The access of address 0 is well known
> but does not, as you claim, make accessing via a null pointer
> "necessary". Dereferencing a null pointer in C leads to undefined
> behaviour. End of story.

Code like the following looks like a dereference, but won't cause a
fault, because it is not a dereference:

int * n = NULL;
int * p;
p = &*n;

Item 1092 from the same book.

By the way, that book is pretty eye-opening as to just how many ways both
compilers and hardware can represent the "null pointer".

--
Your aim is high and to the right.