* 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).
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.
> Back when "put everything in the kernel to make it fast" was the forefront of computing technology.
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.
I guess I don't see it that way. Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
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"?
> I guess I don't see it that way. Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
Unprivileged processes can load bpf filters though - they can attach filters to sockets or load seccomp syscall filters, to name two examples. Just because it is a sandbox doesn’t mean that loading and executing user-supplied code in kernel mode is free from risk! I’m sure the Microsoft engineers thought their code was bulletproof too right until the exploits started showing up.
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.
> exactly why ATMFD ... [was] 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).
But bpf(2) isn't the only entry point for bpf filters in the kernel. Unprivileged user programs have access to the SOL_SOCKET SO_ATTACH_FILTER sockopt, as well as the PR_SET_SECCOMP SECCOMP_MODE_FILTER prctl. Now, these take cBPF programs, not eBPF - so they don't have all the fancy programming features that bpf(2) has - but they're still "code running in the kernel".
> What is your example of where the Linux kernel is "eating more of user space every year"?
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.
> Probably the hairiest things in the kernel that maybe shouldn't be there are boot-time network filesystems, but I think that's kinda the price you pay for that sort of convenience.
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.
And to be fair, putting graphics stuff in the kernel allows Windows to do some graphical things properly, like a secure attention key (ctrl-alt-delete to log in) and a proper task manager.
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.
The secure attention key is handled or if you will caught in the keyboard driver, and then sent to Winlogon, a user space program. How does that relate to graphics being in the Windows kernel?
Well kernel development is not my area of expertise, and I haven't done even any Windows development since before 2009 so ancient history in the recesses of my mind, but I would think that since the SAK causes the secure desktop to appear then there needs to be graphical connection there?
Probably I'm wrong in that supposition there, but then what happens?
Euh, I think a secure attention key is fine; you only have that chord sent to a designated trusted process; preventing other processes from being able to react to it and mimic an auth dialog.
You absolutely can do secure attention key with just another program. If your account does not have /dev/input permissions, only your display server has keyboard access (unless you run stuff as root lol), and handle key combos that force some secure thing to happen.
This is part of the huge and unending clusterfuck of vulnerabilities that people find in the Windows graphics stack, which was wisely moved to kernel space early on in NT's life, which makes all these vulnerabilities much more critical than they would be otherwise.
I recall getting stuck in a DLL hell back in Windows 3.11 ATMFD's granddaddy was still supposedly serviced more directly by Adobe themselves and it was a free for all across various application installers which versions they attempted to install. Windows 3.1 era Games had a bad habit of stuffing weird old versions of Adobe Type Manager into their installers. I forget details of the offenders, but there was a particular many-times-too-many repeated sequence of installing an application then immediately repairing/reinstalling Office to fix the Adobe Type Manager. Forgetting that last step IIRC was a very subtle problem until it wasn't, starting as weird message boxes and then eventually culminating in (days of application use later) Stop Codes that crashed Windows 3.1 back to DOS.
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.)
It was moved out in Vista with great fanfare. A side effect was GDI was no longer hardware accelerated. With windows 7 and later hardware acceleration was added back necessitating parts of it return to the kernel. For obvious reasons this wasn't as widely publicized.
I seem to recall having a discussion with you a while back where Windows would just leave kernel pointers out in userspace, which seemed to do with GDI as well.
You draw to a DirectX surface rather than the raw frame buffer but it is by no means translated to D2D. D2D has a "GDI" emulation mode, but it's more than worthless if you care about rendering fidelity with the real thing - and you probably do if your still on GDI these days.
Ah good to know - I was under the incorrect impression that the D2D "GDI" emulation mode was the only codepath remaining. Btw any pointers on how to keep track of the graphics stack in Windows? In the past there used to be a treasure trove of blogs and content in MSDN but over time that community has frittered away. Any pointers on how to keep track of what Microsofts graphics roadmap is going forward?
The simple answer is use D2D/Dwrite for low level render code in new projects. If you use C# there’s probably higher level wrappers over these. Some of the older C# APIs wrap GDI+ which is pretty slow and renders text really poorly so go with whatever new stuff they have now.
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.
I worked on some inhouse tools similar to Excel (rendering highly customizable grids) so efficient 2D rendering is of high interest to me. This is from C++.
As noted in a bullet point in TFA, one workaround is to:
> 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.
> Elsewhere the advisory said: “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.”
I've always wondered why fonts are rendered programmatically...
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...)
Font rendering is a dark art at common resolutions of ~96dpi. These displays are not really suited to display resizable fonts (as opposed to hand-crafted bitmap fonts). To render half-way readable fonts at ~96dpi you cannot just pre-render at an extremely high resolution and then downsize using a generic algorithm. (Even ignoring the unacceptable cost). To the best of my knowledge most fonts are only readable at 96dpi because glyphs have manually picked control points to make sure that certain delicate points are aligned to the pixel grid.
Wording amendment: ... that certain delicate features are aligned to the pixel grid.
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.
Well, for starters, there's kerning [1], hinting [2] and subpixel rendering [3] so that your text stays legible, even at small sizes.
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.
A font can have hundreds or thousands (see CJK) of glyphs, plus variants. Good luck distributing thousands of 5000x5000 bitmaps (easily in the GB range).
> 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?
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.
Well if you just want static vector fonts alone you don’t need anything programmatic; vector images are not inherently code anymore than raster ones. For TrueType I’m pretty sure the VM is only for hinting. OpenType has more flexibility but I haven’t anecdotally seen many vulnerabilities around OpenType. I suspect Type 1 is subject of many vulnerabilities specifically because it’s old code that doesn’t get as much usage.
> Usually, font renderers are Turing complete in some way, and usually this opens up security concerns, and rightfully so...
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.
You're also forgetting things like ligatures. And, how would you even render your proposed fonts in embedded devices? The solution is not "huge bitmaps".
For starters, small characters are not just sized-down versions of large characters. Ligatures et al further complicate things. When you actually try to deal with font management and image quality you'll realize why they went through the trouble of making it so.
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...
> 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.
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.)
> 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.
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...)
> This is a good start! I agree, this might be the way to go
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 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.
Nobody is willing to trade this functionality. You are going to just have to take this as a given.
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.
Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet...
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?
> Actually, I'll come up with a better option... don't render any fonts locally... instead, get them when/as you need them as precisely sized bitmaps, from a font server, somewhere else on the Internet...
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?
A latency and performance nightmare... yes, quite possibly.
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>
Yes, font downloading is privacy invading - You can make a "totally unique" font like "timesoldroman-adfssdg" and then track everyone who's downloaded it, for each webpage you want to track. It's just like any other tracking cookie, except a font.
Please keep in mind that you need to localize 'Administrators' to make this work on non english systems.
When deploying this, it would be better to replace the name with the groups sid.
I am on mobile right now but some fellow hacker can surely provide them.
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:
> 1 - article has wrong info. Under Windows 10 the name is ATMLIB.DLL. ATMFD.DLL is the name for older version of Windows
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.
As someone with no knowledge of windows, what’s with their naming scheme? Is this some DOS remnant? Without context the name alone would be reason to fail code review.
Really? You telling me he was not trolling me? Look up his comments, he's definitely not without "no knowledge of Windows".
Perhaps I should stop giving good advice and help here in comments, as I tried with my comments, and just do what seems to be the norm instead, namely use throwaway accounts and just messing with people instead.
I have no idea, but it doesn't matter, in the sense that it's simpler than that. You can't post the way you did, even if you were being trolled. This is in the site guidelines: "Don't feed egregious comments by replying; flag them instead." That's an indirect phrasing of "please don't feed the trolls".
Commenters here need to follow the rules regardless of what others are doing. It always feels like the other person started it and did worse, which is to say: it always feels like we're justified in breaking the rules. If we go with that feeling, we're guaranteed a downward spiral. The only solution is to inhibit that feeling and hold yourself to a higher standard. Maybe the other person doesn't deserve better (certainly not if they were trolling), but that's not why we
do it. You do it because the community deserves better and it's in your interest to have a functioning community here.
(I can tell you from experience, though, that most of the time that it seems like someone is trolling, that's a misperception, in the sense that they had no such conscious intention.)
I am actually looking if this is cultural or technical because it's not clear. If I'm trolling, this has got to be the most pathetic case of it on the internet. I mean this alone would be interpreted as a joke in other contexts:
> Under Windows 10 the name is ATMLIB.DLL. ATMFD.DLL is the name for older version of Windows
ATMLIB is just a client library, it doesn't process any fonts itself, it's not the same thing as ATMFD.
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.
> 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.
Which is still not good but not as bad as it could be.
Explorer doesn't render arbitrary user selected fonts and Segoe UI is not a PostScript font, so I don't think Explorer itself uses this component at all? (A lot of Windows should be using DirectWrite now? I don't think DirectWrite uses this component either?)
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)?
I found answers to some of my questions on my own:
- 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.
Fair, that link points out the Kernel hosts some sandboxes directly. I had assumed they mostly had to be opt-in at the application level (opt-out in the case of the UWP platform), given the name, and those Panes are open third-party extension points and it does seem like sandboxes should apply to anything running in them as well, so it seems a fair assumption to believe that is where they were applied.
Sadly there's functionality to show previews of fonts when browsing in explorer, which means the font is potentially loaded and used in an explorer context. The appcontainer sandbox will still work in this scenario since explorer is just the unwitting accomplice responsible for loading the font.
Yes, it sounds like Explorer is the one creating/hosting the AppContainer sandboxes specifically for these third-party capable extension points (previews), as it should have always done, which is why AppContainers are mentioned as an existing solution for this exploit.
No, the AppContainer sandbox this advisory refers to is around fontdrvhost.exe. In Windows 10, this is a sandboxed user mode process running the ATMFD code, it's created by winlogon.exe.
Before then, this ATMFD code was only in the kernel, making it a useful vector for privilege escalation.
"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."
"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."
> The second workaround—disabling the WebClient service—blocks the vector attackers would most likely use to wage remote exploits. Even with this measure in place, it’s still possible for remote attackers to run programs located on the targeted user’s computer or local network. Still, the workaround will cause users to be prompted for confirmation before opening arbitrary programs from the Internet.
... 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.
“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.”
Right-click C:\Windows\System32\atmfd.dll
Properties | Security | Advanced | Owner, take ownership.
Close dialogs, go back in and give yourself Full Control.
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.
Someone posted this comment in the arstechnica article:
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)
The new(ish) CFF renderer in Freetype also comes from Adobe. I don't know whether it shares any code with what's in ATM, and if so, whether any vulnerability might be applicable to both, but it might be interesting for someone knowledgeable to investigate.
It's needed for displaying Postscript Type 1 fonts. I believe Adobe owns the licensing for everything but it's up to Microsoft to update the Windows 10 DLL.
It's an adobe component in Windows to handle fonts because Adobe controls/controlled a big part of the font ecosystem. At this point I believe the Windows team controls it and can make changes to it, but it's definitely supporting adobe file formats
I really wish (hope) that Microsoft is working on a brand new OS with a VM like thing for running legacy stuff (like Apple did with OS9 to OSX)
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.
> 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.
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...
von Neumann saw that code is data. Now what? We like the power of computation too much to give it up, and yet cannot avoid the pitfalls of complex interpreters. Compartmentalize though we may, control is not easy to tame.
The X.org one is only technically RCE in practice as you need an authenticated connection to the X server. It is really more of a local privilege escalation for the case where the X server is running as root.
I've never used Windows 10 and it's been years since I had a Windows machine on my desk but is it really that difficult to imagine and/or understand why ~90% of the world's PCs run Windows?
When you have an OS that updates out from under you, takes 45 minutes to shutdown or start up, shuts down without your control etc. it's no wonder people want more control over their updates.
In my experience of running windows 10 on a 7 year old laptop, you get a persistent status icon telling you updates are available. If you ignore that for a week you start getting intrusive notifications saying "your computer needs to restart, do it now?" and if you put that off for a few days you start getting a popup with the options "restart now?" and "ask me in 10 minutes".
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.
These are pretty common complaints, servers, signs and many people get updates forced on them. Windows 10 was forced on many, many people. Just because you don't care doesn't mean lots of people haven't been burned.
Is there a search and destroy program that can 100 percent remove anything with even a hint of adobe code? Windows should banish adobe PDF from being utilized in the is and actively treat it as a virus.
If it's zero day on Windows it is pretty much a guarantee that adobe or Oracle was involved
I imagine you're getting downvotes because of your smug hyperbole, but in essence, I wouldn't deny that that is a legit question (not the entire fontgame, I guess, but a core part of it anyway).
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?
* 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).