Yet another font exploit

Topic

New Reply

You’d think that MS would’ve figured out a way to block all of the bad font takeover scenarios, but apparently not. Adobe Type Manager fonts just got
[See the full post at: Yet another font exploit]

6 users thanked author for this post.

jburk07, rontpxz81, abbodi86, lmacri, GreatAndPowerfulTech, Elly

Reply | Quote

Replies

Here are the mitigations:

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv200006#ID0EMGAC

1 user thanked author for this post.

Elly

Reply | Quote

[warrenrumak]

Adobe Type v1?  Yikes… yeah, that code is easily 25 years old at this point.

Other than for extremely specific backwards compatibility situations, I can’t see any reason for Windows to even support that format anymore.  Type 1 stopped being relevant in production work by the late 1990s.

• This reply was modified 5 years, 1 month ago by warrenrumak.

2 users thanked author for this post.

Mr. Austin, woody

Reply | Quote

I can’t see any reason for Windows to even support that format anymore.

I think they have to support it because it’s part of the OpenType standard. Windows doesn’t support old-school .pfm style Type 1 fonts, but some OTF files have “type 1” in the information.

And the advisory talks about “automatic display of OTF fonts.”

Reply | Quote

Really anything Adobe should not be included in Windows without the needed source code auditing and MS should be carefully vetting what gets allowed into the Windows core functionality by MS and buy whatever API hooks that MS provides for third party applications get their functionality plumbed in via those API hooks. All that needs to be properly sandboxed and unable to get outside of that protected area.

Reply | Quote

@Woody

Is this any different from the workaround that Microsoft posted?

https://www.ghacks.net/2020/03/24/critical-font-parsing-issue-in-windows-revealed-fix-inside/

1 user thanked author for this post.

woody

Reply | Quote

They look the same to me. Anybody see any differences?

Reply | Quote

Microsoft’s Security Advisory ADV200006 has been revised twice today:

“Microsoft has become aware of limited targeted Windows 7 based attacks …”

“Please Note: The threat is low for those systems running Windows 10 due to mitigations that were put in place with the first version released in 2015. Please see the mitigation section for details. Microsoft is not aware of any attacks against the Windows 10 platform. The possibility of remote code execution is negligible and elevation of privilege is not possible. We do not recommend that IT administrators running Windows 10 implement the workarounds described below.

I believe there are also new alternative workarounds for Windows 7 and Windows 8.1 which involve disabling atfmd.dll by renaming it (or disabling ATMFD via the registry for Win 8.1).

1 user thanked author for this post.

woody

Reply | Quote

Is it just me or does the layout of the advisory just not look well thought out?  If one follows the instructions for protecting Windows 8.1 and earlier by creating the registry key to disable the support for the library, does this mitigate the Windows Explorer exposure?  If I set the registry key is there any reason to do the hokey pokey on renaming the DLL?

Reply | Quote

Only Windows 7 is being attacked. No workarounds necessary for Windows 10.

1 user thanked author for this post.

Nibbled To Death By Ducks

Reply | Quote

GHacks does not include renaming of the DLL file.  I would think the registry key is equal in disabling, but the document could be improved to make this clear.

Reply | Quote

I wonder why Microsoft didn’t share the GPO for turning both panes off for Windows Explorer?

Location:  User Configuration – Administrative Templates – Windows Components – File Explorer – Explorer Frame Pane

Setting:  Turn off Preview pane

Setting:  Turn on or off Details pane

4 users thanked author for this post.

Moonbear, jburk07, woody, Nibbled To Death By Ducks

Reply | Quote

[Moonbear]

@Woody

In that case, is unchecking the Details and Preview panes in File Explorer and then disabling the WebClient service enough to mitigate this? Or is also necessary to also add the registry entry shown at the end of the gHacks article?

• This reply was modified 5 years, 1 month ago by Moonbear.

2 users thanked author for this post.

jburk07, woody

Reply | Quote

Short answer: I don’t know. Wonder if anybody else does?

Reply | Quote

I just followed the ghacks:

For Windows 7, Windows 8.1 and Windows Server 2008 R2, 2012 and 2012 R2:

