Spec#, nullables and more

Daniel Gibson metalcaedes at gmail.com
Fri Nov 26 11:20:15 PST 2010


Bruno Medeiros schrieb:
> On 25/11/2010 16:55, Daniel Gibson wrote:
>> On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
>> <brunodomedeiros+spam at com.gmail>  wrote:
>>> On 05/11/2010 18:52, Daniel Gibson wrote:
>>>>
>>>> Walter Bright schrieb:
>>>>>
>>>>>
>>>>> It's infinitely worse. Null pointers do not result in memory
>>>>> corruption, buffer overflows, and security breaches.
>>>>>
>>>>
>>>> Not entirely true: Null Pointer dereferences *have* been used for
>>>> security breaches, see for example: http://lwn.net/Articles/342330/
>>>> The problem is that one can mmap() to 0/NULL so it can be dereferenced
>>>> without causing a crash.
>>>>
>>>> Of course this is also a problem of the OS, it shouldn't allow 
>>>> mmap()ing
>>>> to NULL in the first place (it's now forbidden by default on Linux and
>>>> FreeBSD afaik) - but some software (dosemu, wine) doesn't work 
>>>> without it.
>>>>
>>>> Cheers,
>>>> - Daniel
>>>
>>> I think Walter's point remains true: null pointers bugs are an order of
>>> magnitude less important, if not downright insignificant, with 
>>> regards to
>>> security breaches.
>>
>> No, that wasn't his point - he thought it was *impossible* to exploit 
>> null
>> pointers ("Null pointers do not result in memory corruption, buffer 
>> overflows,
>> and security breaches.") and I merely pointed out that this is not 
>> correct.
>> I didn't say anything about significance for average applications :-)
>>
> 
> Yes, Walter's statement that it is impossible for a null pointer to 
> cause a security vulnerability is (likely) incorrect.
> But his point at large, considering the discussion that preceded the 
> comment, was that null pointers are utterly insignificant with regards 
> to security vulnerabilities.
> 
> And I agree with that, and because of that I'm suprised and curious to 
> understand why Hoare mentioned (in the abstract on the link posted 
> originally), that null pointers have caused "innumerable vulnerabilities.
> 

I don't know for sure, but I guess there have been multiple vulnerabilities in 
kernel code (of different operating systems) caused by null pointers.
So it may not affect most programmers (that don't do kernel stuff), but there 
are still a lot of (?) vulnerabilities caused by that. And those are bad, 
because you mess within the kernel, so you can do *anything*.

> 
>>>
>>> I mean, from my understanding of that article, a NPE bug on its own 
>>> is not
>>> enough to allow an exploit, but other bugs/exploits need to be be 
>>> present.
>>
>> Well it could be used by a non-privileged user to get root privileges.
>> If you only have "friendly" non-privileged users you need an exploit
>> to make them
>> execute the kernel exploit, of course.
>>
>> But I agree that this kind of bug is not as relevant as others (for 
>> most users)
>>   - you won't have it in regular programs but only in kernels I guess.
>> (Of course it could work in regular programs as well, but you won't 
>> get more
>> privileges then you had before. Also I may be completely wrong on this 
>> and
>> maybe there is some way to gain something by using this kind of exploit
>> on regular programs.)
>>
> 
> By "exploit", I didn't mean to necessarily imply privilege escalation. I 
> meant arbitrary code execution, with or without privilege escalation. (I 
> don't know if this usage of the term is common in the security 
> community, maybe not)

Yes. I guess (haven't dug too far into this) that NP dereferences are mostly 
used to exploit the kernel, because you mmap() to NULL in the unprivileged 
userland program and this mmap() affects kernel code.
I don't know if it's possible to have mmap() affect userland programs other than 
the one that called it.
If it isn't possible you'd have to make the programm mmap() stuff to NULL which 
means you've already exploited it, so no need to use some NP dereference hack.

> 
> So, going back, is it correct to say that an NPE bug on its own is not 
> enough to allow arbitrary code execution, but that other vulnerabilities 
> are necessary?
> 

I don't think it's correct: You may have a "bad" user on your system (e.g. 
pseudo-public server like in universities) who executes code that exploits the 
NPE bug and gains root/kernel privileges that way.
You only need another vulnerability if there are no "bad users" on your system 
=> the only way to execute bad code is via an exploit (e.g. in your webbrowser 
or one of its plugins etc)


But, to make it clear: I'm no expert on this, I just read a few reports on that 
null pointer related kernel exploit.

Cheers,
- Daniel


More information about the Digitalmars-d mailing list