3 ms·

First off, your understanding of WebGL security is wrong. Drivers are primarily blacklisted for stability reasons, not security. The security around WebGL imple

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.

Dylan16807 14y ago
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...
- justinschuh 14y ago
  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.
  - Dylan16807 14y ago
    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?
    - justinschuh 14y ago
      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).

Dylan16807 14y ago

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...

justinschuh 14y ago
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.
- Dylan16807 14y ago
  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?
  - justinschuh 14y ago
    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).