> I have thousands of fonts and have yet to see (or hear) of one that would trigger the security problems supposedly resolved by this update.
this is the complete backwards-thinking that causes people not to install security updates. Too bad it's repeated here in bold on a publication and subsequently even linked on HN.
Of course none of the fonts you have installed is using the security flaw.
But that newly created malicious font that is being used from that ad banner on that website you just visited is certainly going to use the security flaw to install additional malware on your system.
This has nothing to do with the existing fonts you deliberately installed but everything with newly created fonts that you don't deliberately install.
Another note: I really think MS should have fixed the vulnerability in their font parser instead of just disabling a whole class of fonts in a security update.
"Real problem now that affects by income" vs "unknown future risk."
You need to know the chance of a problem and the severity of that problem. My hunch is that in this case "Real problem now" is the worse option for a rational observer.
It's not just remote code execution; it's that this bug triggers in kernel font handling code. So, it bypasses application sandboxes and any other user space protections.
Yeah, the GDI is pretty horrible. But in Microsoft's defense, those decisions were made almost 20 years ago for NT4, when prevailing views on security and stability were very different from today. The post DX10 graphics pipeline doesn't do things like this, and is really quite sane and robust. Unfortunately, you need Vista+ for DX10, and even then you still get saddled with the local GDI attack surface.
Possible vulnerability is a reason to disable font loading from untrusted network locations. It is not an excuse to break font loading in local content-creation programs.
How would windows know whether that blob it just has been told to load as a font comes from an external machine or not?
Disabling all font loading is, besides fixing the parser, the only sensible thing to do from a security standpoint. It is not however at all sensible from a user perspective. They really should have fixed their font parser (and moved it out of the kernel as a secondary goal)
Patch IE, tell mozilla and google about the problem too. Activity that is local to a machine should never be impaired by security patches aimed at the network.
Yeah. This scales really well. Especially because there are no other browsers but from Mozilla and Google (Opera? Smaller ones?)
Also, you'd have to tell all makers of email clients and every other network connected application to mark external data as such - how likely do you think this is going to be?
I'm just saying to treat it like webgl: a recent feature exposing un-hardened code to network assault that only allows recent/whitelisted drivers. It scales pretty well and puts the burden of network safety where it should be, on the application pulling in network data. If you blocked all potentially-weak code just because someone might feed in network data you'd end up with a brick.
First off, your understanding of WebGL security is wrong. Drivers are primarily blacklisted for stability reasons, not security. The security around WebGL implementations is in restricting what's exposed to a safe subset of GL, and transforming the supplied GL commands to ensure validity and prevent the site from directly supplying raw GL to drivers or the user-space stack.
As for the font issue, it simply doesn't work the way you think. You can't just patch IE because the bug would still allow arbitrary execution of kernel code (privilege escalation) from any application, including from inside IE's sandbox. And you can't drop AddFontMemResourceEx from the OS or alter the behavior of font file loading without rewriting pretty much every application that handles fonts.
So, what MS did here is entirely correct. They fixed the handling code so that it doesn't accept these malformed fonts anymore. It's a shame that some content creations tools generated the broken fonts at all, but they were never legal according to the spec and shouldn't have been rendered in the firsts place.
Sometimes you can't fix security in a minor revision. Can you imagine if proper admin rights policies were added in an update to XP? Everything would break and people would be very rightfully mad at Microsoft.
And transforming the supplied fonts for validity is in fact the correct answer, once microsoft gets around to it...
I'm sorry, but you're simply wrong. First off, XP has full support for admin rights, as has every version of Windows NT. But your confusion here really isn't the point, since the analogy itself is wrong, even if your understanding of Windows security was correct.
The vulnerability we're talking about wasn't some design or security policy issue. It's simply a font handling error that presented as a remote kernel compromise in any application handling external fonts via GDI. I know this because I triaged the bug when it was originally reported against Chrome. And I also know that Microsoft's response was entirely correct, which is to refuse the malformed fonts entirely rather than risk further security issues due to handling known corrupted state.
Personally, I think Microsoft should be lauded for shipping a fix within 60 days of us reporting the bug to them. That's an unusually fast turnaround on a critical security issue affecting their entire user base, and a clear acknowledgement of just how dangerous this issue was.
XP has the ability to do things correctly, but by default not the configuration. If Microsoft made a list of software that runs insecurely as admin and blocked them all, it would certainly fix many methods of kernel-escalation but it would also kill hundreds millions of installs.
The problem here is far more in how the fonts are sourced than the bad behavior that results. If someone installs insecure software on purpose, it's Windows' job to be as secure as possible while also not interfering in the software's execution. That's the backwards-compatibility that helps them keep market share.
As far as Chrome's involvement, is the font-loading API specified to accept invalid fonts? If not, no matter if this bug is fixed, Chrome needs to validate fonts anyway; what if the kernel decided to immediately kill any thread feeding in a corrupt font?
Forgive my bluntness, but you appear to be far outside your depth here. Rather than fisk your comment, I'm going to try and explain the positions as I see them.
Microsoft had at least one font handling bug that exposed an arbitrary kernel privilege escalation. They closed this bug by rejecting the narrow class of malformed fonts that triggered the issue (impacting a very small number fonts people actually use). From the software engineering, security, and product perspectives it was exactly the correct solution to this particular bug, because it fixed the issue and preserved compatibility in the vast majority of cases (i.e. for valid fonts).
Now, you appear to be suggesting that instead Microsoft should have somehow altered all existing software that uses GDI font rendering to address the issue. Either that, or you're suggesting that Microsoft should break all APIs that load fonts from memory (or really any path outside of a protected system directory). So, you're either advocating the herculean task of modifying all first and third party software, while still leaving a kernel vulnerability exposed to local applications. Or, you're proposing a massive API change that would break the vast majority of applications using GDI font rendering. Either of these approaches strikes me as a very, very bad idea, and not worth seriously discussing.
Of course, the thing that makes this issue so bad is that Microsoft handles fonts in the kernel. This is a legacy issue that's obviously hurting them on the stability and security front. They're trying to move people to DirectWrite, which is far saner and safer, but it's not supported on XP. And DirectWrite won't address the local escalation issue, because there's 20+ years of software using GDI font APIs that will need to be supported for the foreseeable future. While Microsoft could certainly move GDI fonts out of the kernel, I don't see them doing so. It's a tremendous amount of work and probably not justifiable from a business perspective given that DirectWrite and GPU acceleration are really are the direction everything is headed anyway.
As for your questions about Chrome, we filter fonts using our OpenType Sanitizer (OTS), and Firefox has been using uses our code since 2011. However, fonts are very complicated, and often not entirely verifiable, because their hinting languages include a turing complete VM bytecode with variable length instructions. So, there are infinite classes of malicious behavior that you can't detect without solving the halting problem. Also, any level of user-space filtering applies to only the first stage of an exploit. Once malicious code is executing in the renderer process, it can use a font vulnerability to break out of the sandbox by executing code at kernel privilege (and the same applies to IE or any other user-space sandbox).
"eat a bullet?" What does that even mean? Come on, is it asking too much for even a semi-professional article here? The reg is a tabloid that's bascially blogspam. HN can do better.
"Eat a bullet" is slang which means being shot. As in, the update kills certain fonts. It's also a pun, because fonts contain a character known as a bullet: "•".
Yes, the Reg is an IT tabloid; they do an entertaining, sarcastic, and pun-filled take on IT news. I wouldn't call it blogspam in general; they do real reporting, and provide more than the usual blogspam "link, quote, and one sentence summary." In this particular case, the source they quoted probably would have been a better article to post, as it is longer and contains more information.
22 comments
[ 3.3 ms ] story [ 62.8 ms ] threadThe Chromium bug report where the issue was discovered: http://code.google.com/p/chromium/issues/detail?id=146254
this is the complete backwards-thinking that causes people not to install security updates. Too bad it's repeated here in bold on a publication and subsequently even linked on HN.
Of course none of the fonts you have installed is using the security flaw.
But that newly created malicious font that is being used from that ad banner on that website you just visited is certainly going to use the security flaw to install additional malware on your system.
This has nothing to do with the existing fonts you deliberately installed but everything with newly created fonts that you don't deliberately install.
Another note: I really think MS should have fixed the vulnerability in their font parser instead of just disabling a whole class of fonts in a security update.
"Real problem now that affects by income" vs "unknown future risk."
You need to know the chance of a problem and the severity of that problem. My hunch is that in this case "Real problem now" is the worse option for a rational observer.
That does rather change the balance somewhat.
Of all the things to put into kernel space ....
It's Windows man, this is an old story now.
Disabling all font loading is, besides fixing the parser, the only sensible thing to do from a security standpoint. It is not however at all sensible from a user perspective. They really should have fixed their font parser (and moved it out of the kernel as a secondary goal)
Also, you'd have to tell all makers of email clients and every other network connected application to mark external data as such - how likely do you think this is going to be?
As for the font issue, it simply doesn't work the way you think. You can't just patch IE because the bug would still allow arbitrary execution of kernel code (privilege escalation) from any application, including from inside IE's sandbox. And you can't drop AddFontMemResourceEx from the OS or alter the behavior of font file loading without rewriting pretty much every application that handles fonts.
So, what MS did here is entirely correct. They fixed the handling code so that it doesn't accept these malformed fonts anymore. It's a shame that some content creations tools generated the broken fonts at all, but they were never legal according to the spec and shouldn't have been rendered in the firsts place.
And transforming the supplied fonts for validity is in fact the correct answer, once microsoft gets around to it...
The vulnerability we're talking about wasn't some design or security policy issue. It's simply a font handling error that presented as a remote kernel compromise in any application handling external fonts via GDI. I know this because I triaged the bug when it was originally reported against Chrome. And I also know that Microsoft's response was entirely correct, which is to refuse the malformed fonts entirely rather than risk further security issues due to handling known corrupted state.
Personally, I think Microsoft should be lauded for shipping a fix within 60 days of us reporting the bug to them. That's an unusually fast turnaround on a critical security issue affecting their entire user base, and a clear acknowledgement of just how dangerous this issue was.
The problem here is far more in how the fonts are sourced than the bad behavior that results. If someone installs insecure software on purpose, it's Windows' job to be as secure as possible while also not interfering in the software's execution. That's the backwards-compatibility that helps them keep market share.
As far as Chrome's involvement, is the font-loading API specified to accept invalid fonts? If not, no matter if this bug is fixed, Chrome needs to validate fonts anyway; what if the kernel decided to immediately kill any thread feeding in a corrupt font?
Microsoft had at least one font handling bug that exposed an arbitrary kernel privilege escalation. They closed this bug by rejecting the narrow class of malformed fonts that triggered the issue (impacting a very small number fonts people actually use). From the software engineering, security, and product perspectives it was exactly the correct solution to this particular bug, because it fixed the issue and preserved compatibility in the vast majority of cases (i.e. for valid fonts).
Now, you appear to be suggesting that instead Microsoft should have somehow altered all existing software that uses GDI font rendering to address the issue. Either that, or you're suggesting that Microsoft should break all APIs that load fonts from memory (or really any path outside of a protected system directory). So, you're either advocating the herculean task of modifying all first and third party software, while still leaving a kernel vulnerability exposed to local applications. Or, you're proposing a massive API change that would break the vast majority of applications using GDI font rendering. Either of these approaches strikes me as a very, very bad idea, and not worth seriously discussing.
Of course, the thing that makes this issue so bad is that Microsoft handles fonts in the kernel. This is a legacy issue that's obviously hurting them on the stability and security front. They're trying to move people to DirectWrite, which is far saner and safer, but it's not supported on XP. And DirectWrite won't address the local escalation issue, because there's 20+ years of software using GDI font APIs that will need to be supported for the foreseeable future. While Microsoft could certainly move GDI fonts out of the kernel, I don't see them doing so. It's a tremendous amount of work and probably not justifiable from a business perspective given that DirectWrite and GPU acceleration are really are the direction everything is headed anyway.
As for your questions about Chrome, we filter fonts using our OpenType Sanitizer (OTS), and Firefox has been using uses our code since 2011. However, fonts are very complicated, and often not entirely verifiable, because their hinting languages include a turing complete VM bytecode with variable length instructions. So, there are infinite classes of malicious behavior that you can't detect without solving the halting problem. Also, any level of user-space filtering applies to only the first stage of an exploit. Once malicious code is executing in the renderer process, it can use a font vulnerability to break out of the sandbox by executing code at kernel privilege (and the same applies to IE or any other user-space sandbox).
In all likelihood, nobody understands how it works, and they're just afraid of touching the code and introducing a new vulnerability.
Yes, the Reg is an IT tabloid; they do an entertaining, sarcastic, and pun-filled take on IT news. I wouldn't call it blogspam in general; they do real reporting, and provide more than the usual blogspam "link, quote, and one sentence summary." In this particular case, the source they quoted probably would have been a better article to post, as it is longer and contains more information.