Darren New <dne### [at] sanrrcom> wrote:
> clipka wrote:
> > flawed code which I assume would have been discovered earlier in a
> > commercial environment
>
> Interestingly, I can imagine this particular flaw might be easier to find by
> a bad guy in proprietary code. You can look at the machine code to see
> there's no check for NULL in that routine.

It may be interesting news to you that examining compiled piece of software is
just as easy with open-source software as it is with closed-source software...
;)

And knowing this particular compiler behavior, the bad guy's job has become a
whole lot easier with open-source software: Just get a good static
code-analysis tool and have it grind the code for places where pointers are
de-referenced without checking for NULL first.

*Then* dig through the compiled code to see if the compiler optimized away a
later check for NULL.

So however you toss and turn it: Breaking into any piece of software is easier
if it's open-source than if it's closed-source.


Butt also note that of course the *good* guys' job *should* be a lot easier with
open-source, too: Just get a good static code-analysis tool... (You know the
rest.) That's the very paradigm on which the alleged superior safety of open
source is founded: More eyes looking at the code will spot more of the bugs.

The problem - at least in this case - is that the good guys obviously didn't do
it. Or they didn't listen to one another when some of them did.

If that's how it typically works in reality, then as far as security is
concerned the whole superiority of the open source concept crumbles, leaving
only its disadvantages in this respect. Making software open source doesn't
improve security (or quality in general) *per se* - the good guys need to do
their homework, too.


> How many routines in Linux look like they check for buffer overrun but don't
> because the compiler did something wrong or unexpected? Of those, how many
> will people notice,

Yet how many more could a static code-analysis tool notice? Quite a lot, I bet.
Unless the compiler is outright buggy of course, but that would surface sooner
or later, too.

The major problems are code constructs that lead to undefined behavior according
to the C (or C++) standard specifications - because "undefined behavior" *by
definition* includes the potential for security breaches. Static code analysis
tools do a great job at identifying the use of such constructs.

Post a reply to this message