Slashdot Mirror
Microsoft Plugs "Drive-By" and 14 Other Holes
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.'"
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, as well as for Windows 2000 Server. On the latter, which harbors a bug in its implementation of the License Logging Server, 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 and one in Word with MS09-068. Both updates also affected the Mac editions, Office 2004 and Office 2008.
For more info, check out the top six listings here.
My work here is dung.
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
"...I think the Microsoft hatred is a disease." - Linus Torvalds
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.
The road to tyranny has always been paved with claims of necessity.
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 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.
I discovered this bug (check the credit section 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.
ex$$