4 ms·

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 th

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

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