It rather involved being on the other side of this airtight hatchway: Consequences of enabling the kernel debugger


In the category of dubious security vulnerability, I submit for consideration the following report:

A machine with the kernel debugger enabled is vulnerable to a denial of service attack from an unprivileged user. The unprivileged user need only deference a null pointer. Once this occurs, the computer becomes completely unusable to all users.

Um, yeah. That’s sort of the whole point of the kernel debugger, to halt system execution as soon as a problem has been detected. Enabling the kernel debugger requires administrative privileges, so it’s not like unprivileged users can force a system halt on their own; they need the help of an administrator to turn on kernel debugging first. At that point, you’ve already made it to the other side of the airtight hatchway. If you have an accomplice who is already an administrator, then you may as well just cut to the chase and tell your accomplice to add you to the administrators group, too. Then you can do much more than simply halting the system.

Clarification: As Bob noted, and which I apparently didn’t make clear enough from the title of the article, this message arrived as a security vulnerability report. It’s not a security vulnerability if it requires assistance from an administrator to pull off.

Comments (20)
  1. santosh says:

    start->shutdown ?

  2. David Walker says:

    I have a better one:  "A machine that is plugged in to the wall for power is vulnerable to a Denial of Service attack from an unprivileged user.  The unprivileged user need only unplug the power cord.  Once this occurs, the computer becomes completely unusable to all users".

    Take that!

  3. ads says:

    > start->shutdown

    an unpriviledge use cannot do that on every system (it can be a locked option – for example it is not available on terminal servers for non-admin accounts).

  4. mh says:

    How about: "A machine that is plugged in to the wall, running on battery, or in some cases even switched off is vulnerable to a Denial of Service attack from an unprivileged user.  The unprivileged user need only empty a bucket of water over it.  Once this occurs, the computer becomes completely unusable to all users."

  5. Someone You Know says:

    A machine that is plugged into the wall, running on battery, or in some cases even switched off is vulnerable to a Denial of Service attack from an unprivileged user. The unprivileged user need only detonate a thermonuclear device near the computer. Once this occurs, the computer and all users become completely unusable.

  6. Michael Mol says:

    A machine that is plugged into the wall, running on battery, or in some cases even switched off is vulnerable to a Denial of Service attack from an unprivileged user. The unprivileged user need only summon el Diablo. Once this occurs, the computer and all users become completely unusable.

    Well, the users become unusable. Not sure about the coputer.

  7. Jonathan says:

    Your response is as if the report had said:

    "An unprivileged user can DOS a machine by enabling KD and …"

    Which is clearly incorrect. But the report correctly said:

    "A machine with KD enabled [by an administrator] is vulnerable to a DOS attack from an unprivileged user, which can…"

    Which is true (though not exactly a shocking revelation).

    David Walker, mh, Someone You Know: That’s quite unrelated – obviously, a user with physical access to the machine can do a lot.

  8. John Melville says:

    I think the scary part is not the question but the motivation for the question.  Clearly one of two options are present.

    1) Someone has software that only works with a kernel debugger attached — software that they think is ready for prime time.  Or

    2) Somebody thinks that attaching a kernel debugger to a production machine is a good way to solve a problem.

    Either case should make you very afraid.

  9. Brendan Dowling says:

    This isn’t a question, it’s a notice.  It says, "Don’t leave the kernel debugger installed and enabled in a production system.  It will cause security problems."  

    It seems analogous to the automobile debug module.  You can operate your car with it plugged in, but you may get dust into the connectors and you might have trouble closing the hood.  

  10. a random passerby says:

    @Jonathan: The question was actually answered as if the report were as you read it. In the answer, it’s pointed out that the KD need be enabled by an Administrator. So the user can’t DOS the system on their own, they need an admin to enable the KD for them, and if the user can do that then it’s analogous to giving the user admin rights in this case.

    Also: A machine that is plugged into the wall, running on battery, or in some cases even switched off while encased in an EM-resistant case and buried 2 miles beneath the surface of the Earth with no way to access it is vulnerable to a DOS attack. Once this occurs, the computer is obviously owned by a government agency, at which point it isn’t doing anything useful anyways.

  11. Daniel says:

    @ads

    That reminds me of the policies on my uni: we (students) weren’t allowed to shut down or restart a computer, but those options were available on the logon screen.

    In other words, assuming turning computers off is a bad thing (since it’s disabled), you were strictly required to remain anonymous when doing such vandalism.

  12. kog999 says:

    @Daniel

    we had a policy like that at my old company. the logic was that we wanted users to leave their pc’s on at night so updates could be installed etc. However no matter how many emails we sent out people would still shutdown their pc’s when they leave. so we disabled the shutdown button from the start menu. This would force people to either hold down the power button or unplug the pc to turn it off. most people would not be willing to do that so they would just log out or lock their computer instead (well more like just walk away and the computer would lock itself after 15 minutes) though one or two would still hold down the button. So this ended up pretty much accomplishing our goal.

  13. Henke37 says:

    You never heard of wake on lan? Just let them power the computer down, and power it back up remotely as needed. Users are none the wiser, you are saving power and you get the job done.

  14. microbe says:

    With kernel debugging enabled the system halts when a NULL pointer is dereferenced?

    I can understand if it’s a NULL pointer derefenced in the kernel space. If it’s only in user space, why?

  15. Anonymous Coward says:

    I can understand if it’s a NULL pointer derefenced in the kernel space. If it’s only in user space, why?

    I think this provides the seed to why the question was asked / notice was given (depending on interpretation).

    They have something going wrong in kernel mode or are afraid something might and want to catch relevant data if shit happens, but whatever it is is unexpected / happens too rarely / is too hard to reproduce on the test servers / … so they decided to enable kernel debugging on (part of) the production systems.

    But then they discovered that any user can halt the system from user mode. Raymond didn’t deny this, so I’ll assume this is true, but I think it’s a very weird situation. Unless something goes wrong in kernel mode the system should certainly not be interrupted. (Note: if it isn’t true, then Raymond’s criticism doesn’t apply at all.)

  16. Pavel Lebedinsky says:

    With kernel debugging enabled the system halts when a NULL pointer is dereferenced?

    It doesn’t (in the default configuration). User mode debug breaks or single step exceptions will break into kd by default, but even that can be disabled by setting the /NOUMEX boot option.

  17. Bob says:

    > Which is clearly incorrect. But the report correctly said: "A machine with KD enabled [by an administrator] is vulnerable to a DOS attack from an unprivileged user, which can…"

    A machine with an incompetent administrator is going to have bigger problems than this one.

    And only a real freak knows how to attach a *kernel debugger* and also forgets to detach it after doing whatever debugging was necessary.

    In any case, according to Raymond this was a "security vulnerability" report, and not a "bug report" or a "request for help", and he didn’t say that the reporter was slapped with a wet fish instead of being helped.

    The correct response to an invalid security vulnerability report is to redirect the report to a more appropriate location, if possible with an explanation as to why "this is a vulnerability that requires you to have administrator access in order to exploit it" is not actually a vulnerability.

  18. unekdoud says:

    There’s way too many of these posts around. How about a new category for them?

  19. T-bone says:

    OK, but who reported it? Michael Howard or the newbie?

    I hope you get this for what it means, that I look forward to read your posts, but you probably don’t need to blog on every single minute variation of these clearly mistaken and obviously foolish vulnerability claims that come your way. We got the point already!

    You know, dogs biting men ain’t news.

  20. Jules says:

    I think people discovering a bug are way too ready to call it a security hole.  As an example, a few years back I was one of the maintainers of a free software assembler.  Somebody discovered a buffer overflow in part of the code, so if you had a particular directive with more than (IIRC) 32K of data on the line, you could cause code embedded in the line to be executed.  This was reported to us as a "remotely exploitable security hole".

    First of all, why is it even a security hole?  Surely, if you’re assembling a source file, you are more likely than not planning on running the resulting code, so wouldn’t a more direct approach be to just include your malicious code in the source?

    Secondly: why remotely exploitable?  I asked the reporter, and his response was along the lines of "well, the user might set up a service to automatically assemble files that are sent to them via email, for example somebody doing grading of programming assignments."

Comments are closed.