View mode: basic / threaded / horizontal-split · Log in · Help
November 06, 2010
Re: Spec#, nullables and more
Jacob Carlborg:

> Even though he may actually not forget a particular fact it will be 
> harder and harder to find the fact because of other things "blocking the 
> way". Eventaully it will seem you have forgot the fact.

It's not a block of the way, it's the networks that accumulate noise or just slowly get used for other purposes. So it's not a matter of space, as Walter has said, but mostly a matter of time: if you find some time to refresh old memories you are able to keep them on the long term.

Bye,
bearophile
November 25, 2010
Re: Spec#, nullables and more
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.

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. (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?

-- 
Bruno Medeiros - Software Engineer
November 25, 2010
Re: Spec#, nullables and more
On 11/25/2010 10:28 AM, Bruno Medeiros wrote:
>
> 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.
>
> 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. (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?
>

From a language designer's perspective, I think programmer association 
of semantic meaning to null (along with null's weak typing) is a more 
serious problem than npe vulnerabilities.
November 25, 2010
Re: Spec#, nullables and more
On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
<brunodomedeiros+spam@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
November 25, 2010
Re: Spec#, nullables and more
On 05/11/2010 18:52, Walter Bright wrote:
>
> I think you misunderstand why checked exceptions are such a bad idea.
> It's not just that they are inconvenient and annoying. They decrease
> security by *hiding* bugs. That is the opposite of what you'd want in a
> high security language.
>
> http://www.mindview.net/Etc/Discussions/CheckedExceptions
>
>

Just to clarify: Checked Exceptions are not a source of bugs per se. 
What is a source of bugs is catch-hiding an exception temporarily and 
then forgetting to change the code later (that's the case Bruce mentions 
in the article).
But with discipline you can avoid this: just don't catch-hide 
exceptions. One never catch-hides exceptions by mistake, it is always 
conscious (unlike other bugs like off-by-ones, logic errors, etc.).
For example in Java I *always* wrap exceptions I don't care about in a 
RuntimeException, (using the adapter Bruce presented in that article, 
actually).
Is it annoying and/or unnecessary? Well, I'm not making a statement 
about that, just that it will only actually cause bugs if you are lazy.

-- 
Bruno Medeiros - Software Engineer
November 25, 2010
Re: Spec#, nullables and more
On Thu, 25 Nov 2010 10:54:39 -0600
Ellery Newcomer <ellery-newcomer@utulsa.edu> wrote:

> From a language designer's perspective, I think programmer association 
> of semantic meaning to null (along with null's weak typing) is a more 
> serious problem than npe vulnerabilities.

True! An unfortunately rarely pointed issue and somewhat nebulous to expose.
I had the idea of an UNDEF value on the implementation side that could not be used/assigned explicitely by the programmer. It would just allow idioms like
	if (x) {}	// if x is not undefined...
by beeing under the hood logically equal to false, but any operation, even toString (I mean writeTo ;-) would raise an UndefinedSymbol exception. Since it's not assignable, a programmer cannot load it with app semantics (eg: author name unknown, element not found, invalid color code... whatever). A trial to get the best of both worlds. Just remains the problem of false/UNDEF not beeing distinct in logical expressions.


Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com
November 26, 2010
Re: Spec#, nullables and more
On 25/11/2010 16:55, Daniel Gibson wrote:
> On Thu, Nov 25, 2010 at 5:28 PM, Bruno Medeiros
> <brunodomedeiros+spam@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 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)

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?


-- 
Bruno Medeiros - Software Engineer
November 26, 2010
Re: Spec#, nullables and more
On 26/11/2010 17:28, Bruno Medeiros wrote:
>
> 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.

Hum, cool, I just found out that this link:
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
has the actual presentation on it, so I'm gonna take a look.

-- 
Bruno Medeiros - Software Engineer
November 26, 2010
Re: Spec#, nullables and more
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@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
November 27, 2010
Re: Spec#, nullables and more
On 11/26/2010 10:28, Bruno Medeiros wrote:
> 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.

I really hate this way of thinking.  Security vulnerabilities are binary
- either they exist or they don't.  Every security vulnerability seems
minor until it is exploited.

Yes, some security vulnerabilities are more likely to be exploited than
others.  But instead of rationalizing about how significant each
individual security vulnerability is, isn't it better to just fix all of
them?

(I know, I'm a hopeless idealist.)


-- 
Rainer Deyke - rainerd@eldwood.com
3 4 5 6 7 8
Top | Discussion index | About this forum | D home