Fix the Bugs, Secure the System

LiquidPC writes: "OpenBSD's Louis Bertrand has put his MUSESS 2002 presentation online, entitled Fix the Bugs, Secure the System. Does an overview of OpenBSD, then explains Format String Ugliness, Buffer Overflows, The Wrong Way to Fix Overflows, along with numerous other things."

Comments

Script Kitties

[Mattygfunk]

It was a bit tedious flicking through all those slides but the final one did bring a smile to my face.

Can't wait for this all to get sorted out

[Brontosaurus Jim]

Damn it's tough to code in C these days, keeping track of all the stuff that one needs to to be reasonably secure.

Not to mention the added overhead of making the system secure from semantic errors. Yeesh, it's a good think I get paid a lot for my C work.

But that's all okay, becuase (finally) technology, like Java, C# (okay this one sucks but whatever), etc that will help out and provide a truly _secure_ development platform.

I jsut hope they still pay me as much when this stuff finally gets easy, like it should be.

The only remaining wish...

[__past__]

The only thing I'd like to see from the OpenBSD guys would be a write-up of the gathered wisdom, in form of a "Code-auditing Howto". Unless everybody starts using OBSD (not due this week, unfortunatly), it would be nice if they would share their knowledge so that other platforms like, say, Linux, could benefit.

But then I guess producing a high quality operating system keeps then busy enough...

Re:The only remaining wish...

[dvdeug]

As if they'd pay attention. And before you mod that as flamebait, ask yourself why strlcpy() still isn't part of glibc..

There's a few huge winding threads in libc-alpha <http://sources.redhat.com/ml/libc-alpha> on this. One answer is:

These words make sense. The problem with strlcat and strlcpy is that they
assume that it's okay to arbitrarily discard data for the sake of preventing a
buffer overflow. The buffer overflow may be prevented, but because data may
have been discarded, the program is still incorrect. This is roughly analogous
to clamping floating point overflow to DBL_MAX and merrily continuing
in the calculation. ;)

Agree or disagree, the developers of glibc don't find strlcpy to be an appropriate function based on its merits. Trying to claim otherwise is just trying to stir up trouble.

Re:Buggy

[sporty]

Just becomes something does something in error doesn't mean its exploitable. If say the newest OBSD distrib forgot to provide a copy of disklabel, that's a pretty serious bug. You can't do a fresh install. A denial of service? Hardly. If the /etc/services file was missing an entry for httpd, it's an inconvenience, but still a bug.

Maybe I've been trolled, but thought I'd clear that up. A bug is an error in that a piece of functionality isn't right. An exploitable program or process can be a subset of it... that is, if being exploitable isn't part of the original plan.

The real problem with OpenBSD

[vlad_petric]

... is definitely neither security nor bugs - it's popularity/acceptance. To sustain my claim, there is no OpenBSD entry in the top requested websites

What's the point of a rock-solid operating system if very few are actually using it (and of course, that happens because of lacking features)? For a server security is always the second issue - the first being the service provided.

(I'm definitely exagerating here, so flame me as you like)

The Raven.

Re:Why not just mark the stack non-executable?

[gillbates]

A better idea would be to have two stacks - one for parameter data, and another for executable data. This way, an overflow in a variable couldn't overwrite executable code.

Re:Secure programming

[glenmark]

...or take the approach taken by OpenVMS from the beginning: any time a system call needs a string, that string is passed by descriptor. Of course, when the programmer is sloppy and uses null-terminated strings for his own calls, a buffer overflow in OpenVMS would only crash the program. Overflowing data would be discarded rather than executed. It boggles my mind that this flaw in Unix still has not been corrected after all these years.

Re:Secure the system: get rid of C

[Anonymous Coward]

In the case of OpenBSD, they don't use much other than C where possible because the've audited their libc. The same cannot be said for the C++ library included in the operating system, and hence it is avoided.

Such an example of C library failure was the recent globbing problems with ftp daemons using glibc in December 2001. OpenBSD had a denial of service problem with their FTPd back in April 2001 as a result of a similar (yet mostly already patched) glob function in libc. (http://www.openbsd.org/errata28.html#glob_limit)

Re:Secure programming

[Osty]

As far as I can tell it is safer and more programmer friendly in every respect. Even assuming you don't use OO, it can still be used as 'a better C'

new and delete intead of malloc() and free()

Those aren't guaranteed to be any more safe. You still have to check the value of a pointer after new, and you still need to make sure you use delete.

cin and cout instead of printf() and scanf()

Different syntax, same old problems. In and of themselves, C++'s stream objects are no safer than printf and scanf.

As for the rest, those have little bearing on writing secure code. In terms of security, C++ is no better than C. Both can be used to write secure code, but you do not get it by default simply because you use C++ over C. It's a design process.

Re:Secure programming

[slamb]

[new and delete] aren't guaranteed to be any more safe [than malloc and free]. You still have to check the value of a pointer after new, and you still need to make sure you use delete.

That's half true. You still have to make sure you deallocate properly (call delete or delete[] appropriately exactly once). But you don't necessary need to check return from new - it throws an exception instead of returning null.

(This might not be true on all platforms. I think the standard specifies this, but am not sure. You can make a test that ensures this by trying to allocate a ridiculous amount of memory and catching an exception. I actually do test this for a library of mine, but have only run it on Linux, FreeBSD, and HP-UX with default allocators.)

Different syntax, same old problems. In and of themselves, C++'s stream objects are no safer than printf and scanf.

Not true. There's an entire class of vulnerabilities that printf and scanf are vulnerable to that cin and cout are not: format string vulnerabilities. I think cin and cout suck, but they are unquestionably more secure than C-style format strings + varargs.

Mind you, cin with char[] stuff is still vulnerable to buffer overflows. Don't do that. Use a string class instead.

Re:Security: start in education

[pclminion]

So anyway, the point of this rant is that security will remain horrible until we start teaching people to write securely in the first place.

That isn't the prof's responsibility. He (she?) is a computer scientist, not a software engineer, and certainly not a security wacko. The relationship between computer science and software engineering is kind of like the relationship between physics and mechanical engineering -- the scientists create the knowledge and the engineers put it to use. You can't expect a physicist to design a perfect bridge, any more than you can expect a computer scientist to write secure code. It isn't what we do, and we really don't care about it. Computer science is really more about mathematics than programming; if you want to learn good design practices, take a software engineering course.