Fonts eat a bullet in Microsoft security patch
theregister.co.uk
theregister.co.uk
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.
The Chromium bug report where the issue was discovered: http://code.google.com/p/chromium/issues/detail?id=146254
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.