Advisories and relative security [LWN.net]

Advisories and relative security

Posted Sep 5, 2003 6:40 UTC (Fri) by ekj (guest, #1524)
Parent article: Advisories and relative security

People should really stop writing all code in languages prone to buffer overflows. We've been trying the "just don't make mistakes" approach for 3 decades, and it is not working.

This is a solved problem people. And there are very few situations where a nice ruby or python or whatever (even perl if that's your fancy!) won't do.

Look at the list of vulnerabilities in this weeks LWN:

gkrellm: buffer overflow
node: buffer overflow, format string
atari800: buffer overflows
libpam-smb: exploitable buffer overflow

It's the same every other week. What is the excuse for this stupidity ? Yes, there are other bugs (this week a bit over half of the problems listed where "other" problems), but this is no excuse not to take the easy and painless way of squashing almost half our security-bugs.

to post comments

Advisories and relative security

Posted Sep 5, 2003 8:05 UTC (Fri) by beejaybee (guest, #1581) [Link] (1 responses)

" People should really stop writing all code in languages prone to buffer overflows. We've been trying the "just don't make mistakes" approach for 3 decades, and it is not working.

This is a solved problem people. And there are very few situations where a nice ruby or python or whatever (even perl if that's your fancy!) won't do."

O'Really?

Does it not occur to you that there may be buffer overflows in libraries called by applications written in ruby/python/perl?

Does it not occur to you that there are at least some applications where the overhead of weakly typed interpreted languages is simply unacceptable? (Else I'd write only bash shell script!)

Does it not occur to you that the hidden complexity of languages like python makes possible - maybe even inevitable - a whole class of vulnerabilities which haven't been discovered yet?

Security problems are caused primarily by lack of foresight. Buffer overflows are only one aspect of this. Using a weakly typed interpreted language instead of C(++) may prevent _you_ from creating buffer overflow holes, but doesn't prevent them from affecting your software, nor does it prevent you from making any number of other coding mistakes which might result in an exploitable weakness in your application. And the run time cost penalty may sometimes be unacceptable.

Sure, write in python, if it's suitable for the application and you're comfortable with it. But don't be stupid enough to think that this action alone will solve the problem of insecure code.

Languages and security

Posted Sep 12, 2003 10:13 UTC (Fri) by dvdeug (guest, #10998) [Link]

Does it not occur to you that there may be buffer overflows in libraries called by applications written in ruby/python/perl?

Sure, but at least the problems in your application will be gone. And if the overflow is in the library, all the programs that use that library can be fixed with one fix.

Does it not occur to you that there are at least some applications where the overhead of weakly typed interpreted languages is simply unacceptable?

Since when have all buffer checked languags been weakly typed interpreted languages? Ada is strongly typed and compiled, as is Modula-3 and ML.

Does it not occur to you that the hidden complexity of languages like python makes possible - maybe even inevitable - a whole class of vulnerabilities which haven't been discovered yet?

The vulnerability that hasn't been discovered yet isn't a problem, because no one's exploiting it. In any case, again Ada and Modula-3 don't have the hidden complexity of Python or even C++. (Pound for pound, Ada is simpler then C++.)

Security problems are caused primarily by lack of foresight. Buffer overflows are only one aspect of this.

But they seem to be a huge part of it.

And the run time cost penalty may sometimes be unacceptable.

Ada, for one, can be compiled with buffer checking in only in debug mode. In any case, worst case scenario seems to be about 20% for bounds checking, and while there's code that's written in assembly to eak out those last few percents, there's a whole lot of servers that are only CPU bound when running CGI scripts (i.e. Perl and friends.) Movie players and a/v encoders seem to be the only things I'm worried about speed wise on my P3/450 that serves as my desktop.

But don't be stupid enough to think that this action alone will solve the problem of insecure code.

We put airbags in cars, despite the fact that side collisions happen. Solving one part of the problem, a big part of the problem, is certainly an improvement over doing nothing because there's no silver bullet that will solve the whole thing.