Security Samizdat

Bruce Schneier comments on the article by The Register about the UK’s new class of Type 45 destroyers and Vanguard-class submarines (carrying Trident ICBMs) will run Windows-based operating systems.

Is it wise? Well, all software has bugs. Operating systems are big pieces of software, therefore they must have lots of bugs. It has happened before. These kinds of systems should have multiple checks and redundancies built-in to avoid for any kind of problem. And proper support, heavily trained. And a good Change&Configuration Management process.

As The Register says (with a healthy dose of sarcasm):

“Again, Windows platforms may be troublesome to maintain, but most civilian sysadmins simply wouldn’t believe the resources the navy can throw at problems. A present-day Type 42 destroyer carries at least four people who have absolutely nothing else to do but care for the ship’s command system. As of just a few years ago, this was still a pair of antique 24-bit, 1MHz machines each with about 25KB of RAM.

Two of the seagoing sysadmins will be senior technicians with at least five years’ expensive general training and months of courses specifically tailored for the kit they are minding now. Their assistants will be less skilled, but still useful. They can take care of drudgery – minor bumf, safety checks, making tea – freeing the real techs for serious work. And the on-board team would seldom be expected to cope with anything as complex as a software update. That would be done in harbour by more advanced specialists, probably including vendor reps. Nor do the combat sysadmins get lumbered with general IT desktop support; there are other people to do that, also lavishly trained. If any organisation can keep Windows functional, it’s Her Majesty’s navy.”

There is an article at ZDNet (”Hacker, Microsoft duke it out over Vista design flaw“) which describes the controversy between the hacker Joanna Rutkowska and Microsoft’s Mark Russinovich over an allegued design flaw of Vista UAC.

In a nutshell, Vista assumes automatically that all application installers should be executed with elevated privileges. There is no possibility of running installers with normal user privileges (for example, if no drivers need to be installed or changes to the system done)

Russinovich’s explanation sort of admits that a vector for sohisticated attack is technically possible.

Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs. So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs? To get us to a world where everyone runs as standard user by default and all software is written with that assumption.

According to Bruce Schneier,

What’s interesting is that Microsoft is positioning this as a trade-off between security and ease-of-use. That’s correct, of course, but it seems that someone made a bad decision in this regard.

Joanna posted another entry in her blog clarifying her position:

There are two things which should be distinguished:

1) The fact that UAC design assumes that every setup executable should be run elevated (and that a user doesn’t really have a choice to run it from a non-elevated account),

2) The fact that UAC implementation contains bug(s), like e.g. the bug I pointed out in my article, which allows a low integrity level process to send WM_KEYDOWN messages to a command prompt window running at high integrity level.

I was pissed off not because of #1, but because Microsoft employee - Mark Russinovich - declared that all implementation bugs in UAC are not to be considered as security bugs.

True, I also don’t like the fact that UAC forces users to run every setup program with elevated privileges (fact #1), but I can understand such a design decision (as being a compromise between usability and security) and this was not the reason why I wrote “The Joke Post”.