1. Open a Windows Explorer instance and select Organize > Layout.
2. Disable the Details pane and Preview pane options (if they are enabled. You should notice that the panes are not displayed when disabled)
3. Select Organize > Folder and search options.
4. Switch to the View tab.
5. Under Advanced Settings, check “Always show icons, never thumbnails”.
6. Close all Windows Explorer instances.

This is going to be a major PITA for those of us who like to work with graphics. Can some actually quantify WHERE, WHEN and HOW FREQUENTLY these attacks are happening, along with who the most vulnerable of the WIN 7 crowd are?

“Only Windows 7” now, eh? My olfactory sensors detecting something not quite so sweet in Denmark…

Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty

1 user thanked author for this post.

Moonbear

Reply | Quote

“Only Windows 7” now, eh? My olfactory sensors detecting something not quite so sweet in Denmark…

That just means the adversary actually using this exploit is unsophisticated. Defeating Windows 8.1 would require an ASLR bypass, defeating Windows 10 requires that and possibly a sandbox bypass as well (especially on newer versions when fonts were completely moved out of the kernel).

Which isn’t a great sign, it’s possible this has been used quietly by the big nation-state adversaries for a while before the little guys got their paws on it.

Reply | Quote

Forgot to ask this: Why is there no CVE on this yet, just a MSFT Advisory? And again, can we get someone, or agency,  actually quantify WHERE, WHEN and HOW FREQUENTLY these attacks are happening, along with who the most vulnerable of the WIN 7 crowd are?

If we can put a CVE to this, Eset has a very good “Virus radar” site that gives this sort of info on exploits.

The big mystery to me is why, if this is so critical, is there no CVE yet?

Win7 Pro SP1 64-bit, Dell Latitude E6330 ("The Tank"), Intel CORE i5 "Ivy Bridge", 12GB RAM, Group "0Patch", Multiple Air-Gapped backup drives in different locations. Linux Mint Newbie
--
"The more kinks you put in the plumbing, the easier it is to stop up the pipes." -Scotty

Reply | Quote

Perhaps we have to wait until next week? Due to;

“We appreciate the efforts of our industry partners and are complying with a 7-day timeline for disclosing information regarding these limited attacks.”

1 user thanked author for this post.

woody

Reply | Quote

The owner of the atmfd.dll file is Trusted Installer, change that to admin and it is possible to rename, using windows 7.

https://helpdeskgeek.com/windows-7/windows-7-how-to-delete-files-protected-by-trustedinstaller/

