Spec#, nullables and more

[Daniel Gibson]

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:
>>>
>>> bearophile wrote:
>>>>
>>>> Walter Bright:
>>>>
>>>>> The $10 billion mistake was C's conversion of arrays to pointers when
>>>>> passing to a function.
>>>>>
>>>>> http://www.drdobbs.com/blog/archives/2009/12/cs_biggest_mist.html
>>>>>
>>>>> Sadly, there's an ongoing failure to recognize this, as it is never
>>>>> addressed in any of the revisions to the C or C++ standards,
>>>>
>>>> I agree, that's a very bad problem, probably worse than null-related
>>>> bugs.
>>>
>>> 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 :-)

>
> 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.)

> (in that particular case, a straight-flush of them it seems). On the other
> hand, buffer overflows bugs nearly always make possible an exploit, correct?

I never said that buffer overflow bugs are better ;-)

Cheers,
- Daniel