Microsoft Plugs "Drive-By" and 14 Other Holes 189
CWmike writes "Microsoft today patched 15 vulnerabilities in Windows, Windows Server, Excel, and Word, including one that will probably be exploited quickly by hackers. None affects Windows 7. Of today's 15 bugs, Microsoft tagged three 'critical' and the remaining 12 'important.' Experts agreed that users should focus on MS09-065 first and foremost. That update, which was ranked critical, affects all still-supported editions of Windows except Windows 7 and its server sibling, Windows Server 2008 R2. 'The Windows kernel vulnerability is going to take the cake,' said Andrew Storms, director of security operations at nCircle Network Security. 'The attack vector can be driven through Internet Explorer, and this is one of those instances where the user won't be notified or prompted. This is absolutely a drive-by attack scenario.' Richie Lai, the director of vulnerability research at security company Qualys, agreed. 'Anyone running IE [Internet Explorer] is at risk here, even though the flaw is not in the browser, but in the Win32k kernel mode driver.'"
Well... (Score:3, Informative)
Re:And the others? (Score:5, Informative)
What about the fourteen other fixes?
The article talks about them at the end (on the second page):
Microsoft also issued critical updates for Vista and Server 2008 [microsoft.com], as well as for Windows 2000 Server. On the latter, which harbors a bug in its implementation of the License Logging Server [microsoft.com], a tool originally designed to help customers manage Server Client Access Licenses (CAL), Storms urged users of that aged operating system to apply the patch pronto, even though the machines are probably well-protected.
"Windows 2000 Server has the logging server enabled by default, but those systems are likely behind multiple firewalls, and people running [Windows 2000 Server] are pretty cognizant of the fact that it's an older version and will act accordingly."
Excel and Word also received patches today. Eight vulnerabilities were addressed in Excel in MS09-067 [microsoft.com] and one in Word with MS09-068 [microsoft.com]. Both updates also affected the Mac editions, Office 2004 and Office 2008.
For more info, check out the top six listings here [microsoft.com].
+5 informative? (Score:4, Informative)
Good grief. MS offers ALL security patches to EVERYONE, including pirates, and also offers many other patches such as stability and performance updates to everyone as well.
---
"There seems to be a myth that Microsoft limits security updates to genuine Windows users," wrote Microsoft's Paul Cooke, who works in Windows Client Enterprise Security. "Let me be clear: all security updates go to all users."
----
From http://www.tomshardware.com/news/windows-pirate-bootleg-security-patches,7666.html [tomshardware.com]
Re:It's Still Windows (Score:5, Informative)
So in trying to bash Microsoft you're saying that Linux sucks?
Linux is a monolithic kernel. Windows is a hybrid kernel. Linux puts a lot more into kernel mode/real mode than Windows does. Many drivers in Windows are user mode drivers, for example, particularly printers. The only thing I can think of that runs in kernel mode in Windows and not in Linux is the graphics system -- which is why the screen flickers and changes resolutions slower in Linux and Windows tends to run full screen games and video better with DirectX, but it also rarely brings the system down... not that a system you can't get desired display output from is useful entirely.
Re:Yay, tight integration of browser with OS... (Score:5, Informative)
Anybody else think something is integrated with something else in a deeply, deeply wrong way here?
No, not really, at least, not in the way you're insinuating. The Win32k kernel mode driver is essentially the major component of the Windows kernel responsible for kernel-mode graphics related processing. Put more succinctly by MS from the MS09-065 [microsoft.com] security bulletin:
Win32k.sys is a kernel-mode device driver and is the kernel part of the Windows subsystem. It contains the window manager, which controls window displays; manages screen output; collects input from the keyboard, mouse, and other devices; and passes user messages to applications. It also contains the Graphics Device Interface (GDI), which is a library of functions for graphics output devices. Finally, it serves as a wrapper for DirectX support that is implemented in another driver (dxgkrnl.sys).
The handling of EOT (Embedded OpenType) fonts is apparently (at least partially) handled by the kernel and presumably a component of the GDI system. IE supports EOT fonts and presumably just hands them off to the kernel, after all, it is delegated the responsibility of handling them, so why re-implement it in IE? The flaw is not really in IE but in buggy code in the relevant processing. There is an argument to be made that IE really shouldn't be explicitly processing these fonts by default in an untrusted network (and this can be changed in the preferences, but is not the default), but the flaw itself is in the system call code itself; the latter is merely about reducing attack surface in the case of exploits such as this arising.
My point is, this isn't really a case of IE being "overly" coupled into the system (which isn't to say it isn't, just that I don't view this as an example of it). Whether it's sensible engineering to have the kernel handle this stuff is probably a far more interesting and valid argument. Protecting against system call vulnerabilities is pretty tough, as you do expect the kernel to be trusted, indeed, if you can't trust the kernel you have serious problems. A quick google seems to suggest Firefox doesn't support EOT fonts, and I'm not sure if any other browsers do either, but if they did, they may well have their own exploit situations as well.
Re:OK, just a second now... (Score:5, Informative)
I discovered this bug (check the credit section [microsoft.com] in the advisory), so can explain. The bug is in parsing a component of TTF files, which are handled by the GDI kernel subsystem in Windows. Anything that tries to load fonts can be used to exploit this vulnerability, as they will eventually reach this code, Internet Explorer just happens to be the easiest way to reach it remotely.
Other browsers _are_ affected, the difference is that there's only one level of indirection before the vulnerable code in Internet Explorer, and at least two in other browsers. This is because IE supports EOT files directly, which via TTLoadEmbeddedFont() are decoded and passed straight to GDI, where as other browsers take a TTF input, convert it into an EOT and then pass that to TTLoadEmbeddedFont, so you have to convince three different chunks of code your input is valid (the browser, t2embed, then gdi), instead of just two in IE.
If you use any browser that support @font-face on Windows (Safari, Firefox 3.5+), you should still patch and reboot.
Re:Would the big customers know more? (Score:2, Informative)
Yes, the appropriate contacts in such organizations get informed. Chiefly, the CIOs and their assorted assistants down the IT chain. What they then do with that information is up to them. There's a reason these companies pay for their overpriced support contracts and license aggreements with Microsoft.
I know the major security vendors like Symantec are also informed.
This has been addressed several times (redundantly, I might add) in Slashdot articles over the years, and can probably even be confirmed by your own IT department.
Re:Yay, tight integration of browser with OS... (Score:3, Informative)
From what I understand: GDI functions are in the kernel for speed reasons - constantly switching to usermode just to draw things slows down the system.
Vista moved it into userspace, and lots of users complained about slowness. Looking at the vulnerability details, this just gives you privilage elevation on Vista (and related servers), not remote code execution.
For Windows 7, MS moved GDI back into the kernel, with some redesign. So they apparently fixed this issue when they returned GDI to user mode.
Again, just my understanding, could be wrong.
Re:Yay, tight integration of browser with OS... (Score:3, Informative)
NT 3.x supported user-space drivers and was criticized by reviewers for poor graphics performance (especially those who wanted to run visualisation/CAD apps on it). But it was rock-solid, as you can imagine.
NT 4 introduced kernel-mode display drivers, which helped it become very popular with engineers who needed these apps (remember, the only other 'mainstream' OS on the market at this time was Win95/98 and System 8/9; NT was rock-solid by comparison and Linux didn't have many commercial apps at this time).
Given that stats show that 3rd-party drivers are the #1 reason behind Windows blue-screens, starting with Windows Vista, Microsoft started to use the mini-driver approach for drivers. They've expanded and refined the use of such drivers with Windows 7.
Essentially, vendors write a user mode client driver that executes in user-space, with some basic functionality being implemented in kernel-space by a Microsoft-written and Microsoft-QA'd driver. So you get crash resistance without losing speed. See Layered Driver Architecture [microsoft.com] on MSDN for more.