Digg this story   Add to del.icio.us  
A Security Wish List for 2002
Jon Lasser, 2002-01-09

An end to buffer overflows, and a beginning to serious user education ... These are a few of my favorite things.

By the middle of January, most columnists have graced us with their predictions for the coming year, as well as a review of their previous year's predictions. Unfortunately I have no correct predictions about which I can gloat, as I wasn't yet writing this column last year; fortunately, I also have no badly mistaken predictions to bury. I've also made a New Year's resolution not to waste time (incorrectly) predicting the future.

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.

An Apt Solution
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 proper pgp signatures on packages. I don't think that this will be the year that we see a slew of packages trojaned via transparent proxies, but I'd like to try and stick by my New Year's resolution a little while longer, so don't consider that a prediction.

Password: Educate
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 making progress, fortunately; I favor the alternative scheme in section 7.2 of this document.) The package managers would also need to implement a list of trusted signatures, for packages that could be installed automatically. It's possible that Red Hat will add the features missing from RPM in time for their 8.0 release, but I've heard nothing to indicate that it will really happen.

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?


SecurityFocus columnist Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.
    Digg this story   Add to del.icio.us  
Comments Mode:
A Security Wish List for 2002 2002-01-09
Anonymous (5 replies)
A Security Wish List for 2002 2002-01-09
Anonymous
A Security Wish List for 2002 2002-01-10
Anonymous (2 replies)
Languages can be fast _and_ safe 2002-01-10
Anonymous
Java Performance 2002-01-10
Anonymous (1 replies)
Java Performance (and app performance in general) 2002-01-26
The Shadow Knows . . .
A Security Wish List for 2002 2002-01-10
Anonymous
A Security Wish List for 2002 2002-01-11
Anonymous (1 replies)
Java vs Python 2002-01-20
Anonymous
A Security Wish List for 2002 2002-01-24
Amarendra GODBOLE [amar AT efn DOT org]
A Security Wish List for 2002 2002-01-10
Anonymous
A Security Wish List for 2002 2002-01-10
Anonymous (1 replies)
learn asm? dumb idea. 2002-01-14
player 2 (1 replies)
learn asm? dumb idea. 2002-01-20
Levi (2 replies)
stupid idea... 2002-01-30
Anonymous
learn asm? dumb idea. 2002-01-30
retro
Security Education 2002-01-10
Educator (5 replies)
Security Education 2002-01-11
Anonymous
Security Education 2002-01-14
Anonymous
Security Education 2002-01-19
Anonymous
Security Education 2002-01-19
Anonymous
A Security Wish List for 2002: the stack 2002-01-10
scott@surfprivately.com
We all have same urge to amend reality 2002-01-10
by law or action or by dreaming our way around it...
A Security Wish List for 2002 2002-01-10
Night Hawk
A Security Wish List for 2002 2002-01-12
Elc0chin0
A Security Wish List for 2002 2002-01-24
Amarendra GODBOLE [amar AT efn DOT org ]
A Security Wish List for 2002 2002-01-28
Anonymous


 

Privacy Statement
Copyright 2010, SecurityFocus