Warning/alert to all Windows users

It would seem that there is a very bad security hole in windows systems that will allow, on un -patch systems, a root/kernel attack that AV software will not block or detect by just going to the wrong websites.

Microsoft had push a patch out last Tuesday and it is very important for us all to be sure that this patch is installed.

I am adding parts of the transcript from the GRC Security Podcast that cover this matter in details see below.

Side note there is also a problem in SSL that we all depend on for our banking etc and that is cover on this week GRC podcast also so you might wish to go to GRC and listen to this week complete podcast.
--------------------------------------------------------------------------------------

GIBSON RESEARCH CORPORATION http://www.GRC.com/

SERIES: Security Now!
EPISODE: #223
DATE: November 19, 2009
TITLE: A Security Vulnerability in SSL
SPEAKERS: Steve Gibson & Leo Laporte
SOURCE FILE: http://media.GRC.com/sn/SN-223.mp3
FILE ARCHIVE: http://www.GRC.com/securitynow.htm

LEO LAPORTE: This is Security Now! with Steve Gibson, Episode 223 for November 19, 2009: The Trouble with SSL.

LEO: Okay.

STEVE: Not surprisingly. One of the - I was going to say the "baddest." One of the worst problems that Microsoft patched last Tuesday, last week, the second Tuesday of November, is heavily expected by the security community to be exploited very soon, if it's not even - if it's not already being done. So I wanted to further encourage - I know that the fact that Microsoft patches typically require you to reboot your machine, I know that I've been in a position where I've got so many things open and set just the way I like, and I'm in like the middle of things, that rebooting the system right then is a problem. But there's this problem with the embedded open type fonts, EOT fonts, which, well, there's a couple lessons here. It's a font-parsing bug which allows remote code execution. The problem is that it's a kernel bug.

LEO: Ooh.

STEVE: So it's an overflow that occurs in the kernel. Well, since these EOT files can be compressed and encrypted by their spec, their spec supports encryption, that makes it extra difficult for antiviral software to see what's going on, because it's an encrypted payload. And so that's expected to thwart AV. And so it'll be systems which simply load a page. This is the other reason it's expected to be a big deal is that it's the classic drive-by problem where you just get some text on a website, and it can take over your machine. Interestingly, because this is a kernel-level problem, Vista's IE7 and IE8 sandboxes, which are designed to protect the system, offer no protection for this exploit. And again, because it's a font-rendering problem in the kernel, this is not helped by disabling JavaScript. So even turning JavaScript off will not help.

So the thing that I find annoying is that fonts are being rendered in the kernel. There's something fundamentally broken about that. And we know where this happened, and we know when. Because, I mean, the idea is the kernel is your holy, sacrosanct - it's the kernel. I mean, it's the OS. You want to keep application sorts of things out of it. It provides core services. It handles the abstraction of your I/O so that various apps can vie for the peripherals, and the kernel manages that. It typically abstracts the file system so that applications are able to talk to NTFS or FAT files in a uniform fashion. It handles memory management so that applications are able to request memory resources, which the kernel juggles. If it runs out of RAM, the kernel swaps things out that are not being used and brings new, empty memory in from swap space, I mean, all those really low-level things.

Well, at one point Microsoft, hopefully before they got the security religion, I mean, because you wouldn't ever want them to do this after they were concerned about security because it completely breaks security, Microsoft said, well, we need - we want faster display performance, so we're going to move GDI, the Graphics Device Interface, from user space, where it had always been, into the kernel, in order to minimize the user-to-kernel transitions because it's expensive to cross between user space and kernel space. So they said, well, let's move GDI, this complex rendering code which includes the whole font system, down into the kernel because won't that be a good idea. Yeah.

LEO: Oh, boy.

STEVE: And as a consequence, this is what you get. You get more complexity. You get little mistakes. But rather than it being a mistake in user space that just causes a much more limited problem, now it's a mistake down in, you know, God Central of the computer. I mean, this is where everything happens. And as we've seen, for example, with rootkits, I mean, the reason rootkits are such a problem is that they're down in the kernel, able to literally do things like hide files from the directory system so you can't see them, and AV systems can't see them.

So anyway, I wanted to encourage people, I wanted to further explain this particular vulnerability, which was fixed last week, and just make sure - and also explain or reinforce how trivial it will be for this to be exploited. Again, it's in the public domain now, what this problem is, how to exploit it, how it can be used. It will be anyone who touches a website, whose Windows system renders fonts on a website, that hasn't patched this can get their machines, at the kernel level, taken over.

Now, Microsoft, to their credit, has done some things in Vista and later, like Address Space Layout Randomization, ASLR, where the chunks of the kernel are located in sort of semi-random locations, making kernel-level exploits more tricky. But there's lots of instances where even Address Space Layout Randomization can be worked around. So if you haven't by any means yet rebooted your machine with last week's patches, delay only as little as possible because this is a bad guy.

LEO: That's really too bad.