Holy cow, I wrote a book!
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.
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.
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.
Did you hear about that tracer-T program ?
Yes, but shouldn't the bug still be checked out? I mean not as a security vulnerability, but as more of a stability bug.
@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.
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?
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.
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.
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.
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.
Raymond's corollary to the Godwin's law: no matter what, someone will bring up DRM eventually.
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.
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
@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.
@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.
@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).