Excellent point, mohaughn. It definitely depends on the role of the system when judging the severity of this bug. When I replied, I was considering the target system to be an Exchange server, print server, or some other production-level, mission-critical role. Like many UNIX systems, these systems rarely see a console operator when they're running smoothly. The security around these consoles needs to be air-tight. The student lab/library however is a completely different scenario where security is compromised by the need for accessibility. However, while this bug could easily be exploited on these public systems, sensitive data should never be stored on them. If such data needs to be accessed, it should be remotely accessed from a central server and distributed accordingly. Systems whose keyboards are touched by several hands should be carefully watched and seldom trusted.

problemchild -- I think we agree, just not on the terminology. When I say "Security is already compromised if you have access to the console", by console, I'm talking about unhindered access to the physical system. By removing the floppy drives, adding padlocks, adding security guards/cameras, using infared beams and sophisticated biometrics, you're adding physical security that prevents my unhindered access to the physical system. I consider the BIOS passwords and boot order part of the software of a system. If you were just to employ those software controls without some kind of physical deterrent in combination, those software controls are useless. So I agree with you that there are ways to keep someone from monkeying with a console, but not without some kind of hardware deterrent.