OpenBSD Journal
Contributed by jose on from the press dept.
Even the developers of the "secure" operating system suffer with C's faults. Theo and crew continually fix bugs in OpenSSH that result from subtle programming errors. And once they're all "fixed," people with talent for finding bugs, such as Solar Designer, look through the code and the floodgates open again.Yep, it's a continual race, and usually quite interesting.
(Comments are closed)
Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]
By Andrew Falanga () ccodewarrior@mailandnews.com on mailto:ccodewarrior@mailandnews.com
I'm not an anti-Java person so this comment isn't meant to start a war. The vast majority of buffer overflows are due to sloppy programming, use of gets() vs. fgets() and so forth. Or other types of sloppiness. No, I'm not a programmer on par with Theo or the rest of the crew, but they have their bad days too.
I'm rambling now. The basic point is, the types of vulnerabilities he's speaking of aren't due to language design. They are due to sloppy programming.
Andy
Comments
By chris humphries () chris@unixfu.net on mailto:chris@unixfu.net
the problem with c is that humans use it, and humans make mistakes, no matter how good the programmer.
his point was that using languages that dont require the c lower level access to memory allocation and managing threads/locks, not to use them. it would make the margin of human programming errors much smaller if c like access isnt needed.
disappointing that python wasnt also mentioned, hehe, but oh well :)
i generally agree. writing c takes alot of time to write relative to other languages (generally). i would rather spend time on designing and writing the program to do tasks, instead of making sure memory is available and that i can use it, that my threads are safe, locks and race conditions are good, and checking these several levels deep. it is just nice to have that taken care of, so the only real security issues i am left with in programming is just programming design flaws with the program itself.
the article is good, though with writing an OS, it would be interesting to see if it would be possible for it to be written in something that isne c and asm. it kinda just needs that level of access.
though alot of programs that are in c/c++ dont really need that level of access to everything, and on modern systems, speed is really not that noticable, shoot, even kde is fast now for me, hehe.
needing c for os, crypto, and database stuff i totally see a need for, cause speed is needed. for msot everything else, i dont see why c is needed, but cool thing about languages out there is that you do have a choice.
playing is fun, and choosing which to play with is half of the fun :)
i personally know a good number of languages, and there are pros and cons to each, and there is definately not one that is the magic answer. it is really just knowing the pros/cons and deciding which is best to use for the program, also now i have to take into account development and debugging time (time does equal money, it sucks but is true) and hiring programmers that know the language thru and thru.
trying to find python programmers that will move to cities that arent big is tough (like in my last job, which is still looking for python programmers , http://devis.com/, and this job. i ended up choosing perl, heh. i curse myself sometimes, but i believe it was good for job and business).
so in summary, sloppy programming is of course the biggest problem. second is we are human.
that article makes me want to audit apache, sendmail, and bind though ;)
Comments
By Anthony () on
C increases the number of ways that you can fuck up. If you increase the number of decisions that need to be made, it increases the number of mistakes that are made even if the mistakes/decision ratio remains constant.
A lot of the time, I've found it's useful to do a project in python, then translate it to C. Python is basically executable pseudo-code, and I can work out all the conceptually hard stuff about my project in it. Then, when I translate it to C, I don't have to make design decisions. I know what it does in Python, I just have to reproduce it.
It's possible I could learn to have that clarity of thought without python's help, and I'm not saying that this is a magic bullet that others should use, but it increases my productivity.
I write lines of python at about the same rate as lines of C, but C increases line count by about a factor of 2-5. Also, translating python to C is very fast, because as pseudo-code it's precise enough that there's no ambiguity.
By riffraff () on
ruby is in many ways similar to Python and their power/expressiveness is comparable.
But Ruby has a built-in system of security, trough the usage of (un)tainted objects and 5 predefined safe levels (you can add more if you want).
For example, running with $SAFE=1 Ruby won't allow tainted data(i.e. user input) to interact with untainted objects.
With $SAFE=4 you cant do system(), eval(), trap signals, can't load a file from a world-writable directory, can't open an external file that is not already open, redefine functions or global variables, and stuff like this :)
but, btw, if the programmer is dumb the code is dumber
By tony () tony@libpcap.net on libpcap.net
the whole point is security from the foundation. without a solid foundation, the whole thing crumbles.
By Anonymous () on