Bernstein right? Maybe, but Theo is too, mostly [LWN.net]

Bernstein right? Maybe, but Theo is too, mostly

Posted Nov 4, 2007 19:30 UTC (Sun) by tialaramex (subscriber, #21167)
In reply to: Thanks for proving Bernstein right by man_ls
Parent article: Daniel Bernstein: ten years of qmail security

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.

to post comments

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.