James Robertson on the recent security flaws announced in Jaguar:
Then you need to read this article (via Scoble). Yet another buffer overflow problem. This comes from the continued usage of C and C++. Yes, there are ways of finding those problems. And no, most people won't use those ways most of the time. The answer? Use a managed language - Smalltalk, Lisp, heck, even Java or one of the .NET languages. Or, keep producing security flaws....
The security flaws were announced on Bugtraq by @stake just after the release of Panther. Every OS has security problems (and these were rather low-impact bugs) so this would usually have been unremarkable. The controversy came from the fact that the only solution to the problems suggested in the security advisories was "upgrade to Panther", a $129 proposition in an industry where accepted practice is to fix security flaws for free.
Apple later announced their intention to fix the problems in Jaguar as well.
The bugs in question were:
- Mac OS X Long argv[] buffer overflow (CAN-2003-0895)
- Mac OS X Systemic Insecure File Permissions (CAN-2003-0876)
- Mac OS X Arbitrary File Overwrite via Core Files (CAN-2003-0877)
The first is a buffer overrun, certainly. The second is a file-permissions issue when copying an executable out of a disk image. The third is unsafe file-creation for core dumps that could lead to arbitrary files being overwritten, and core files being stolen.
Buffer overflows are dangerous and prevalent, and avoiding them is a good thing. One way to do this is to use a bounds-checking language/runtime, but there are certain things (such as large parts of an Operating System) that are still so performance-critical as to make such management an unwanted overhead. It is possible to write C programs securely (the $500 security bug bounty on qmail is yet to be collected), but it takes a lot of attention to fine detail, and avoiding the standard C library.
Don't let bounds-checking lull you into a false sense of security. Two of the three OS X bugs above weren't buffer overruns. Many IE exploits come from fooling the browser into thinking some content is trusted when it shouldn't be. A lot of the worst IIS exploits came from poor input verification, or Unicode hacks to get around it. Almost every webserver in existence has fallen victim to some form of directory-traversal attack. Applications like Bugzilla, PHPNuke and Postnuke have terrible security histories, despite being written entirely in managed languages.
Insufficient input validation and SQL/code injection attacks. Porous trust boundaries. Directory traversal. Cross-site scripting. Weak authentication policies. Insecure default configurations. Unsafe file creation. Race conditions. Information leakage. Resource starvation.
The enemies of security are complexity and inattention to detail. Using a "managed language" is one way to reduce complexity, but more than enough remains to make our lives very difficult. We just have to keep paying very close attention.
