It rather involved being on the other side of this airtight hatchway: Dubious escalation


Consider this type of dubious security vulnerability:

There is a buffer overflow bug in kernel driver X. To exploit it, call this function with these strange parameters. The exploit works only if you are logged on as administrator, because non-administrators will get ERROR_ACCESS_DENIED.

Yes, this is a bug, and yes it needs to be fixed, but it's not a security bug because of that only if you are logged on as an administrator clause.

It's another variation of the dubious elevation to administrator vulnerability. After all, if you're already an administrator, then why bother attacking kernel mode in this complicated way? Just use your administrator powers to do whatever you want to do directly. You're an administrator; you already pwn the machine. All you're doing now is flexing your muscles showing how cleverly you can take down a machine that's already yours.

Comments (40)
  1. MItaly says:

    These are quite common "vulnerabilities"; I remember that few years ago a self-proclaimed, 16-years-old "security expert", discovered an incredible security vulnerability of the Windows firewall: if you’re an administrator, it can be configured and even shut down with some shell commands.

    And this person went on TV several times.

  2. Nathan_works says:

    Did you hear about that tracer-T program ?

  3. Kv3 says:

    Yes, but shouldn’t the bug still be checked out? I mean not as a security vulnerability, but as more of a stability bug.

  4. Marquess says:

    @Kv3

    It says “Yes, this is a bug, and yes it needs to be fixed” in the article.

    Yeah, I think they got that part covered.

  5. Paul says:

    Did they fix that one in 3.1 where you could overpower the user of another computer, launch a command prompt and delete win.com?

  6. Joe Dietz says:

    Yes and no.  Some security products perform a sort of UAC-style sandboxing of the administrator account, either by not allowing the administrator full administrator privileges, or by disallowing some other functionality later.  These products typically rely on ring-0 remaining more privileged than ring-3 to enforce this.  Of course to enforce this you have to be able to tightly control or at least monitor what ring-0 code that the ring-3 administrator is allowed to load (protected media path might be an in-box example of such a security scheme).  At that point, ring-0 exploits become interesting from a security standpoint.

    Of course, you could also point out that layering mandatory access control over a discretionary access control system is a fools errand, partially because drivers will always have bugs.

  7. Alexandre Grigoriev says:

    Actually, this class of bugs (when an IOCTL to a driver is causing kernel buffer overflow) is legitimate and considered serious enough. Even though the IOCTL can only be issued from a privileged process.

  8. Marquess says:

    They should also fix that vulnerability where they ask a user out to a drink an somehow make the latter tell his password.

    And don’t get me started on rubber-hose cryptanalysis.

  9. Médinoc says:

    Actually, this may become a real vulnerability with those pesky "protect copyrighted contents from the user" measures: DRM requires the kernel to forbid things even to the computer administrator.

  10. bozox says:

    Raymond’s corollary to the Godwin’s law: no matter what, someone will bring up DRM eventually.

    [Second corollary: Followed by driver-signing. -Raymond]
  11. Nick Lamb says:

    Security bug: A bug which affects the system security

    System security: Defined by the user

    Maybe the user has a program which runs with administrator privileges and calls this particular function with externally provided parameters. This may (by the function’s definition and the customer’s requirements) seem to be completely safe. But thanks to this bug, it no longer is. A security bug.

    Therefore, all bugs are potentially security bugs. Hence the OpenBSD bug fixing policy and Linus’ refusal to flag particular kernel bugs or git commits as “security”. The marketing department gets to have people who tell everyone how safe your OS is, but the technical people just have to fix bugs.

    [If you write a component which will push whatever button in the nuclear reactor control room anybody tells it to, that’s not a flaw in the control room. -Raymond]
  12. Christian says:

    I would be very happy if this strict idea of "Admin=can load driver=can do anything" would still be true.

    And I was shocked when MS gave in to Gibson with XP SP2 and reduced the maximum amount of open TCP-connections (that are not yet established) and dumped down the raw interface so that it does not allow DDOS over this.

    Not only is this against the priciple behind this blog posting (installing winpcap to inject packets is possible on vista64 as far as I know and nobdy filters anything away) but also against the interest of the owner of the pc (with the filesharing software making lots of outbound connections ;-)  ), just to protect random targets on the internet.

    Too bad, that MS gave in

  13. Nick says:

    @bozox:

    As a corollary to Godwin, does the person who brings up DRM also lose the argument?

    Sure, this bug requires administrative access to exploit, but what if there’s a DIFFERENT bug that allows for privilege escalation?  Now a normal user can exploit this bug as well!

    Gosh, no wonder Windows is so terrible! Microsoft obviously needs more eyes to see these kinds of obvious problems.

    [I thought I mentioned in the article that this is a bug that should get fixed. It’s not a security bug, but it should be fixed as a defense-in-depth measure. -Raymond]
  14. Nick says:

    @Christian:

    How is it not still the case that "Admin=can load driver=can do anything"?  On my Win7 machine I’m an admin, I can load a driver, and that driver runs in the kernel.  Are you talking about requiring signed drivers on 64-bit?

    Also, MS hardly "gave in" to Steve’s wild ramblings about the doom of the Internet.  They didn’t get rid of "raw sockets" like he cried, and they didn’t even limit the number of open TCP connections.  What they did limit was the number of half-open connections.  Big difference.  Poorly written peer-to-peer clients had an issue with this limit, but pretty much everything else worked fine even with it in place.

    Not that it matters.  The artificial limit was removed in Vista SP2 and Win7.

  15. Josh says:

    @Nick: The may not have gotten rid of raw sockets completely, but they totally hosed a project of mine that relied on forged return address headers and a three way protocol implemented in UDP to enable semi-anonymous file sharing without the overhead of a proxy server.

    I can’t really blame them for it, but that won’t stop me from holding a minor grudge for making that project more annoying (the documentation of the change was hard to find at the time, so I spent quite a while trying to figure out the problem without success).

  16. Nick says:

    [I thought I mentioned in the article that this is a bug that should get fixed. It’s not a security bug, but it should be fixed as a defense-in-depth measure. -Raymond]

    Sorry, I guess I didn’t make my sarcasm clear enough.  My point was just that the argument that your original bug was a security problem was the same as my fake argument in that post.  I figure they’re the same thing except that in the original case the "exploit" is typing in the password of an administrative account.

  17. Anonymous Coward says:

    Whether this is a security bug depends on what about logging in as an admin changes so that the bug works. This information isn’t provided, so it’s impossible for us to judge and therefore you shouldn’t push your opinion on us as we can’t verify it.

    And this isn’t just a theoretical objection either. There are lots of things I can’t do on my computer even when I’m logged in as an administrator without entering a password or logging in with a ‘special’ account. And processes I run don’t always have all the permissions that I have either.

    [As I recall, the driver basically says “if (!UserIsAdmin()) return STATUS_ACCESS_DENIED;” -Raymond]
  18. PiersH says:

    If this isn’t a security breach then signed-only driver loading on x64 isn’t a security feature. What is it, then?

  19. Jonathan says:

    PiersH: It’s a stability feature, which verifies that all drivers passed the WHQL test suite.

  20. Worf says:

    Raw sockets wasn’t a new feature, because you could do them way back when WinSock 2 was around (Win95 era). It’s just that Winsock saw an IP header and rewrote the source address always.

    XP was the first Windows to get rid of this, and SP2 put it back. Probably not necessary anymore since people moved to syn-cookies which made syn-flooding useless (spoofing source addresses is a necessity to syn flood. Otherwise your stack will see a syn-ack reply and do a RST, which frees up the host).

    As for getting rid of stupid things in Vista/7, that’s more because the stack got rewritten with NDIS 6 and its new dataflow architecture.

  21. GWO says:

    @bozox: Raymond’s corollary to the Godwin’s law: no matter what, someone will bring up DRM eventually

    Without getting into the ethics of DRM, it does seem to act as a counter-example to Raymond’s assertion that “You’re an administrator; you already pwn the machine.”

    [By pwn, I mean “have compromised security and gained administrator level access.” -Raymond]
  22. Marquess says:

    Well, there is that driver (which I won’t here), that is properly signed, and whose job is to load other drivers. Reportedly still works in Windows NT 6.1.

  23. 640k says:

    Poorly written peer-to-peer clients had an issue with this limit, but pretty much everything else worked fine even with it in place.

    No, firefox also stumble on this limit when opening to many tabs to fast. I guess M$ defines this as a "feature".

    The artificial limit was removed in Vista SP2 and Win7.

    More info (proof) on this would be appreciated.

  24. 640k says:

    PiersH: It’s a stability feature, which verifies that all drivers passed the WHQL test suite.

    No it’s not. The signed-only limit is only there to make all driver developers pay for a authenticode cert. You have to PAY to run code in ring0.

  25. ring leader says:

    This is why drivers should run in ring1 instead of ring0.

    As OS/2 did.

    As the i386 expected software to do.

    A buggy driver should not be able to bring the system down.

  26. Marquess says:

    @640k:

    Last time I checked, domain certificates were sufficient.

    @ring leader:

    What’s that ring 1 you’re referring to there? Two of the three supported architectures for Windows NT 3.x didn’t have more than two rings!

  27. Nick Lamb says:

    [If you write a component which will push whatever button in the nuclear reactor control room anybody tells it to, that’s not a flaw in the control room. -Raymond]

    At 26C3 several people demonstrated some very subtle nasty tricks that rely on bugs people like you would feel confident aren’t “security bugs”. These are great for black hats because (thanks to the kind of thinking you’ve demonstrated) they don’t tend to get patched, unlike “real” security bugs.

    My favourite doesn’t really relate to this scenario, although it does involve a hardware driver. This a trick which requires that your victim has GigE and a particular network card which has a corruption bug when unexpectedly receiving jumbograms. The grey hat manages to deliver crafted packets through a firewall to userspace on a machine despite firewall rules that forbid any packet of that sort, and all because of this “non security” bug.

    [Where did I ever say that this bug shouldn’t be fixed? For this bug to become a security issue, two things need to go wrong. Surely this takes lower priority than fixing security issues that arise when only one thing goes wrong? -Raymond]
  28. Mike Dimmick says:

    Unfortunately most people are still administrators on their own computers; certainly on Windows 2000 and XP, and it’s (sadly) common for them to turn UAC off, or put it in no-prompt mode, on Windows Vista and even 7.

    It’s not much of a mitigation if very few people are running in that configuration. Chances are that some piece of regular malware – usually purporting to be a ‘security scanner’ – will start to use the hole.

    (Low rights regular user since 2003 – but part-time IT support at my job.)

  29. David Walker says:

    @640K:  Do you really think that making drivers be signed is for MS to make money?  The amount of money is trivial in the scheme of things.

  30. Nick Lamb says:

    [Where did I ever say that this bug shouldn’t be fixed? For this bug to become a security issue, two things need to go wrong. Surely this takes lower priority than fixing security issues that arise when only one thing goes wrong? -Raymond]

    You didn’t say it shouldn’t be fixed, black hats aren’t relying on you never fixing it, they’re relying on your customers never applying the patch because the other six patches that month were labelled "security fix, important" and this one wasn’t so they never got to it.

    As to priorities, those are an entirely unrelated can of worms. Accepting that all bugs can have security implications AND that it’s often easier to fix the bug than figure out the exact security implications doesn’t lead to any obvious policy about which order to fix them in. No easy answers, I’m afraid.

  31. ring leader says:

    @Marquess:

    Only a few ancient NT kernels do support other architectures. Most NT kernels, all of those developed the last 10 years, only run on architectures with 4 ring, x86-32/x86-64/itanium.

    [Are you saying that Windows NT should declare that it will only run on processors with 4 rings from now on? -Raymond]
  32. ring leader says:

    [Are you saying that Windows NT should declare that it will only run on processors with 4 rings from now on? -Raymond]

    NT supports lots of hardware feautures which are not available on all supported architectures. OS/2 was ported to ppc which only have 2 rings. NT could follow it’s example.

  33. 640k says:

    Marquess: Last time I checked, domain certificates were sufficient.

    The rules for drivers signing changes on regular basis. There are currently several windows oses with different requirements. The requirements are also dependant on the architecture and edition, which results in an abundance of different combinations of OSs, SPs, architectures & editions.

    Self signed certificates are not allowed any more for driver signing. Even if a domain certificate would be allowed, it requires a domain controllant. That’s another word for "windows server license + server hardware". An authenticode cert is cheap compared to that.

    No matter what you do, no matter how hard you try, if you want to run code in ring0, you will always have to pay.

  34. Nick says:

    > More info (proof) on this would be appreciated.

    Have some proof: http://support.microsoft.com/kb/969710

  35. Marquess says:

    @640k

    Windows Server is good at other things beside authorizing certificates. More importantly, when you need custom (in-house) drivers and can’t afford to run in test mode, you are probably in a situation where you are going to need a server anyway.

    (Just checked: Server 2008 R2 Standard goes for about 680€ these days. And well worth it.)

  36. Drak says:

    @Nick Lamb

    "they’re relying on your customers never applying the patch because the other six patches that month were labelled "security fix, important" and this one wasn’t so they never got to it."

    And that’s why you turn update notifications on and apply the updates when it tells you they are there?

  37. 640k says:

    You don’t enable automatic updates for server. Ever.

    Recent patches broke, OCS, Exchange, Sharepoint. Only yo name a few server software which was incompatible with ms own patches.

  38. Drak says:

    Ah, but I’d say that a lot of people running Windows and getting exploits on their PCs are NOT servers, but home users.

    And they should just turn those updates on.

  39. GWO says:

    [By pwn, I mean “have compromised security and gained administrator level access.” -Raymond]

    Fair enough.   But Adminstrators still have some checks on their activity.  DRM means there’s a second airlock that no-one can access, behind which content providers put their content.

    A bug that allows administrators through this content-provider-airlock is still a security bug, at least when viewed from the point of view of a content provider.

    I don’t know if this is such a bug, but a bug that allows arbitrary code-injection into the DRM enabling parts of the kernel could conceivably easily intercept some system calls and allow people to copy content that should be non-copyable.

    [Fair enough, but malware authors are not particularly interested in this second class of security flaw. -Raymond]
  40. Syllopsium says:

    OS/2 never used ring 1. Primarily it used rings zero (kernel) and ring 3 (user mode).

    In rare occasions it was also possible for OS/2 to use ring 2. This was primarily used by specially marked 16 bit IOPL (Input/Output Privilege Level) DLLs and permitted ‘direct’ access to I/O ports. In reality there were the delights of thunking from the 32bit program to the 16 bit DLL, and then call gates and instruction trapping enforced by the kernel/processor.

    More than you could ever possibly want to know, written by Holger Veit here : http://www.edm2.com/0307/32-bit-io.html

    Later on it was possible to write almost entirely 32 bit device drivers; this is a subject already *way* offtopic for here. Google it.

    This also leads to two other points :

    1) Comparing anything to the aberation that was OS/2 PPC is a mistake. PowerPC is not x86. OS/2 PPC was technically and commercially stilborn. OS/2 x86 from 2.x onwards consists of a lot of 16 bit assembly and an increasing amount of 32 bit code in user mode (Gpi, Win were initially 16 bit until 2.0 SP1 and 3.0 respectively). It is architecturally different than many other operating systems.

    2) Comparing Windows security to OS/2 security is laughable. OS/2 is a single user system strongly tied to x86 architecture and with no significant security subsystem. It has more holes than swiss cheese, even with the optional, obscure ‘security subsystem’.

    I loved OS/2, and used it until 1999 : far longer than anyone sane should have done. After that, I switched to NT 4.

    OS/2 never went through the re-engineering that Windows did between 3.x 16 bit and NT, so would have died eventually (not only did NT evolve significantly, it also did it right). It was good at the time, but move on, please?

Comments are closed.