Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Why is Control-Alt-Delete the secure attention sequence (SAS)?

Why is Control-Alt-Delete the secure attention sequence (SAS)?

  • Comments 50

When we were designing NT 3.1, one of the issues that came up fairly early was the secure attention sequence - we needed to have a keystroke sequence that couldn't be intercepted by any application.

So the security architect for NT (Jim Kelly) went looking for a keystroke sequence he could use.

 

It turned out that the only keystroke combination that wasn't already being used by a shipping application was control-alt-del, because that was used to reboot the computer.

And thus was born the Control-Alt-Del to log in.

I've got to say that the first time that the logon dialog went into the system, I pressed it with a fair amount of trepidation - I'd been well trained that C-A-D rebooted the computer and....

 

  • G. Man, Ian just about nailed what the SAS is about - it's not that the hardware is special, but instead no application can fake a control-alt-del sequence.

    And thus you can't write a trojan logon dialog - all the user has to do is to type C-A-D and get the real one.

    Sushant, it's my understanding that Apple's less concerned with slavish backwards compatibility - they're willing to break applications in favor of new designs.
  • > I thought the point was that only C-A-D generates a hardware interrupt that the OS can trap. Something else does like ctrl-alt-space would not generate such an interrupt and so a trojan could fake the login screen. Is this not correct?

    No. Under NT, userland applications don't have direct access to the hardware at all (unlike in DOS, where the fact that it *is* a hardware interrupt came into play).

    Everything an application gets, it gets because the kernel gave it to them. Since the kernel sees it first, it can perform any filtering on it that it wishes. There is no *technical* reason that the SAS is C-A-D. The NT kernel could just as easily and securely trap Ctrl+SysRq and not pass it on to applications. (In fact, this is the case with NT on Alpha -- the sequence has *no* special meaning on that hardware, yet remains just as secure.)

    As mentioned, C-A-D was chosen solely to avoid regressions; since it was the least likely key combination that an application would be looking for.
  • Larry, isn't there a DirectX flag these days to inhibit C-A-D? I remember playing around with it and naturally locking everything up. I don't remember if it might have been in 9x, though.
  • CN: There might be for Win9x, but there certainly isn't for WinNT. If there was, it'd be a massive security hole - the SAS has to be guaranteed to prevent spoofing the logon dialog.
  • It's no longer the case, apple changed, but in the past,

    MS - Software compatability - all old programs run.

    Apple - Hardware compatability - all new programs run on old hardware (even if it took 20 minutes to startup the app).
  • This 'slavish compatibility' has failed somewhat for XP SP2 - you finally decided to make security come first. From various MSDN blogs I get the impression that the attitude was 'if we must break it, let's break everything once'.

    However, Joel Spolsky seems to think that the problem is deeper - that the compatibility camp in MS has been outweighed by the new products camp.

    What you are saying (I think) is that MS will try not to break compatibility, even in Longhorn. How far will this go? Will security concerns still trump compatibility, as with SP2?

    I take it that you don't share the same concern, or feel the same sense of loss, about breaking compatibility with open-source software ;-)
  • There will be one thing that will break a lot of compatibility: 64-bit Windows doesn't alow 16-bit Windows apps. Didn't Gates demonstrate DOS VisiCalc running on Longhorn? There's going to be a lot of 16-bit apps (e.g. old games) that won't work anymore once 64-bit becomes mainstream.

    Microsoft could integrate Virtual PC into the OS in some fashion in order to allow 16-bit apps to run.
  • Jonathan's right, 64 bit windows removes the DOS subsystem. And I'm not sure that it's the right decision - there are a number of x32 apps out there that still use 16bit setup technologies.

    And the server platforms have removed support for Posix and OS/2.

    It'll be interesting to see if the 16bit removal decision sticks.
  • Mr Blobby: That's actually gray. We've changed from "Every application must run" to "Every application must run unless running it would mean opening up a security hole".

    That's actually not a huge difference.

    And I respectfully disagree with Joel on this one - he's referring to the public face of Microsoft's tools development organization (MSDN Magazine, etc). Those organizations are all about all about selling development tools, thus they focus on "the new thing".

    But the OS group has a different charter - we focus on ensuring that your LoB applications (or games, or productivity applications, or whatever) will continue to work from release to release.

    The platform SDK (or the C/C++ runtime library, which is written to the platform SDK) defines a binary compatibility layer that is carefully upwards compatible. The fact that the source code of the application is licensed under an open source license doesn't matter - the <i platform /i> doesn't care.

  • Sorry for lack of research, but well:

    Application-specific quirksmodes (as of Simcity fame) don't/won't exist any more?
  • Mr Blobby,
    Nope, appcompat will still work and they're still there. That's how we resolve the issue of broken apps - we change the system behavior for the single broken app instead of changing the entire system for the sake of an app.

  • In which case, my previous comment about open-source apps still stands. However, that was just meant to be a joke... To make it less contentious, and more useful, how about this (broader) question:

    Out of the set of all apps which don't work despite the work you put into the binary compatibility layer, how do you go about selecting/prioritizing the subset which will get the quirksmode treatment?
  • From several comments I understand that Ctrl-Alt-Del is secure under NT-based kernels because NT-based kernels prevent applications from trapping it. So a Trojan-style fake login screen would be impossible if an NT-based OS is already running.

    If W9x is running then a Trojan-style fake NT-style login screen remains perfectly possible.

    For users to be secure, in addition to pressing Ctrl-Alt-Del, they'd better make sure an NT-based OS is actually running. Is there any way to be sure of that, other than rebooting?
  • Mr. Blobby: I guess I understand, but.. If an open source product is successful, then it will become successful because it is available in a binary distribution.

    Source distributions will NEVER be successful distribution mechanism (beyond the hobbiest or IT department level). User's just don't compile the code and run, they run pre-compiled binaries.

    If you've got the source code and your app breaks on Windows, then you can fix it yourself - by downloading the source and recompiling it, you take on all responsibility for maintaining your code. That's the behavior of a hobbiest or IT person, not a consumer. As I said, consumers use binaries.

    Norman, that's actually a really good point - a user that doesn't know the OS on the computer DOES have to reboot it to truly ensure that NT's running.
  • Sorry, my actual question got lost in pointless discussion about licensing. I am talking only about binaries.

    More clearly:
    When you design your new OS (or upgrade, or whatever) your testing team will find a number of apps which won't work, or have major bugs introduced. Do you actually go to great lengths to ensure EVERY app found this way will in fact work? If not, then how do you prioritise - severity of bugs and popularity of application would seem to be the obvious first starts. Also, presumably your testers give the third-party notice and help to fix the bugs themselves first?

    Another question:
    MS has recently been cutting down its test teams, because of the rise of automated testing, and the rise of the 'developer/tester'. However, presumably you do still have a large test team for app compatibility?
Page 2 of 4 (50 items) 1234