The OpenBSD project hopes that new changes to its latest release will eliminate “buffer overflows,” a software issue that has been plaguing security experts for more than three decades.
OpenBSD Team Fights Buffer Overflows
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Now, here’s a true server OS!
Eugenia, If you really want that firewall of yours to be rock-solid and secure, dump the FreeBSD box and use OpenBSD!
And speaking of stability, why would an OS crash if all it does is sit there and route traffic? You can use a 386 box for that purpose and still get away with it!
I would love to see this addition merged into the likes of FreeBSD. There are a tonne of security features that can be added to FreeBSD from OpenBSD which would have very little impact on the over all speed of the system. Sure, there are pointless and padantic features that OpenBSD has, however, there are also very good features that I would love to see FreeBSD merge.
Isn’t this basically a C specific issue (with it’s weak array bounds checking)? If you really want to write an OS from scratch that isn’t susceptible to buffer overflows, use a language with stronger bounds checking?
basically the reason that C is still used after all these years is that it combines the flexibility of assembly with the performance of assembly
C allows you to program on the ‘bare metal’. even going to C++ you lose a lot of that because you start abstracting what is really going on to ideas that are easier to comprehend, but not nesecarrily to what really happens.
higher level languages add a lot of runtime overhead because they have to make things safe for you by assuming you have fucked up during programming.
the best thing you can do is to use C (and assembly if needed), but strictly adhere to design principles. for example never pass a pointer to a buffer without also passing the length.
basically i think that you should never drop a good tool only because it is possible to make mistakes. you should learn to use the tool instead.
kind regards,
Bruno.
OpenBSD is a great OS for firewalls. But OpenBSD is also great for general purpose servers (web,mail,dns,…). And last but not least, I love my OpenBSD desktop(s) *g*
Some will say that OpenBSD doesn’t have (insert_buzzword_here), or doesn’t support (insert_freaky_piece_of_hardware_here). But that isn’t the project’s goal. OpenBSD is just a clean (At least I spend time _adding_ stuff after a clean install, not _removing_ cruft I don’t need), rock-solid (The only crashes I ever had were due to bad hardware), free (really free, not gpl which looks free but isn’t) and last but not least ultra-secure.
These latest security changes also made me understand why i386’s are dirt cheap when compared to other arches like Macs or Suns. It’s just because i386’s are crap and broken by design (well, at least their MMU is
). Also i386’s have way to little cache (but that’s getting off topic here 
)
But in the end, it’s all about the right tool for the right job, not? So OpenBSD isn’t for everyone. If you want an OS that has everything preconfigured, or that has mind-numbing wizards to guide you through everything, there are other OS’s to suit your needs, like most Linux-distro’s or even Windows. OTOH, if you like a real UNIX-like OS, that still carries the real UNIX-way of thinking and doing things, and is very secure, be sure to give OpenBSD a try
I agree with rabbit, OpenBSD is a great, very clean, stable and secure OS.
I’ve give OpenBSD a second try (I already tried it in the past) if only it supported harddrives bigger than 137 GB (no, it’s not my BIOS limitation, it’s an OpenBSD limitation according to the official FAQ) and if it supported finnish keyboards properly.
Problem is, if the problem is there, and if the language isn’t failsafe enough to protect against it, then you may run in to troubles. Bruno you’re absolutely right, however. Such issues in mission-critical server software such as OpenBSD has got to be exorcised.
The FAQ says:
“Note the next generation of ATA drives, those with capacities greater than 128G (1G=2^30 here, not 1,000,000,000, so drive manufacturers will often call this 137G), are not supported by OpenBSD 3.1 and earlier.”
So this may mean that, since 3.3 will be out May 1st, those drives may well be already supported. Too bad I don’t have such a drive, but you might want to test it out
As for finnish keyboard support, well, if you feel like creating/porting over a finnish keymap, I’m sure it’ll be included.
I agrre with rabbit. OpenBSD is truly a great OS. I use it for www/mail and firewalling at the moment (gentoo serves my desktop).
May i also add that reading the misc list provides me with enough entertainment to keep my TV turned off
regards /texas
Yes, this entire category of problem is pretty much due to a deficiency in C’s design. Unfortunately we’re stuck with it.
Ritchie has said it was his biggest regret about C, and it’s the reason why Plan9 and Inferno designed and used a new language for those OS’s.
Having said that, the issue is more complicated than just ‘bounds checking’. That kind of logic error leads to them, but C isn’t amenable towards a graceful failure in this case. And no, you do not necessarily have to have some super high level, run-time-efficiency-encumbered language to achieve this.
It would be nice if there were some good open source verification tools out there. (Here’s hoping maybe IBM could help out with that w.r.t. their recent acquisition of Rational.)
Does this place ever have meet-ups?
First off… I have some problems with the way the article was written on a technical level. If I read correctly I believe they say that PPC is a 32-bit architecture, and while there are 32-bit PPC versions, there are also 64-bit ones… the earlier 64-bit ones weren’t so popular, but last I checked the Motorola chips that are produced for Apples stuff were 64-bit with some sort of abstraction layer which obtained 128-bit processing power, which they called their Velocity Engine. I felt it was a bit broad to just chunk “PowerPC” into a 32-bit class, especially along side x86 stuff. Next, I’m pretty sure x86 on a very basic level has a method for making pages of memory executable and writable or both…. In my first attempt to code an operating system, and after reading up on what Global Descriptor Tables were, I thought it was quite interesting that you could set up one hunk of memory as executable, one as writable, and some as both, or any combination of those modes… In fact, I believe I had to add two separate tables in order to make it read/exec and read/write and therefore read/write/exec. Would this not be the same as what the OpenBSD team has done except on a higher level? I’m sorry… but I’m not impressed by the writing. While it’s interesting to see the OpenBSD team work on upping security I think it’s just as easy to implement security using higher level stuff that protects the system, such as an ability for a “user-level”, or simply making sure programs don’t need higher permissions than they will. I may be incorrect on that too though, but isn’t it so that the only real way to gain root on a system with a buffer overflow is if the program with the flaw runs as root or further exploits another (possibly local) program running as root? I don’t know anymore… but this is the kind of article that will make all the kiddies try to argue that PPC is a 32-bit architecture when I talk to them about PPC 620…
Is OpenBSD/NetBSD using Linux kernel? please school me. Thanks.
OpenBSD, NetBSD, and FreeBSD each have their own kernels, which are in no way related to the Linux kernel. That said, since OpenBSD was originally forked form NetBSD, the two still bear some resemblence at the kernel level. At the user level, I daresay that the three entirely seperate BSDs are more consistent and similar than most pairs of GNU/Linux distros.
they use their own kernel 🙂 it’s not related to linux but unix proper way on down the line.
what’d be even better is if they could write a source analyzer that finds these things and points them out so the world at large could benefit. i know about smatch and splint, are any of them security paranoids working on it?
“De Raadt was careful to point out that the group paid for its own beer.”
If this works then OpenBSD will be the undisputed security champion. It already claims to be the most secure OS in the world, but I would have to say that if buffer overflowing is impossible then there can be no doubt.
Buffer overflow security problems seem to be reported every day. If OpenBSD is immune then that is fantastic. Of course… if this works they won’t be able to keep it to themselves for long. Especially considering that they are a BSD. Which is good for everyone I guess.
what’d be even better is if they could write a source analyzer that finds these things and points them out so the world at large could benefit.
Well, technically the world at large can benefit. This is a BSD, so anyone can pull that code out and apply it to their own operating system as long as it will fit into the architecture reasonably well.
Assuming this works as well as they say it does I would expect this to hit the BSDs and possibly linux within a year or so, but what do I know (hint: not much)?
what’d be even better is if they could write a source analyzer that finds these things and points them out so the world at large could benefit. i know about smatch and splint, are any of them security paranoids working on it?
It would have to be a “source understander” (or “program understander”) that would have to know every byte in the host computer and every possible input etc. It would be like knowing the future from looking at atom movements: impossible.
Sure, you can find the easy bugs from source analyzing but not the harder ones.
I don’t follow OpenBSD closely but is this new? Maybe for the OpenBSD users. Dont mean to bash OBSD but kinda tired of people saying it’s secure out-ot-the box and such…Immunix has buffer overflows protection for years….Stackguard, FormatGuard, SubDomain-enabled kernel from immunix.org or wirex.com. No I don’ work for them.
Last I tried OBSD (which is two days ago), any user could view /etc directory and openssh has password authentication as default
Too much for security there, I guess. Look at Engarde Linux 
But I must say I like pf and its syntax however, especially altq.
OpenBSD is an example of a great software engneering project. They have a definitive view of what they want to creat, and then they do it, and don’t bother with making buzz-word compliant additions. This removal of dangerous C-code, as well as the new sack-protection have again raised the security bar for other software projects, open source or not.
I would also like to say that I appreciate the fact that OpenBSD doesn’t require a lot of garbage to run, and is a very well organized and documented project. When I started using it, I was woried that it would be too difficult to use, but after the first day, I was set. Everything is organized and operated logically, and all the core components are rock solid.
Congrats to the OpenBSD team on a job very well done.
It’s not impossible at all. There already exists really expensive programs that do model-checking analysis of C that could find these kind of flaws. The problem is, they’re all commercial and very expensive.
Another is that they’re typically tuned to look for other kinds of problems like e.g. aliasing and memory issues. People just don’t seem to think it’s important enough to pay for security.
Id just like to know what kind of beer they were drinking!
Last time I got drunk I did some interesting stuff, but none of it advanced network security.
Plan 9 *uses* C? (I don’t know if it’s a variant of C or straight C though, I haven’t coded enough under P9…)
You don’t understand. Security through obscurity just doesn’t work. For a secure OS, it shouldn’t matter if people can read what’s in /etc. Even if they can read the (blowfish encrypted) password database, (almost) no harm is done.
And everyone uses password auth., well, some may not, but there’s nothing wrong with passwords. If your users have weak passwords, that’s not the OS’s fault, but you should educate your users.
This is really great. The 386 has several kinds of memory segments: readable, read/writable and executable. Now, make the Code Segment only Executable, make the Data Segment only Read/Writable and the problem should be solved.
All data a client might send, remains unexecutable this way, yes, and as the 386 supports this, why indeed not use it?
It’s not impossible at all. There already exists really expensive programs that do model-checking analysis of C that could find these kind of flaws. The problem is, they’re all commercial and very expensive.
They find SOME flaws, but not all kinds of bugs. There’s a lot more to it than strcpy overflows and such.
If you really fell for their advertisment BS or what it is then why doesn’t Microsoft or SUN just buy it and make it find all the bugs? If it’s true then there wouldn’t be a need for security advisories/patches ever again?
“If you really fell for their advertisment BS or what it is then why doesn’t Microsoft or SUN just buy it and make it find all the bugs? If it’s true then there wouldn’t be a need for security advisories/patches ever again?”
Yes, I’m sure that if Microsoft got involved then the number of bugs would change dramatically. They would skyrocket. Any evidence to suggest otherwise ‘ts’?
buffer overflows are a byproduct of an outdated C language “feature”. I feel there is a more elegant solution which is far safer and often faster, and that is to use counted strings instead of null terminated strings.
The most common type of counted string was popularized by UCSD pascal in the late ’70s (an array of 256 characters based at 0, the first of which is the length of the string)
The advantages are…
1) A standard string while being limited to a maximum of 255 characters, can never exceed that limit because of the size byte at the beginning having a hard constraint. If one assumes that all strings within the program adhere to allocating a maximum sized string, buffer overflows become totally benign. You should also of course use good programming practice by using safe string libraries whenever possible, and avoid dirty programming practices which bypass the normally safe method of accessing components of strings. Also, even if you corrupt the length, normal use of the strings still does not compromise memory.
2) the length of the string can be quickly referenced. This makes concatenation and other string primitives significantly faster since you don’t need to scan to the end of the string all the time.
3) one or more null characters can be represented within the string.
There are some disadvantages which need to be taken into consideration. The limit of 255 chars of standard string tends to be somewhat restrictive for some applications.
This can be improved by using a larger variable for the count instead of the byte count at the beginning of the string which does complicate matters somewhat. For safety one should probably still statically allocate the strings but a larger variable for the size increases the risk of buffer overflows slipping in. However decent compilers should be able to manage such an extension in a relatively safe manner providing one sticks to using the primitives and other accepted methods of referencing the string.
P
I’ve give OpenBSD a second try (I already tried it in the past) if only it supported harddrives bigger than 137 GB (no, it’s not my BIOS limitation, it’s an OpenBSD limitation according to the official FAQ) and if it supported finnish keyboards properly.
I can’t comment on the Finnish keyboard layout, but I believe OpenBSD has supported large rdives since 3.2 was released last year.
Last I tried OBSD (which is two days ago), any user could view /etc directory and openssh has password authentication as default
Too much for security there, I guess. Look at Engarde Linux 
Most Linux distros let any user read /etc too. You just can’t change any of the files (which is also the case with OpenBSD). This is a very trivial thing to change if you don’t like that setup. I hardly think it is a big enough issue to abandon an OS over.
Yes, I’m sure that if Microsoft got involved then the number of bugs would change dramatically. They would skyrocket. Any evidence to suggest otherwise ‘ts’?
Did you read my post at all? I didn’t think so either.