Windows code-execution zeroday is under active exploit, Microsoft warns
arstechnica.com
arstechnica.com
* Attackers can exploit the vulnerability by embedding the Type 1 fonts into documents and convincing users to open them
* The vulnerabilities lies in the Windows Adobe Type Manager Library ATMFD.DLL
* disabling the Windows WebClient service blocks what Microsoft says is the most likely remote attack vector, through the Web Distributed Authoring and Versioning (WebDAV) client service.
* local, authenticated users can run malicous programs that can exploit the vulnerability (I presume this is a privilege escalation).
More info on the history of ATMFD (and some previous vulnerabilities): https://googleprojectzero.blogspot.com/2015/07/one-font-vuln...
(If you're reading lots of LaTeX-generated papers, then yes, you're probably seeing PostScript fonts.)
This makes exploits like this possible: https://sensepost.com/blog/2017/abusing-gdi-objects-for-ring...
I don’t know of any specific blogs/resources. I used to work on Excel’s render code so had a bit of an inside view.
The Vista experience shows you it was and still is necessary for perf.
Moving things into the kernel is one heck of a sledgehammer solution to DLL Hell, at least.
(Windows 10 has slowly moved a lot of the graphics stack back out of kernel space. It appears to be moving the right direction, just very slowly.)
There is:
https://portal.msrc.microsoft.com/en-US/security-guidance/ad...
Microsoft documents, as a possibility, how to "Rename ATMFD.DLL" and describes the impact.
> Rename ATMFD.DLL, or alternatively, disable the file from the registry
Caveat:
> Renaming ATMFD.DLL, the last recommended stopgap, will cause display problems for applications that rely on embedded fonts and could cause some apps to stop working if they use OpenType fonts.
Also from TFA:
> Monday’s advisory provides detailed instructions for both turning on and turning off all three workarounds.
Back when "put everything in the kernel to make it fast" was the forefront of computing technology. Microsoft obviously still has work to do but they did take a large chunk of sound and graphics code out of kernel space in Vista.
Linux can't really do either of those things nicely because graphics is just another program. Although I'm sure you can isolate your don't decoding better than shoving it in the kernel.
Am I missing something?
Probably I'm wrong in that supposition there, but then what happens?
Linux kernel/bpf is getting nervous.
joking aside (and sorry for going off on this tangent) under Linux it seems the kernel is eating more of user-space every year. That argument could of course be also turned around by claiming that user-space is eating the kernel. which ever way you look at - systems programming has gotten much more challenging (interesting) in the past years.
bpf is a sandbox, and unprivileged processes do not magically gain access to it; anything malicious that could be done with bpf could as easily be done with the coincident root privileges.
What is your example of where the Linux kernel is "eating more of user space every year"?
X.509 parsers... or three or so...
Heck, the entire io_uring system is a prime example of the Linux kernel “eating more of user space” - it’s essentially a programmable syscall pipeline that executes entirely in kernel mode. All to reduce some user/kernel transitions - exactly why ATMFD and http.sys were invented in the Windows kernel.
Except everything ATMFD does is basically obsolete if you have memory mapped files. FreeType works fine, nobody ever tried to put it in the kernel (at least upstream, in a form accessible to userspace).
No they can't. Calling bpf(2) requires you to be running as root or have CAP_SYS_ADMIN.
I am sure the engineers at Microsoft were shipping and not thinking about exploits. Or at least the exploits were the lesser of their worries.
I don't call having to tweak my kernel config to be very convenient, or the graphics driver crashing my system, or not having an obvious way to reboot the network/audio/FS stacks without doing a full reboot (I am sure it may be possible).
However, I am hardly the target market for gnu/linux.
to clarify I love ebpf traffic processing as opposed to having an iptables nfqueue[1] based approach (or worse a fully privileged kernel module).
my point was that userspace now looks different than before because I have to gain a pretty deep understanding of LLVM in order to do meaningful work to achieve the same goal (and be rewarded by a ~50% speed up).
Is ebpf user-space? Is it kerne-space? Is it something inbetween? I've written C for over 2 decades and have used assembler to optimize for embedded architecture where it made sense. far from an expert in assembler - maybe I'm not a good systems programmer because I should know more about this topic?
[1] I wrote this in January: https://github.com/DyslexicAtheist/nfq/ fully aware it could be done in ebpf but chose NFQ nevertheless - because my LLVM foo is simply not good enough. I feel either I'm dumb or the learning-curve is so big that it will take me a year or more to get the same done in ebpf. So ebpf has in some way hi-jacked my existing user-land skills :) not complaining - just saying my skill set has been obsoleted in a matter of few months - again not complaining - I will just have to dig deeper into LLVM and know more about the hardware than I did before :)
____
really don't understand where the downvotes are coming from since I haven't criticized the current approach. it seems HN is a bad place to make a joke.
https://portal.msrc.microsoft.com/en-us/security-guidance/ad... :
Windows 10 1709+ All fonts are processed in fontdrvhost.exe in user mode appcontainer. ATMFD.DLL status: Not present
Usually, font renderers are Turing complete in some way, and usually this opens up security concerns, and rightfully so...
One of the primary reasons why fonts are rendered programmatically is because there's a theoretically infinite set of sizes/styles that might be required...
Well... why not make fonts with glyphs that are say, 5000 x 5000 pixels... and then instead of rendering for a particular size, line by line, stroke by stroke, curve by curve, why not instead use an interpolation algorithm to shrink that 5000 x 5000 pixel glyph to the exact size you want?
If a font provider program were made to operate that way, then all that would be needed to audit the program for security - would be to audit the shrinking/interpolation algorithm -- which could be as simple as possible (it's just a function which shrinks a bitmap of size A to another bitmap of size B... not a Turing machine which ingests other programs...)
Yes, fonts would consume much more memory (I suppose they could be compressed), but doing things that way might make font-providing programs more secure. And yes, you'd need to provide extra glyphs for italic, bold, bold italic, etc. (much more memory), but you'd be making a trade-off for a simple, security auditable font-provider... (we assume it's open-source...)
Most of the features of which I am aware in fonts are modeled as FSMs, which can certainly be turing complete but do not need to be. Off the top of my head you could figure out a “sane” max time for a “script” to run without any loss of font quality, though it would not technically comply with the intended functionality.
I am at a loss of words for why this was ever possible, although perhaps security didn’t matter until this past decade and I am too young to remember how low priority it used to be.... certainly, putting anything in kernel space for performance reasons of all things seems ridiculous for desktop computing. I’ll take a fucking massive performance hit to keep my data safer.
I am fairly confident AAT tables are FSMs, so I am curious where the turing completeness comes from. I am certainly not familiar with all truetype/opentype features.
but one example there would be support for ligatures, which could be a lot more complex depending of the language you want to support.
And depending on the rendering speed you want, you might want to perform some JIT compilation, which unfortunately might not cover all edge cases.
All I know is, the fonts (in ROM) in the original IBM-PC, or the Apple ][, or the C-64, or the Atari 800, or any other of the 64K computers of the 1980's -- never had a security issue with their (ROM bitmap) fonts.
That, and:
I challenge all of the naysayers to come up with a better solution than the one I have proposed...
Not all font-renderer/language experts, here, are we?
Neither am I.
That's the whole point.
A graphical shrink routine I can easily audit for security holes.
A font description language (an entire language mind you!) with lots of nuances -- how is any normal human being (much less rockstar programmer) supposed to audit one of those, with all of its possibilities, for security holes, in a single human lifetime?
We've seen some very subtle manipulation of these (evinced by this article), whether intentional or not...
A simple graphical shrink routine -- is orders of magnitudes more transparent and auditable than font description languages, or their interpreters...
You want a better solution?
Come up with one and tell me what it is!
I'm listening...
Now the security for the font server becomes the problem of the server its running on, not your local PC... and while the font server runs the risk of compromise, you, by only using pre-rendered bitmaps, should ideally not...
Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts?
This sounds like:
- a latency nightmare - a performance nightmare - a privacy nightmare
> Of course, the drawback to this approach is, what if you want to work offline and have not downloaded the necessary fonts?
I'm calling Poe's Law on you, friend
A privacy nightmare? I don't see how (unless you had to register on the font-serving machine and it tracked fonts downloaded -- but is that really privacy invading?)
Yes, there would be trade-offs (didn't I say that a couple of times?), but such is the price potentially paid for font renderer security...
That is -- get rid of the font renderer software component...
Hey, one other idea, while I'm at it... run the font renderer in a virtual machine... that could possibly work too... although given that virtual machines have the same issues with complexity and security bugs, I'm sort of 50/50 about that...
Another idea: You could have a completely sandboxed language VM -- (e.g., JVM), and if that language VM is provably secure -- run the font renderer code on it...
But again, we've seen JVM security bugs so...
I'm going to have to go with either "shrink a big bitmap" or "put the font renderer on an entirely different server and serve exact-sized bitmaps" ideas...
Or... use a 64K computer from the 1980's where the glyphs are in ROM... <g>
Very expensive idea though.
Seriously? Do you know of ANY security issue with Arial? The problems come with external fonts, not those built into the system - regardless of their representation.
> I'm listening...
You do realize that you're proposing "let's strip (useful) functionality". Remove all external media other than punched cards, and you stopped the spread of malware - computer viruses were never a problem back then. But a cure that's worse than the disease is not a solution.
> Not all font-renderer/language experts, here, are we? Neither am I.
That's the point. A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.)
Arial can be described via a font description language.
While I may not know of any security problems with some (a tiny subset of a theoretically infinite set) of those font description language definitions of Arial (aka, mini-programs that tell the font renderer how to render Arial), I know that I do not have the ability to security audit the font rendering program that produces that Arial font.
I would not have this ability unless I programmed my own font renderer, and even so I might miss things like potential buffer overflows, stack overflows, anomalous behavior, and the like.
In short, I could not test for every possibility that a would-be hacker could potentially dream up.
It would be similarly difficult for someone else, even a very good programmer, to properly audit for security the code I had written (or anyone else had written for that matter), even if I/they had written it to the best of my ability for it to be secure.
>You do realize that you're proposing "let's strip (useful) functionality".
Not necessarily...
Remember that a font, after all of the font code is processed, must come out of the font renderer as a bitmap.
If that bitmap could be produced in some other non-programmatic way, that is, some way without the use of the font renderer, then all security issues having to do with the font renderer would be rendered (pardon my pun!) -- obsolete.
In other words, no font renderer, no font renderer security issues.
>Remove all external media other than punched cards, and >you stopped the spread of malware - computer viruses were >never a problem back then. But a cure that's worse than >the disease is not a solution.
You have to make your own choices. Am I advocating this for everyone? Not at all. You have freedom; you (and everyone else) make your own choices based on that freedom.
But for me, if in the future I'm running a server that is mission critical, that has to stay up 24/7, and has to be resistant against hacker (and other party!) attacks, then you can sure as hell bet I'm not going to be running a font renderer on it!
Hey, as I said... it's your choice! You can run font renderers, and any number of things you randomly download from the Internet ("Bonzi Buddy" comes to mind) on servers that are mission critical, but would I?
I would not... but that's just for me and my future servers... you may have different concerns, and your mileage "may vary" as the old expression goes...
>> Not all font-renderer/language experts, here, are we? >> Neither am I. That's the point.
> A little humility would suggest that there are font renderer & language experts out there, and that obvious solutions like yours would have crossed their minds. Don't "challenge naysayers to come with a better solution" - know that better solutions exists (e.g. fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal; and pretty much zero security risk. So better solution do exist. It's just that they wouldn't be good enough.)
I meant no disrespect (to you, or any of the font renderer and language experts out there), but you know, sometimes a person may need to challenge groups of experts -- to get them to think even harder.
I am sorry, but that is true...
If I have offended you or anyone else, then you have my most humble apologies -- but my challenge is not rescinded, because until and unless the security community can prove (I mean prove rigorously, like a mathematical proof) that font renderers are secure, and that problems like the one this HN article is about can and will never happen in the future, until that point in time, my challenge is not rescinded because it is necessary.
Humility or not...
Also, I'll concede that I like your point:
>fonts could be represented as vector drawings/ fixed set of curves, with much less loss of functionality than your proposal;
This is a good start! I agree, this might be the way to go... (this is why I issued my challenge, for points like these...)
But they already are! That's the point that you are missing, for basic stuff, you can use a font that is described with only basic features/ that can have no possible security issues.
> Remember that a font, after all of the font code is processed, must come out of the font renderer as a bitmap.
But go into complex arabic fonts and you start to realize that your .svg (or worse, bitmap) can't be a representation of a "character" but that of a "paragraph". Pre-render that, as a font!
> You can run font renderers, and any number of things you randomly download from the Internet ("Bonzi Buddy" comes to mind) on servers that are mission critical, but would I?
That's very, very different. You don't run arbitrary binaries on mission critical servers - nobody does, right? But that doesn't mean that "we should remove the capability of OSes to run arbitrary binaries".
Yes, custom fonts are slightly more safe "client code". All precautions that need to be taken when running client code, need to be taken when rendering custom fonts. Which means that first and foremost, you need to ask yourself "do I need to run custom client code in this mission critical server?". Sometimes you do - but often you don't; and when you don't, by all means, disallow it - it's the safest option.
You have thrown away all the parts that are hard, and suggest only implementing the part that is easy, in a bad way.
That is not a viable replacement. Those hard parts are necessary. You can't just ignore them.
You are willing to trade security for functionality.
My argument is based in security.
I am willing to trade functionality for security.
You are correct, what I have suggested is not a viable replacement, if functionality is desired.
But I am also correct, what I have suggested is a viable replacement, if security is desired.
Also, I would suggest that the challenge is on YOU - to live with all of the future security and privacy ramifications of the position you take, because by choosing functionality over security, you equal-and-oppositely UNCHOOSE security...
You cannot have both, and if you believe you can, if you want to persuade me, then the burden of proof is upon you to rigorously and mathematically prove it.
Until then, I remain unconvinced...
People aren't going to stop wanting to use computers in their own language just because you are upset about font rendering. It is just not happening, and there is no point in discussing it.
Addendum: It obviously depends on the display font size, or more easily, how many screen pixels are used for rendering. The dpi is only an indirect factor. For normal screens on laptops and desktops (< 1m distance) typical font size means low pixel density. For example, the character '9' as rendered in my comment on the HN website has 6 horizontal and 9 vertical visible (coloured) pixels. Which means that Antialiasing (grayscale) is absolutely needed. Which again means that the borders are somewhat washed out, causing eye-strain.
The situation can be somewhat improved using subpixel rendering, improving the horizontal resolution by a factor of 3, optimistically speaking. Though subpixel rendering relies on the structure of display pixels, and that the monitor is not rotated, and it's hard to get right and some people will always complain about colour fringes.
Then, if you want to support a variety of languages, you need to handle diacritics, ligatures, contextual shaping, and bidirectional text [4]. A character's appearance can very based on what comes before and after it. Or the base character can change appearance depending on the diacritics that are added to it. Some languages have complex rules about how you combine things, for example Thai [5].
If you want to support Emoji (and of course you do), then there's things like skin tone modifiers [6] and the zero-width joiner [7] that lets you make all kinds of crazy combinations.
Modern text rendering is, for better or worse, very complex.
[1] https://en.wikipedia.org/wiki/Kerning
[2] https://en.wikipedia.org/wiki/Font_hinting
[3] https://en.wikipedia.org/wiki/Subpixel_rendering
[4] http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&ite...
[5] https://www.unicode.org/L2/L2018/18216-thai-order.pdf
[6] http://www.unicode.org/reports/tr51/tr51-16.html#Emoji_Modif...
[7] http://www.unicode.org/reports/tr51/tr51-16.html#Emoji_ZWJ_S...
TrueType doesn't need a virtual machine to parse the vectors either, only to hint. Your proposal doesn't provide any hinting capability, so it doesn't solve the problems the VMs were created to solve. Moveto/lineto/curveto commands like TrueType uses are trivial and are not causing the issues here.
Fonts are going to be complex no matter what, largely because of international text and advanced typographic features. The real solution is to move to memory-safe implementations.
1 - article has wrong info. Under Windows 10 the name is ATMLIB.DLL. ATMFD.DLL is the name for older version of Windows
2 - rename it. Here is the script to be used under an elevated command prompt (change name accordingly if Win10):
cd "%windir%\system32"
takeown.exe /f atmfd.dll
icacls.exe atmfd.dll /save atmfd.dll.acl
icacls.exe atmfd.dll /grant Administrators:(F)
rename atmfd.dll x-atmfd.dll
cd "%windir%\syswow64"
takeown.exe /f atmfd.dll
icacls.exe atmfd.dll /save atmfd.dll.acl
icacls.exe atmfd.dll /grant Administrators:(F)
rename atmfd.dll x-atmfd.dll
wmic path win32_group where (LocalAccount=true AND SID="S-1-5-32-544") get Name
edit: that's just the name of the local Administrators group, here's how to get the Admin-accountname:
wmic useraccount where (domain='localhostname' and sid like 'S-1-5-21-%%-500') get sid /value
wmic useraccount where (domain='localhostname' and sid='sidfromfirstcommandhere') get name /value
That will just return the name of the built-in Administrators account. If you wanted to find all user accounts in the administrators group you could do:
powershell -c "$([ADSI]'WinNT://YOUR_MACHINE_NAME/Administrators,group').psbase.Invoke('Members') | foreach { $_.GetType().InvokeMember('ADspath', 'GetProperty', $null, $_, $null)}"
I don't think they have the wrong info. According to the MS advisory they linked (https://portal.msrc.microsoft.com/en-us/security-guidance/ad...) it would appear that ATMLIB.dll is not actually affected as there is no mention of it at all, only ATMFD.dll. Also implied by the advisroy is that ATMFD.dll is present on Windows 10 but only versions prior to 1709:
> Rename ATMFD.DLL
> Please note: ATMFD.DLL is not present in Windows 10 installalations starting with Windows 10, version 1709. Newer versions do not have this DLL.
In Windows 10, they changed it so the ATMFD code runs sandboxed in fontdrvhost.exe, and eventually removed it completely from the kernel, that's why atmfd.dll is not there on later editions.
Which is still not good but not as bad as it could be.
Also, the way this is written is sounds like system isolates this DLL into its own AppContainer separate from specific apps that use/rely on it (and I guess remote to it)?
- The AppContainers thing sounds like it directly refers to the Panes in Explorer referenced, and it sounds like it is Explorer creating the sandboxes, so they wouldn't bubble out of the Pane, so it probably is correct that versions of Windows 10 doing that don't have a lot to worry about that as an exploit vector. That probably doesn't apply to other possible vectors such as evil PDFs/Word Documents, though those generally have warnings for PostScript fonts at this point. (I glossed over the Panes as the concern for the idea it might be running in the Explorer process. Their an "extension point", so Explorer moving them into sandboxes sound like exactly what it should have done, and not surprising is what it is doing.)
- DirectWrite is considered to have parts forked, but entirely independent, from ATMFD. Some CVEs have been caught that also impacted (lightly) DirectWrite, but this doesn't sound like one.
It's a sandboxing method, and atmfd was moved into a sandbox to reduce the risk of people exploiting bugs in it. At this point it is clear that sandboxing it was worth the effort.
Before then, this ATMFD code was only in the kernel, making it a useful vector for privilege escalation.
https://bugs.chromium.org/p/project-zero/issues/detail?id=13... (description of an old ATMFD bug) explains it:
"Windows 10 has a sandboxed user-mode font driver (fontdrvhost.exe) that doesn't have access to any sensitive information and will cleanly restart upon crashing."
https://census-labs.com/media/windows_10_rs2_rs3_exploitatio... has some more detail on how this process is further hardened with syscall filtering, if I recall correctly this was introduced in Windows 10 1709:
"Privilege escalation exploits are on the rise, because of sandboxes. The Win32k component, a provider of system calls, has introduced win32kfilter, a filtering mechanism that cuts down the number of system calls available to sandboxed processes (thus reducing the kernel's attack surface). FontDrvHost.exe, which is the font parser, uses the 3rd level of win32kfilter."
Not great, not terrible.
...sorry
... why doesn't WebClient also prompt users before opening programs via things from the internet then?
It basically makes anything that calls an internet service in authenticated apps, like Windows Explorer's image preview pane, a vector for loading arbitrary programs without warning.
Am I missing something here? Some way this would be really annoying or pointless?
I know Android never bit the bullet with making any internet access require a privacy confirmation, which I'm guessing might be overwhelming to the average user. But I still think it should be an option, like an opt-in Little Snitch for network access that includes embedded webkits.
Rename ATMFD.DLL
Right-click C:\Windows\System32\atmfd.dll
Properties | Security | Advanced | Owner, take ownership.
Close dialogs, go back in and give yourself Full Control.
You can always "undo" that change, if so.
I renamed it, then used Outlook 2016 successfully for days (mostly Outlook, Word and some Excel). After a reboot, I did get an error code 0x426-0x0 trying to start office apps, but I'm pretty sure that was just due to disabling the Click-To-Run service a long time ago and (possibly) having gotten new updates pushed to me during the reboot.
I did an SFC /SCANNOW which restored the original atmfd.dll, and I immediately deleted it.
If you bump into any OpenType fonts it might be a different story.
To be clear and despite its name, this is not Adobe code. Microsoft was given the source code for ATM Light for inclusion in Windows 2000/XP. After that, Microsoft took 100% responsibility for maintaining the code.
Microsoft has added additional code and removed code from that DLL (they shove all their Type 1 handling and Open Type font format handling into that one DLL)
Then re-enable it when the fix is in.
Doesn't seem to be. The file (ATMFD.DLL) doesn't exist in a fresh install of Windows 10 1909 enterprise.
https://portal.msrc.microsoft.com/en-us/security-guidance/ad...
They really do need to start over from scratch, get rid of all the cruft, design the APIs not to suck, design in security, permissions, and sandboxing from the beginning. Make root kits and other spyware much harder. Get rid of installation scripts (more like iOS/Android/Some Mac app) and a million other things.
I don't hate windows but I hate that every app I install including every game on steam or the oculus store or humble bundle can basically own my machine.
Security model is still better than what POSIX provides. As for sandboxing: "For systems running supported versions of Windows 10 a successful attack could only result in code execution within an AppContainer sandbox context with limited privileges and capabilities." From https://portal.msrc.microsoft.com/en-us/security-guidance/ad...
What they can add is sandboxed apps with a virtual filesystem and whatnot.
But they do not want to spend the manpower to do so, it seems.
I am not seeing that in c:\windows\system32\ATMFD.DLL in multiple different windows10 machines I've checked.
Search for that one instead and rename it.
https://www.microsoft.com/en-us/msrc/technical-security-noti...
(Win10 1703+ is already not using this DLL, that came out years ago.)
If you put that off for long enough, it will restart the next time you close the lid.
I cannot imagine anyone going through all that and then going "wow I wasn't expecting an update!"
On top of that, it generally takes 5-10 minutes tops to actually do the update, more usually it's a standard restart that takes like 30s.
the only "45 minute" update I've had was one of the big service pack updates and that was opt-in with an up front warning.
If it's zero day on Windows it is pretty much a guarantee that adobe or Oracle was involved
Imagine my surprise. Geez maybe it’s not the best idea to allow Adobe to entirely run the font game?
Source: worked at Adobe years ago
It's also one of the reasons to reduce use of proprietary software to a minimum. Especially, if it's a core component of the system. Flatline, it's an increased security risk you can't verify.
On a serious note: Are there legit reasons to have it being a core component?
Without question one of the worst companies to be put in charge of anything important anywhere.
That’s all I’ll say about Adobe. Dark times, glad I moved on.