To bad, i got stuck on way how to follow this tutorial, i dont get it but some people does…? The best way is to rename or delete atmfd.dll so if someone would make an better, or easier tutorial then I can re enable showing my icons on desktop, they all look the same now because of security measures:(

Reply | Quote

The original Microsoft Advisory linked in the second post of this thread listed the commands required to do that.

Reply | Quote

For any MS Defender ATP customers, MS have updated the Microsoft Defender Security Center dashboard with the vulnerability – “Type 1 font-parsing 0-day vulnerabilities”.

There is a bit more info there, but you also have access to an advanced hunting query to locate processes launched with possible malicious intent by the vulnerable font parser on Windows 10 devices.

Reply | Quote

My Windows 7 system running 0patch has just now received a micropatch for this vulnerability:

I happened to be working on the computer when 0patch popped out a notification to report application of the new patch.

 

Keep Running Windows 7 Safely for Years to Come  
Make Windows 10 look and work like Windows 7

1 user thanked author for this post.

jburk07

Reply | Quote

0Patch : Micropatching Unknown 0days in Windows Type 1 Font Parsing

…As we’ve done before in a similar situation, we decided to provide our users with a micropatch to protect themselves against these vulnerabilities in a “0patch fashion”, i.e., completely automatically and without disturbing users even in the slightest.

Our micropatch is currently available for fully updated Windows 7 64-bit and Windows Server 2008 R2 without Extended Security Updates (ESU), which means with January 2020 Windows Updates installed. This provides protection for our users who continue using these Windows versions but were unable or unwilling to obtain ESU, and are now, somewhat ironically, the only Windows users with a patch for these vulnerabilities….

https://blog.0patch.com/2020/03/micropatching-unknown-0days-in-windows.html

2 users thanked author for this post.

Cybertooth, jburk07

Reply | Quote

MoonBear said:
is unchecking the Details and Preview panes in File Explorer and then disabling the WebClient service enough to mitigate this? Or is also necessary to also add the registry entry

The font parsing vulnerability is found in the Adobe Type Manager Library’s kernel font driver (ATMFD.DLL) itself.

Disabling Windows/File Explorer’s Preview Pane, Details Pane, & thumbnails view merely disables some of the “vehicles” used by ATMFD.DLL to render Adobe Type 1/PostScript & OpenType (OTF) fonts.

• Other possible “vehicles” include 3rd-party file managers, 3rd-party file font viewers, email clients etc. that utilize Windows’ ATMFD.DLL driver to render the affected font formats.
• MS Outlook’s preview function is apparently not affected by the vulnerability.
• Web browsers like Internet Explorer, Firefox, Chromium, etc. do not use ATMFD.DLL to render fonts on a webpage, so these are not affected either.

Disabling the WebClient/WebDAV server service merely turns off one of the routes that a malicious font (or a document using a malicious font type) can infiltrate the local PC via the local network/server route.

• Even then, it is still possible to receive a malicious file via the internet (eg. through email or by manually downloading from a hyperlink on a webpage).

As such, unless Microsoft provides a cure for the defective ATMFD.DLL ( & MS already declared it won’t be doing so for unsupported Win 7 & older systems), the most effective mitigation is to disable ATMFD.DLL by:

• Adding a new registry entry:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows
=> add: DisableATMFD = 1 [REG_DWORD]

• &/or renaming ATMFD.DLL
  Note: This DLL is a protected file, so you need to change the DLL’s file permissions first before you can rename it.

… followed by rebooting the PC.

Negative Impacts of Disabling ATMFD.DLL:

1) It is no longer possible for any application to use/display Adobe Type 1/PostScript & OpenType (OTF) fonts, or view documents created with these font formats.

2) A malevolent local/remote user with logon credentials to your PC can easily undo the disabling, before proceeding to carry out a local attack.

3 users thanked author for this post.

SueW, GoneToPlaid, Cybertooth

Reply | Quote

[tcc089]

Hi there!

I’m still running Windows 7, so I just tried adding the DisableATMFD DWord (32-bit) value 0)  registry key and after rebooting I could no longer access my WD Home Duo NAS.  I renamed the key to “xDiasableATMFD”, rebooted again, and all is fine now.

I’m not saying that disabling ATMFD is a bad thing, just be aware of one of the possible side effects.

Cheers!

• This reply was modified 5 years, 1 month ago by tcc089.

Reply | Quote

Weird. I wonder why a NAS should care about embedded font technology?

Reply | Quote

Hey everyone,

The newsletter incorrectly states that DisableATMFD should be set to zero when in fact it should be set to 1. Also note that this vulnerability does also affect Windows 10. See either of the following for workarounds:

https://docs.microsoft.com/en-us/security-updates/securitybulletins/2016/ms16-132

https://www.askvg.com/fix-critical-font-vulnerability-in-windows-7-windows-8-and-windows-10/

Best regards,

–GTP

 

1 user thanked author for this post.

SueW

Reply | Quote

GoneToPlaid wrote:

Also note that this vulnerability does also affect Windows 10.

It’s not as severe for Windows 10, and attacks were only reported against Windows 7, but updates have been released for Windows 10 too:

ADV200006 | Type 1 Font Parsing Remote Code Execution Vulnerability

Reply | Quote

Could someone kindly paste the text for the commands required to be run from a command prompt as an administrator to both enable and disable the method required to manually rename the ATMFD.DLL file?

For some reason, when I try to view the mitigations at https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/adv200006#ID0EMGAC all I get is a blank page.

Thanks.

Reply | Quote

Rename for 64-bit Windows 7/8.1
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

