3 ms·

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

by pilif 14y ago

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)

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

by pilif 14y ago

Dylan16807 14y ago

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.

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