An end to buffer overflows, and a beginning to serious user education ... These are a few of my favorite things.
Most users wouldn't know a strong password if their system administrator handed it to them on a Post-It note
Therefore, rather than provide predictions for the coming year, I have a wish list of what I'd like to see happen. Unlike predictions, I can't gloat when my wishes come true -- but I can still say "I told you so," when an item on my wish list might have prevented an incident from occurring.
My wish list is, in order of priority: an end to buffer overflow and format string attacks; automated updates that work; correct and consistent cryptographic signatures on software packages; improvements to user education at all Internet sites; and no more executable attachments in email.
Eliminating buffer overflows would definitely be the thing I'd most like to see in the coming year. It's also the least likely to happen. Buffer overflows are generally the result of sloppy programming. They occur where programmers forget to check the size of text input, overwriting the original code, or altering the flow of execution, thereby allowing malicious users to execute their own code instead.
Even the combined efforts of the entire Internet and the shaky economy are unlikely to rid us of all sloppy programmers this year. Worse yet, most of the buffer overflows to be exploited in the coming year are already present, waiting to be discovered.
There are steps that could be taken, however, to reduce our exposure to these pernicious attacks. For starters, Linus Torvalds (and Marcello Tosatti, the maintainer of the current stable Linux kernel) could adopt Solar Designer's non-executable stack patch. (While the patch has not yet been updated for the 2.4 kernel; this work is in progress.) This would prevent the kernel from executing code in places typically used to store user data.
While this would not stop all buffer overflows -- as Torvalds has said in the past when rejecting calls for the inclusion of the patch -- it would stop a significant subset of them, forcing attackers to redirect their efforts to other problem areas. Just because one window latch is broken doesn't mean we should leave all of our doors unlocked.
Another step towards stopping buffer overflows would be the adoption of Immunix's StackGuard patches to the GNU C Compiler (GCC) used by all Linux distributions. Red Hat Linux 8.0 is likely due by the end of the year, or perhaps early next year; by adopting StackGuard, Red Hat users could be protected from another significant subset of buffer overflow attacks.
While not all software will currently build with StackGuard, Red Hat could do the Linux community a huge favor by working to patch programs that fail to work with StackGuard. That would in turn pave the way for the adoption of StackGuard by the standard GCC package. It's unlikely that Red Hat will take this step, but it would eliminate many of the worst attacks against their distribution.
Crispin Cowan, of Immunix, stated on the Robust Open Source mailing list that their version based on Red Hat 7.0 was immune to all sixteen known remote root exploits for that distribution. While this is due not only to StackGuard but also to their FormatGuard patch to the GNU C library and other projects of theirs, adoption of these GPLed technologies would limit attacks against Linux systems.
Another technology that would limit attacks against Linux boxes, and the next item on my wish list, is automated update systems that work. While Debian's apt package-management front-end comes close, as do some of the automatic updaters for RPM, too much user input is required to correctly configure Debian packages. With all of the package update systems, there should be a front-end that proactively checks for updates on a regular basis and notifies users that they should be installed.
On this front, we've seen real progress over the past several years: progress that can, and likely will, continue. It's also possible that the perfect automatic update system is already available; email me if you think you've used it already. My hope is that this problem can be solved by year-end.
Of course, this automatic updates are useless without
To see this wish list item come true, we'd need consistent and correct package signatures from all major Linux distributions, including better Debian support. (Debian is
User education is another major gap. Most users wouldn't know a strong password if their system administrator handed it to them on a Post-It note. (And, worse still, they'd stick the Post-It note right on their monitor for the world to see.) Many users can be socially engineered into sharing their passwords over the telephone with an unknown party who merely sounds like they need it. Few users probably know how to change their passwords, and fewer still actually do so on a regular basis.
Poor understanding of system security isn't entirely the fault of the user, however: developers and administrators need to provide well-written documentation that doesn't overwhelm the user.
Too many systems have no documentation at all, and what documentation there is tends to be badly written or excessively long. Few sites even have password guidelines that users actually read. It's the job of system administrators to verify that users understand how to use systems securely. As incidents occur at sites all over the network, this should improve, but far too slowly to fulfill my wish.
My final wish list item for the new year is an end to executable attachments, on all platforms, with all mail readers.
While it's still mostly a problem for Windows software, I'm still sick of seeing dozens of email Trojans on a weekly basis. Users need to learn not to click on everything that shows up in their mailbox, and developers need to think up new ways to keep this from happening.
It's not likely, but what is a wish list for, if not as an aid to dreams?