View mode: basic / threaded / horizontal-split · Log in · Help
November 27, 2010
Re: Spec#, nullables and more
Rainer Deyke schrieb:
> 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.)
> 

Of course you should fix all of them, but the (sensible) language level support 
to prevent them may vary.
e.g. buffer overflows are a huge problem, so D has builtin index checking for 
arrays and such.
Null Pointer dereference exploits are - as far as I know - only relevant in 
kernel code and if mmaping to NULL is possible. So it's probably not a common 
problem in D code and people who write code that may be affected can take care 
themselves.

Cheers,
- Daniel
November 27, 2010
Re: Spec#, nullables and more
Daniel Gibson Wrote:

> Rainer Deyke schrieb:
> > 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.)
> > 
> 
> Of course you should fix all of them, but the (sensible) language level support 
> to prevent them may vary.
> e.g. buffer overflows are a huge problem, so D has builtin index checking for 
> arrays and such.
> Null Pointer dereference exploits are - as far as I know - only relevant in 
> kernel code and if mmaping to NULL is possible. So it's probably not a common 
> problem in D code and people who write code that may be affected can take care 
> themselves.

Even if eliminating unnecessary NPEs or segfaults doesn't prevent many significant security problems, it can improve the user experience in tremendous ways.

I'm an embedded / qt / android software engineer working on Linux. My (graphical) tools experience random segfaults in the range of tens of times per a single work day. Reloading the same tools over and over again and restoring the lost data may actually waste almost 10% of my daily work time. Imagine if the industry lost 10% of its income because of sloppy tools written in too low level languages, would that make the feature significant enough?

Instead of using automatic GUI builders and such, the tools we use are often hand written C or C++. Why these happen? We forget to initialize or fail to track the lifetime properly.
November 29, 2010
Re: Spec#, nullables and more
On 26/11/2010 17:54, Bruno Medeiros wrote:
> 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.
>

I've seen the presentation, but he doesn't explain how a null pointer 
access would have caused a vulnerability. I'm going to assume that in 
all likelihood this applied to older computer architectures and/or OSes 
that didn't handle null pointer access that gracefully (1965 is way 
back...). But not so much to modern ones. Or that the vulnerability 
wasn't an actual arbitrary code execution, but some other system failure 
caused by the program crashing.

In any case this side-topic was just a minor curiosity, it's not really 
relevant for D.


But on his talk as a whole, the general point he made was interesting, 
he expressed the desire for languages to have more safety and checking, 
preferably on compile-time, if possible, and if not, on runtime at least 
(rather than have the program corrupt data, or execute crap). He 
mentioned that the big argument against this at that time was 
performance penalties, but that even so a lot of the people/companies 
were happy with the checks that were introduced (like array bounds 
checking), even if initially it didn't seem like a good idea.


-- 
Bruno Medeiros - Software Engineer
November 29, 2010
Re: Spec#, nullables and more
On 26/11/2010 19:20, Daniel Gibson wrote:
>>
>> 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)

You're still thinking in terms of compromising a machine. I didn't mean 
specifically that, forget users and hosts, I was thinking of a more 
general and simpler case which relates to a process only: can the input 
to some program P cause arbitrary code execution, when it shouldn't? 
Like, can an image file cause my image viewer to run arbitrary code, can 
a zip file to the same for my zip extractor, etc.. (the same if the 
program is a server process and the input comes across the network)


-- 
Bruno Medeiros - Software Engineer
November 29, 2010
Re: Spec#, nullables and more
On 27/11/2010 03:29, Rainer Deyke wrote:
> 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.)
>
>

You missed the point. The point wasn't that a vulnerability caused by a 
null pointer access was less serious or significant than a vulnerabitiy 
caused by a buffer overrun. Once a vulnerability exists, it should be 
fixed regardless, yes.
The point was that if you have a null pointer access *bug*, that bug is 
incredibly less likely to create a *vulnerability* than a buffer overrun 
*bug*. Note that "creating a vulnerability" means "making it *possible* 
to exploit the program", it does not mean "someone actually exploiting 
the vulnerability".

-- 
Bruno Medeiros - Software Engineer
Next ›   Last »
4 5 6 7 8
Top | Discussion index | About this forum | D home