It's 2020 and hackers are still hijacking Windows PCs by exploiting font parser security holes. No patch, either Hackers are commandeering victims' Windows PCs by exploiting at least one remote-code-execution flaw in the Adobe Type Manager Library included with the Microsoft operating system. No patches are available right now. Redmond today warned of two flaws, not yet assigned CVE numbers, present in the font parser – and at least one …
I realize I'm in the minority, not everyone will find my solution feaseable, but the fact that I'm totally blind & my screen reader reads *everything* in plain text means I should be able to force Windows never to display anything except in very specific fonts. I don't need all the fancy serif's & fiddly bits, just render in plain text so my reader can do it's damned job. Yet I have(?) to leave the font handling service running lest Windows has a hissy fit. Why? Just flush the font folder of everything except the fonts I know work, won't render my system FUBAR, and ignore every font "required" by whatever program I'm running at the time.
You allow it in the browser, why not for the entire OS as a whole? This wouldn't just help me & folks in a similar boat, it would benefit *everyone* whom felt like hardening their machine against such attack vectors.
Of course, that's the reason why MS can't allow it -- we might start getting uppity & demanding an OS that was fit for fekkin' purpose.
*Smashes head on the desk in frustration until I pass out*
The browsers love to download bad fonts because someone from the colored pencil office thinks it is cool. Then you have the extremes like Atlassian who have their own bad font and force it on everyone who uses their platform with no option to use better fonts. The person who made that decision needs to be hit with a copy of the METAFONTbook.
Yes. @font-face is perhaps the stupidest idea in CSS, and CSS is not short on stupid ideas.
I routinely disable font downloading in my browsers, and I've never had reason to miss it. (And it's not that I don't appreciate a good typeface; I studied typography in one of my degree programs.) But few users will know how, or why, to do that.
"Microsoft says it's C++'s fault."
Blame the COMPILER and LIBRARY author!!! No, wait...
So what fix will we do in "older windows"? My guess: don't view documents with MS office products... ESPECIALLY not documents with embedded fonts!!!
(I'll want to know what effect it has with Libre Office)
The electron, having been looked at, is no susceptible to further interrogation because someone went and observed the thing rather than locking it down and putting it in quarantine, and now there's a lot of uncertainty about were it is or how fast it's going.
Actually, in the most recent releases of Win10, font parsing apparently runs in usermode with the privileges of the invoking user.
But note this is not the first RCE in Windows font processing. It's not even the first one in the Adobe Type Manager library. All of that crap needs to be taken out behind the shed, and replaced with something running in a safer environment. Font rendering has some excuse for wanting native-code processing for performance; font parsing does not. Routinely parsing thousands of font descriptions a second would be a very specialized use case.
That means that the miscreant is sending me a mail with a document attached and expecting me to open it because COVID-19 or my bank or whatever.
I have a very fine bullshit detector and I can assure you that your mail will be filed in SPAM faster than you can blink and your document will not be opened or previewed in any way.
That settles that problem.
Now, I've checked my Win 7 installation and it has, in perfect Microsoft form, no less than 12 copies on disk. Two that are in Windows\System32 and \SysWOW64, and ten copies in \winsxs\ followed by a slew of characters that would take way too much time for me to type here and nobody cares about reading that anyway.
Then there are two more copies in \winsxs\Backup, in which the file names start by "amd64_microsoft_windows_gdi_" and another slew of characters etc etc.
Which ones can I get rid of, anybody know ?
But in real operating systems the e-mail client, browser or any other applications run with the permissions granted to the user that runs them. And if configured properly, users (other than admin, root, etc.) don't have permission to mess with kernel data and trusted binaries.
As I read the article, you don't _have_ to open it. All you need to do is fail to catch one of the many "features" that include Preview (E.G. Lookout or Windows Exploder). That _preview_ will invoke a series of unfortunate events.
Last time I had to use Windows at work, the Outlook preview pane seemed to be the main enabler for malware. And yet many (most?) in the office found it too convenient to lose. Apparently nothing has changed in a decade.
(Yes, other handy applications, and websites (gmail?), will obligingly load images etc. "just in case" you want them. It is the usual Whack-a-Mole to keep disabling it after "upgrades".)
That means that the miscreant is sending me a mail with a document attached
MIME called to let you know that many MUAs support embedding fonts for the main message text, no attached document necessary. Perhaps you have an MUA that's smart enough to ignore that bullshit, or at least let you configure it to be smart enough to ignore that bullshit.
In either case, it's more likely that said miscreant sends an email to someone you know, with some social engineering to get that person to forward it to various others. If I wanted to spread an email-borne virus around, I'd just send it to a mailing list, or kick off one of those agonizingly long everyone-forwards-the-entire-chain-thus-far email threads so popular at work.
Filtering by senders and subjects helps, but it's not perfect.
All supported versions of Windows are affected.
... exclusively supported by Microsoft ...
Well ...
So much for the ... guaranteed to be healthy and well looked-after for the next six months.
O.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
