Re:Fonts eat a bullet in Microsoft security patch
by andybak on Monday December 17, 2012 @08:58AM
(#4932239)
Ah. I have just noticed that the bug allows remote code execution from just visiting a malicious website.
That does rather change the balance somewhat.
Re:Fonts eat a bullet in Microsoft security patch
by justinschuh on Monday December 17, 2012 @10:03AM
(#4932500)
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.
Re:Fonts eat a bullet in Microsoft security patch
by DannyBee on Monday December 17, 2012 @10:25AM
(#4932590)
I think the best part of this is the phrase "kernel font handling code"
Of all the things to put into kernel space ....
Re:Fonts eat a bullet in Microsoft security patch
by codewright on Monday December 17, 2012 @01:24PM
(#4933526)
>Of all the things to put into kernel space ....
It's Windows man, this is an old story now.
Re:Fonts eat a bullet in Microsoft security patch
by justinschuh on Tuesday December 18, 2012 @09:43AM
(#4937658)
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.
"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.