Contributed by Dengue on from the maximum-uptime dept.
What would be marvelous is if someone could let me have some pointers explaining how the process works and, in particular, hard data about things like bugs found. I have a distinct recollection about a message regarding the *printf () audit but just can't find it anywhere on the web. This is a serious research project, which has some pages about it available at the Centre for Software Reliability of City University in London, UK."
(Comments are closed)
By Jason Stout () on
http://securityportal.com/closet/closet20001025.html .
Also a google search reveals a lot of good info.
http://www.google.com/search?q=writing+secure+code
Not exactly what you wanted per se but I think it will be helpful none the less.
-jason
By Anonymous Coward () on
Proactive might mean, "I read a lot of source." If you read a lot of source, at some point you may find a bug. You can apply this information to other parts of the source tree.
OpenBSD's core team also strikes me as well knit. Each member tends to be responsible for a specific area of the project-- and they collaborate. I doubt it is pulling teeth to get other members to look into a potential problem.
I assume they get back to each other quickly as well-- as an outside developer I usually receive a response within a day. So I doubt potential issues are put off for too long.
On that note, OpenBSD's core team tends to be made from seasoned developers. Which lends itself to figuring out the best possible solution.
By Arrigo Triulzi () arrigo@maths.qmw.ac.uk on mailto:arrigo@maths.qmw.ac.uk
Now for the real question: are there figures? Is there anyone who you think could take the time to reply to an e-mail on this subject in the core team? The last thing I want is to sound like a time-waster to them so any suggestion or data is welcome.
Thanks.
Arrigo
By Marc Espie () espie@openbsd.org on mailto:espie@openbsd.org
In the cases I've seen, it takes usually less than 6 hours between the time a security issue is noticed, and the resulting commit that fixes it. It is a question of priorities.
Pro-active is important too: fix potential problems. Don't sit on your ass trying to prove that the problem is exploitable. Going farther: provide better interfaces where conventional practice is obviously error-prone (to wit: strlcpy).
Look for patterns: a distressingly large number of security issues come from the same basic errors. Not knowing the API you're programming for (notice how OpenBSD manpages often get new sample code and extra caveats about common programming errors ?).
Obviously fishy code that's almost impossible to read, looks too clever to be good, and is plain wrong 99 cases out of 100.
And your standard buffer overflows and race conditions, a distressing number of times...
Many runs over the source tree happen as follow:
somebody notices something very fishy somewhere in a program. A bad programming pattern is identified. A full-scale search of the whole source tree is then run, that usually identifies at least ten instances of the same pattern.
Nice `success stories' of an incredibly hard to found bug don't happen. Most security holes are obvious in retrospects. Audits are tedious. The benefits are huge. The alternative not morally correct.
In the end, secure code simply is code without bugs. Written clearly. With a tendency to avoid cuteness, and to be plain and boring for 90 lines out of 100. It's the remaining 10 lines that make the code go fast and be smart anyways.
By Ed Trada-Oteh () ed@trada-oteh.com on trada-oteh.com/~ed
It would seem that the "Open" in "OpenBSD" certainly doesn't apply to being open about
their methodology.
There have been previous 'accusations' of
hypocrisy in the 'we fix our bugs but don't disclose' policy leading some people to see
OpenBSD as hiding it's vulnerabilities for
PR reasons. The OpenBSD response is that it's
simply 'not reasonable to disclose every
bug fix which may or may not be exploitable'.
So, a policy of not revealing any specific
methods or tools or numbers or details about
the source code audit basically leaves the OpenBSD
project as a sort of not-open open-source project.
Good luck.