Undo for 64-bit Windows 7/8.1
cd “%windir%\system32”
rename x-atmfd.dll atmfd.dll
icacls.exe atmfd.dll /setowner “NT SERVICE\TrustedInstaller”
icacls.exe . /restore atmfd.dll.acl
cd “%windir%\syswow64”
rename x-atmfd.dll atmfd.dll
icacls.exe atmfd.dll /setowner “NT SERVICE\TrustedInstaller”
icacls.exe . /restore atmfd.dll.acl

Restart after rename or undo.

For 32-bit; just the first half of each batch of commands, not including cd “%windir%\syswow64” and following lines.

2 users thanked author for this post.

7ProSP1, Elly

Reply | Quote

For those wondering just why there are TWO sets of seemingly identical commands, it’s because the atmfd.dll file exists in BOTH the system32 AND the syswow64 sub-directories of the Windows directory. You have to rename BOTH instances of the file for the workaround to be completely effective.

To continue from above, you also have to rename the file in both locations to completely undo the workaround.

Ok, there, I’m done! 

1 user thanked author for this post.

Elly

Reply | Quote

While I understand manually entering the commands from a command prompt changes the permissions granted to the atmfd.dll file in both directories (where applicable), wouldn’t simply just renaming the atmfd.file to something else by right clicking on it accomplish the same thing?

i.e., This would also make the file unavailable to be exploited because it, in essence, wouldn’t “exist” anymore.

Further to the above, according to 0patch, renaming the atmfd.dll file is the most effective mitigation, because it eliminates the vulnerable code thereby reliably blocking all remote and local attacks using these vulnerabilities in Windows font parsing.

I’m certainly not trying to argue with anyone, I just want to make sure the most effective mitigation for this issue is applied.

1 user thanked author for this post.

Myst

Reply | Quote

You won’t have permission to change the file name without running all the other commands.

Stick to the registry change, simples!

cheers, Paul

1 user thanked author for this post.

Myst

Reply | Quote

Right, I get that.

But what I’m saying is, if you simply just change the name of atmfd.dll by right clicking on it, wouldn’t this completely remove the threat of an exploit as the target file (atmfd.dll) then wouldn’t “exist” anymore to be exploited in the first place?  Permissions access to a non-existent file would then be irrelevant, correct?

Forgive me, I’m just trying to understand all this and keep everything as simple as possible.

Reply | Quote

7ProSP1 wrote:

But what I’m saying is, if you simply just change the name of atmfd.dll by right clicking on it,

NO. When you right-click on the file, your User ID does not have permission to change the name of the file. You won’t be able to do it.

3 users thanked author for this post.

Myst, 7ProSP1, satrow

Reply | Quote

7ProSP1 wrote:

if you simply just change the name of atmfd.dll by right clicking on it, wouldn’t this completely remove the threat of an exploit as the target file (atmfd.dll) then wouldn’t “exist” anymore to be exploited in the first place?

Yes, except you cannot do that without first changing permissions. Also, exploit kits can carry their own file versions to drop into a vulnerable ’empty’ slot.

3 users thanked author for this post.

Elly, Myst, 7ProSP1

Reply | Quote

For those comfortable carefully poking around in the registry, there’s only one entry to modify (or create and modify) vs. two separate instances of renaming a file.

However, poking around in the registry isn’t for the faint of heart, as it can get you into deep trouble rather quickly if the wrong key is incorrectly modified.

Instructions on exactly which entry to modify are in the bulletin from Microsoft, or you can find them in this week’s newsletter in Susan Bradley’s section. However, as pointed out by @GoneToPlaid above, Susan mistakenly wrote that the key in question had to be set to zero (0), when, in fact, it should be set to one (1) to enable the workaround. To undo the workaround, simply set the key’s value to zero (0).

1 user thanked author for this post.

SueW

Reply | Quote

I have no idea what to do here. I have a Win7 machine and when I go to regedit to locate ATMFD.dll file I see nothing and as described by Susan if it isn’t there, add a New command setting it to zero. I read through here and saw GTP’s correction setting the value to 1 and noticed there were posts here mentioning negative effects when modifying or adding new commands. So far I’ve only created the new file as stated by Susan and then deleted it so everything is back to where it was originally before I got going on this new venture. What risks do I take to leave everything as is? I basically use the PC as a workstation with little to no internet use. Using my Chromebook for that, or the iPad at the current iPadOS.

