Thanks for proving Bernstein right [LWN.net]

Thanks for proving Bernstein right

Posted Nov 4, 2007 16:41 UTC (Sun) by man_ls (guest, #15091)
In reply to: Thanks for proving Bernstein right by i3839
Parent article: Daniel Bernstein: ten years of qmail security

surely you didn't meant to say that simply dereferencing a pointer is a bug? ;-)

Ehm, my C is a little rusty, but no :D I rather meant null pointer dereference, double dereference or whatever other strange things are allowed in C that lead to security problems.

Every bug has the potential to be a security problem, one way or the other.

That is a belief originated by OpenBSD people which is not shared by many. "Potential" is a weak word, but anyway the potential security problems related to many bugs is near zero. Some bugs are purely aesthetic, others just make things work wrong with no side effects. Some languages help keep side effects to a minimum, others don't.

Some security issues are not even bugs; failure to validate an input string maybe an excess of confidence, but it cannot be considered a bug unless you assume the string might come from a hostile party. Most program specifications just say what should happen, not what should not happen.

My experience is that there aren't less bugs in Java code than in C code.

Of course not, but I much rather prefer a NullPointerException than an undesired intrusion.

to post comments

Bernstein right? Maybe, but Theo is too, mostly

Posted Nov 4, 2007 19:30 UTC (Sun) by tialaramex (subscriber, #21167) [Link] (7 responses)

No, the OpenBSD people are so close to absolutely correct that it's not worth calling the
difference. Bugs cause something unexpected to happen. If unexpected things happening was
acceptable then you wouldn't bother with security, just say "That was unexpected" when
anything bad happens.

Here's a nice simple example. You have a program which examines NTFS formatted hard disks to
check that everything on the disk is authorised by the company. The program is pretty simple,
but it has a small bug.

The bug is that it assumes all NTFS filenames are Unicode strings. This seems like a
reasonable assumption, because most likely every NTFS filename you've ever seen was a Unicode
string, and all the files you tested with have such names, there isn't any way to "type in"
anything except Unicode strings as the name for a new file in Explorer or Word or similar
software, so why would you assume anything else?

But now you've created an incentive to construct files with non-Unicode names. Perhaps the
code sequence 0xFFFF 0xFFFE 0xFEFF 0xFFFF would be a good name for a file. Your buggy software
cannot convert this into a Unicode string, so it ends up in an exception handler that you
never realised could be called under such circumstances. The exception handler normally fires
when a file has been deleted before it can be examined, so it just tidies up and moves on to
the next file. So now the magic file is invisible to your software and you have a security
breach.

There are billions of assumptions like this, regardless of whether you're programming in LISP
or Fortran, and if any of them are wrong in a security sensitive application the security
probably doesn't work. Worse, the only people likely to find out have an incentive not to tell
you. That's why security is actually hard, although you wouldn't think it from all the Mickey
Mouse security consultants and 3rd rate security software.

Oh and yes, it turns out that although the Win32 APIs don't believe in files with non-Unicode
names, the underlying NT kernel, like the Linux kernel, considers them all to just be opaque
identifiers. Don't laugh too loud at the programmer who wrote one byte too many into an array,
you'll have your own foot in your mouth soon enough.

Security bugs

Posted Nov 4, 2007 21:43 UTC (Sun) by man_ls (guest, #15091) [Link] (6 responses)

Bugs cause something unexpected to happen.

In the vast majority of cases, bugs cause something expected not to happen. You press the button, it doesn't work. These bugs normally don't pose security risks.

Examples are good for illustration, and yet often they are not so good for proof. In your example something expected does not happen (exception logging), and yet it poses a security risk. The key is in the part where you say:

Your buggy software cannot convert this into a Unicode string, so it ends up in an exception handler that you never realised could be called under such circumstances.

Here is really where something unexpected is happening.

In short, the vast majority of bugs result in minor failures which don't compromise the application. Treating all bugs as having the same priority ("security critical") leads to the kind of version paralysis we can see in OpenBSD; the rest of the world just moves along.

Security bugs

Posted Nov 5, 2007 10:47 UTC (Mon) by tialaramex (subscriber, #21167) [Link] (5 responses)

You press the button, it doesn't work. These bugs normally don't pose security risks.

Sure, like Logout in a default Windows install. There's no security implication to an
apparently "logged out" machine still actually being logged in with your user privileges
right? It's just a minor usability bug, not even worth fixing in a security sensitive
environment really...

Fortunately these days Microsoft doesn't believe optimists like you, and so they provide an
override, you can force the session to actually end when the user clicks Logout. It's rare
that sensitive environments enforce this, but at least it's documented.

I'm sorry, but your whole thesis is wrong in principle. Every time you make a false assumption
in a security system the actual security of the system becomes an unknown.

Worse, it turns out to be wrong in practice as well. Every so often a very narrow, apparently
minor problem is found in some security sensitive component which vendors declare not to be a
security risk after some analysis. And almost inevitably this is taken as a challenge by
readers of Bugtraq and other less salubrious lists and the result is a working exploit. Not
always a model example, it may be hard to get working on common platforms, or it may require
some inside knowledge or even be only a probabilistic attack. But suddenly "No security
problem" has transformed into "Oops, critical security fix needed".

IIRC there's even an example of this happening to the Apache HTTP server, which has a lot of
very smart people working on it. The trouble is that the black hats only need to find one
hole, while the white hats need to find every hole in the entire system. It's an unequal
battle, but it's certainly not helped by pretending it's easier than it is.

Yes, there undoubtedly have been examples that really were impossible to exploit in the wild,
but distinguishing them from the other type I described above is so hard as to be not worth
the engineering effort to make the distinction. That's how OpenBSD is able to maintain any
momentum at all - they just fix the bugs rather than trying to figure out whether they can
ignore them safely.

Security bugs

Posted Nov 5, 2007 20:08 UTC (Mon) by man_ls (guest, #15091) [Link] (4 responses)

OK, so you (and de Raadt) can go on treating all bugs as potential security holes. Meanwhile I (and the rest of the world) will go on assigning severity and impact to bugs, programming defensively, using defense in depth and the rest of accepted principles of secure programming. Yes, sometimes we will leave holes open -- but so will OpenBSD, and so will everyone else.

Security bugs

Posted Nov 6, 2007 8:55 UTC (Tue) by tyhik (guest, #14747) [Link] (1 responses)

Your ealier posts in this thread make me ask the following. Is there an open-source project
you are regularly contributing code to? Let alone maintaining. I'd consider avoid using it if
possible. Sorry, no offence, just business :)

Security bugs

Posted Nov 6, 2007 9:53 UTC (Tue) by man_ls (guest, #15091) [Link]

Oh, I'm sorry; in case it wasn't obvious, I regularly contribute to a plethora of Free software projects, especially in C. I enjoy referencing and dereferencing every so often; whenever something doesn't compile I add *'s until it works. (I know, sometimes it's &'s, but it's hard to know beforehand.)

Just joking, I don't actively contribute to any Free software projects. On the other hand, in the last seven years I have developed a number of network-exposed services and maintained several public servers, and they have experienced zero intrussions. Sure, it was not terribly popular stuff, mostly research projects. But still.

Sorry, no offence, just business :)

Not sure your business sense is too good. This makes me ask the following: is there any business investment you are regularly making? Let alone running. I'd consider taking all my money out. No offence, just business ;)

Security bugs

Posted Nov 6, 2007 21:44 UTC (Tue) by tialaramex (subscriber, #21167) [Link] (1 responses)

The fact that you still think

"treating all bugs as potential security holes"
and
"assigning severity and impact to bugs"

... are opposites is the source of your confusion. All bugs are security holes (or must be
assumed to be until comprehensively proved otherwise, which amounts to the same thing), but
that doesn't somehow magically make them all equally severe bugs or equally urgent to fix.

The important insight from Theo (who I respect but don't much like) is that we should fix
these lower priority bugs anyway, and find ways to avoid introducing new ones - because it's
easier than figuring out their security implications. The OpenBSD bug you referenced actually
illustrates this, even though in this case it was the OpenBSD team themselves who looked
foolish.

You might think it stands to reason that we should fix or prevent bugs, but actually our
resources are limited and there are other things we could do instead. Bill Gates argued fairly
convincingly that since customers / users don't notice bug fixes you should divert as much
engineering resource as possible to adding features instead. Theo's point makes it obvious
that this is a mistake, and Microsoft eventually concluded the same.

Security bugs

Posted Nov 7, 2007 1:21 UTC (Wed) by man_ls (guest, #15091) [Link]

Thanks for trying to make it clear, but it remains a mystery to me. Somehow we are expected to product zero-bug code, or otherwise we may compromise the whole system. We assign priorities but in the end we are expected to solve all issues, so it doesn't really matter.

Thank God the original creators of Unix did not share this frame of mind; they tried to isolate security-sensitive parts. It was a lesson that Julius Caesar himself had learned in the Gallic wars: it doesn't matter if a few thousand enemies get through our outer defenses, we have enough layers that not much will get through all of them; and then we butcher those few. It was thus that he conquered an estimated 250,000 gauls with just about 7500 men. Read it from the source if you have the time (book VII, chapter LXIII; or just search for "ditch").

And yes, it is still sensible practice to follow Caesar's advice and organize your application in layers (or compartments, or whatever) so you can defend in depth. Bugs in outer layers do not matter, at least not for security; bugs in just a handful of inner compartments must be watched carefully. Funnily enough that is what Bernstein seems to be asking for in his paper (which I will have to read carefully after all; I do not much like the guy anyway, just as you don't really like de Raadt). But it sure sounds like running applications in tight compartments, minimizing side effects.

Null pointer dereference is a crash, not a security bug

Posted Nov 5, 2007 15:26 UTC (Mon) by mheily (guest, #27123) [Link] (1 responses)

> Ehm, my C is a little rusty, but no :D I rather meant null pointer dereference, double
dereference or whatever other strange things are allowed in C that lead to security problems.

If a program attempts to dereference a NULL pointer, the program will be terminated
immediately with a SIGSEGV signal. This does not allow arbitrary code to be executed. A double
dereference is a perfectly normal and desirable condition in many programs, and the compiler
will catch double-vs-single pointer mismatches at compile time.

> Of course not, but I much rather prefer a NullPointerException than an undesired intrusion. 

Again, there is no way for a NULL pointer dereference to facilitate an intrusion since the
program will segfault instead of executing arbitrary code.

Null pointer dereference is a crash, not a security bug

Posted Nov 5, 2007 17:51 UTC (Mon) by phiggins (guest, #5605) [Link]

A lot of Java programmers have gotten so rusty on their C that they can't remember how Java
saves them from these kinds of mistakes. It's actually the ArrayIndexOutOfBoundsException that
saves your bacon from memory corruption. Of course, Java programmers are often way too smug
and think that memory corruption problems are the only kinds of security bugs. It's very hard
to write an arbitrary code execution vulnerability in Java, but an unexpected and improperly
handled ArrayIndexOutOfBoundsException or NullPointerException could still violate the
security of your program. It will be more difficult to get shell access that way than with
arbitrary code execution, though!

The bigger concern is with the JVM implementation, which has had some vulnerabilities, but it
hasn't been nearly as bad as I expected it to be. Java really has done well in the
memory-related security area.