Slashdot Mirror
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."
I think the bottom line is pretty obvious here: If you're serious about security it's not rocket science to build a secure system, but it is a lot of hard work, and much of that work just happens to be precisely the kind that the Linux camp shuns. It's time for the self-professed "hackers" to grow up and start acting responsibly. If not, the list of Linux security exposures will continue to grow longer and more embarassing, making it all the easier for MS to tell customers, "Do you really want to risk your company to a bunch of kiddie coders who have no respect for security?"
Before you fire off a nasty response to that last part about MS, think about how hard MS is working to change their image WRT security. A lot of people I know in the business are saying that getting security right has become the new religion at MS. No one should be surprised to see Windows become as secure as Linux before LInux can become as usable as Windows. And if that happens, the whole war for the desktop is lost.
You may not find that millions of web servers are running on OpenBSD, but if there were some way to keep track of how many of them are protected by firewalls/routers running OpenBSD, the numbers would probably be more impressive.
I, for one, find that the "secure by default" policy is incredibly convenient for a drop-in firewall solution (and I've done this a few times for various companies).
I prayed about it, and God said, "Don't do it!" But I thought, "I know better."
Yes, it's tough to code in C and still keep things secure, especially for inexperienced programmers. But people developing at the OS level need the speed and performance of C. We can't get that amount of speed with Java, C#, etc. There's always a trade-off.
Interestingly, there's a C dialect called Cyclone by AT&T which tries to give the best of both worlds. It doesn't allow careless code (that becomes buffer overflows, etc.) but it doesn't sacrifice performance either.
What's the point of a rock-solid operating system if very few are actually using it
OpenBSD will never show up on my networks - but every packet that gets to my FreeBSD webserves goes through an OpenBSD firewall. I imagine that a lot of packet are touched by OpenBSD - an we'll never know it.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
granted, a non-executable stack makes it significantly harder to exploit a buffer vulnerability, but it's not impossible. you can also put your shellcode in environment variables, in the heap, or various other places. if you wanted to follow your line of reasoning to completion, you'd have to have an isolated code segment, marked read-only, and everything else marked non-executable. of course, then we have the issue of how to handle run-time dynamic loading, and programs like vmware--pretty much anything that gets machine code from a source outside of itself and the libraries that are linked in at compile time.
i do agree with the idea of a non-executable stack, though. it's just regarded far too often as a panacea for buffer overflows.
#define F(x) int main(){printf(#x,10,#x);}
F(#define F(x) int main(){printf(#x,10,#x);}%cF(%s))
If this had been converted from presentation-style to an actual webpage, it would have been deemed a big waste of time. Where is all the information? There isn't even anything new here, I already knew everything there, and I've only been using OpenBSD for a couple weeks.
The only thing there was a long list of titles with no information, old or new.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
We've done that hundereds of times, but people just don't believe it's that simple.
1. Pick a random piece of code.
2. Find bug.
3. If bug doesn't fit in any known class of bugs, create new class of bugs and and remember it.
4. Fix bug.
5. Search for all bugs in all known classes of bugs.
6. If all bugs in all known classes of bugs are fixed or you're bored, goto 1.
There is no magic. Just work.
I'm a CS major, and we just got some sample code from the professor to help us on our first project. The very first thing it does in main is have a buffer overflow.
// BAM!!
#define SZ 100;
char buf[SZ];
cout << "Enter courses filename: ";
cin >> buf;
This is C++! We have the string datatype for this! There's absolutely no excuse for this--especially in code that will be referenced as "good" code by everyone else in the class.
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.
~~~LXT~~~
Life is like a computer program: anything that can't happen, will.
But no one actually believes C is a good language?
C is a great language for the thing it was designed for -- system level (ie OS) programming. It turns out that it is mostly decent (and at least functional) at other programming tasks, and this helped it become ubiquitous.
Most of the problems in C that arise at the system level are a function of the standard library that it came with. For example, strcpy() should have never existed.
As to whether or not C is any good anywhere else... *shrug*. Minus easy-to-use regexp's, I think once you learn how to write good C code it can be a "good" language for just about anything. Still, I'm not saying I wouldn't mind seeing Java become more common in applications... So long as I can get a good static compiler and libraries for it.
The enemies of Democracy are
I can't believe there is not one mention of using a language other than C. Is it the systems community? Is it because of BSD's history?
I don't know why this idea fails to even come up. Network servers are bandwidth-limited, not cpu limited, and writing them in a safe high level language is not only easier, but makes buffer overflows impossible. Being easier to write also of course allows more time for optimization and for other security fixes. (For those that need really high-performance for their gigabit links, maybe a C version and very careful maintenance is possible. For home users, this prospect is ridiculous.)
C seems almost *designed* to allow for buffer overflow exploits. If we want secure programs, we should be starting from more secure foundations!
For more detail, check my previous rant, "C lang remains inappropriate for network daemons": http://slashdot.org/comments.pl?sid=24271&cid=2629 013
I don't agree with your assessment that safe high-level languages necessarily perform badly. (What is the difference between speed and performance?) But, let's forget about that.
What is "OS-level" about an ftp daemon? BIND? Mozilla? Gnutella? All sorts of network (and other) applications are written in C, even though there certainly isn't any need for performance or device-level bit manipulation. (At least, I would place security way above performance!)
Cyclone is actually from Cornell, by the way. It's a good project for moving systemsy people away from C, but there are already mature programming languages that are not slow, and yet are secure by default. (Try SML or O'Caml, for instance.)
If you want to make sure people don't make a particular mistake, make it impossible for them to do so. That means you either 1) fix C to eliminate all buffer overflow issues (impossible, IMO), 2) enforce proper coding technique, possibly through a special string library and/or macros (very difficult on a project as large as an OS), or ditch C completely (virtually impossible given the size of the Linux code base).
- Stripe of right top fish is made of Sun logos
- Yellow left top fish is covered with Windows logos
Of course, only the blowfish will not get eaten by the cat (because of its spikes).But it doesn't really work. It's better than nothing, but if there's one thing that years of security bugs should have taught us, it's that there are always new classes of undiscovered bugs out there. You can eliminate every known bug, but that doesn't guarantee that there are no clever exploits that you haven't figured out but that somebody else has (or will) find out how to use. What you really need is a level of security that's orthogonal to code level security. That can be something like capabilities, mandatory access controls, or even just finer grained control over what the code is allowed to do than Unix's all or nothing model.
Right now, if I want my computer's CD burning software to be able to set itself at high priority to avoid buffer underruns, I have to run it SUID root. That's insane; it means that a single programming error in what reasonably should be a user accessable program could give somebody complete access to the system. That isn't security, it's a nightmare. We need a system where I can assign that program only the right to reset its own priority, and not complete run of the system. Yes, it's better if the code is audited and potential bugs are eliminated, but a system in which a single bug can completely compromise the whole system is badly designed.
There's no point in questioning authority if you aren't going to listen to the answers.
Because we area able to learn from the openbsd team. Their goal is to help everybody build more secure systems. MS security practice takes place behind closed doors and can not help anybody else.
In the end we will see if MS is able to actually execute their goal. OpenBSD already has.
War is necrophilia.
Since strncpy() does exactly the same thing, just don't bothering always NUL terminating the resulting string.
Data discarding can be detected by checking return values, you can't do much against people not checking the result of their call. The question is, what API is the less troubling ? strncpy() or strlcpy() ?