i have also secured the PC through the advice of several folks on Ask Woody, Cybertooth and Canadian Tech have posted very good instructions in order to be as secure as one can be without access to win updates.
Thanks

MacOS iPadOS and sometimes SOS

Reply | Quote

ATMFD.DLL is part of Adobe Type Manager Library’s kernel font driver. If you haven’t installed a program that utilizes it, you don’t have the vulnerability on your system… at least that is what I got from careful reading and checking a Windows 7 I have access to.

I’d love if someone who really knows could confirm that, though…

Non-techy Win 10 Pro and Linux Mint experimenter

2 users thanked author for this post.

Charlie, Myst

Reply | Quote

It was integrated into Windows 7 at some point, for all users… wondering if it is missing from my system because of my Canadian Tech type updating (ie- not in the updates I did), or if I’m just missing seeing it…

Non-techy Win 10 Pro and Linux Mint experimenter

2 users thanked author for this post.

Charlie, Myst

Reply | Quote

I didn’t have the registry entry either, and I’m in the U.S.  I’m now wondering if I should remove the entry I created!  Yikes, is it 1 or 0?

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

Reply | Quote

According to a post made by GoneToPlaid under this topic, the correct value should be set to 1. Even though I am not finding the ATM command in my registry, I’m going to leave the newly created subkey as is and as noted in my latest post until further notice.

MacOS iPadOS and sometimes SOS

Reply | Quote

I set my new registry setting from zero to 1 because it seems to me that zero means it doesn’t run and 1 means it does run.  And I’m pretty sure it’s the intent to have this running since it disables the fonts.

I had no problems after changing it to 1 and rebooting.  I’m open to other opinions on this though.

Being 20 something in the 70's was so much better than being 70 something in the insane 20's

1 user thanked author for this post.

Myst

Reply | Quote

I have an ancient version of Adobe Photoshop, also an older Lightroom and PS Elements, and have blocked Adobe Updater through AV firewall. Also eliminated Adobe Reader and Flash.

Not sure what any of the above actions I took once upon a time would have to do with the ATM vulnerability. Hopefully all is ok the way it sits – idle and peaceful with the ability of a worker bee behind the scenes and off the mainstream.

MacOS iPadOS and sometimes SOS

1 user thanked author for this post.

Elly

Reply | Quote

Those changes do not affect the font vulnerability, you still need to make the registry change.

cheers, Paul

3 users thanked author for this post.

Elly, GoneToPlaid, Myst

Reply | Quote

b wrote:

Rename for 64-bit Windows 7/8.1
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

Undo for 64-bit Windows 7/8.1
cd “%windir%\system32”
rename x-atmfd.dll atmfd.dll
icacls.exe atmfd.dll /setowner “NT SERVICE\TrustedInstaller”
icacls.exe . /restore atmfd.dll.acl
cd “%windir%\syswow64”
rename x-atmfd.dll atmfd.dll
icacls.exe atmfd.dll /setowner “NT SERVICE\TrustedInstaller”
icacls.exe . /restore atmfd.dll.acl

Restart after rename or undo.

For 32-bit; just the first half of each batch of commands, not including cd “%windir%\syswow64” and following lines.

As noted here? Not feeling warm and fuzzy about making these changes.

MacOS iPadOS and sometimes SOS

1 user thanked author for this post.

Elly

Reply | Quote

Ended up going back into the Registry Editor as noted by Susan in the Newsletter and created a new subkey – DisableATMFD – and set the value to 1. Closed the Registry Editor and rebooted.

MacOS iPadOS and sometimes SOS

3 users thanked author for this post.

Elly, GoneToPlaid, Charlie

Reply | Quote

Definitely the easiest to implement / roll back.

cheers, Paul

3 users thanked author for this post.

Elly, Charlie, Myst

Reply | Quote

This is what I did, and I had no issues after rebooting. Killing remote access to ATMFD.DLL, via adding the registry dword and setting its value to 1, is the best option. This is also the simplest and quickest thing to do.

3 users thanked author for this post.

SueW, Elly, Myst

Reply | Quote