[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FD] Auto-detection of Compressed Files in Apple’s macOS

[On the web here:

[NOTE: This was originally discovered as a result of a different set
of bugs in Google’s Chrome browser, details of which will be posted
soon. While the impact of this particular issue isn’t high, it was
interesting enough for us to pursue a coordinated disclosure process.
Because of the large number of parties involved, the disclosure
coordination process took a long time which is why this article took
almost two years to publish.]


Compressed files on macOS are autodetected by the operating system
even if they are renamed to certain other extensions. This can be used
to fool users and antivirus software that relies on file extensions by
packaging malicious code inside compressed files with different
extensions. The vendor (Apple) does not consider this to be a security
issue. Most anti-virus vendors for macOS are not affected by this
issue. This was originally discovered in macOS v10.11 (El Capitan) and
v10.12 (Sierra), but the latest version of macOS v10.13 (High Sierra)
was not tested.


On Microsoft Windows, files are identified by their extensions, which
appears after the “.” in the filename. On macOS metadata about the
file maybe available separately and either a creator code, a type code
or a Uniform Type Identifier is used. However, on the Internet (in
browsers and email clients) instead of filenames, MIME media types are
used with a registry maintained by IANA on behalf of the IETF. Linux
systems use a mix of extensions and media types, with some
auto-detection / “sniffing” of media types based on file content. Some
mappings do exists across the various systems as well.

For example, a ZIP archive would be identified as follows:
- Windows – .zip extension
- Internet/Linux – application/zip media type
- macOS UTI – com.pkware.zip-archive

Additionally, on most desktop OSes, an association exists between a
file type and an application that will open it by default. Those
associations are maintained differently from OS to OS, but at their
core they associate a particular identifier about a file type such as
an extension (Windows) or a media type (browsers), and a program
assigned to open it by default. Users are used to this arrangement and
many security utilities such as antivirus programs will only look
inside files that maybe dangerous. For example, a ZIP file on Windows
if renamed to a different extension may not necessarily be scanned by
default because double clicking on it will not open it.

Another important point is that malware authors may sometimes try to
disguise malicious code by compressing it inside an archive such as a
ZIP file. The expectation is that when a user downloads it, they will
double click and open it using the default program on that platform,
and then will execute the malicious code. This is another reason why
this functionality deserves a closer look.


The following two things were discovered:
1. The compression utility that is part of macOS will open any file
extension associated with that program and will try to “sniff” /
auto-detect the original file type used. The following file extensions
were tested:

ZIP Files when renamed as:
- .AS
- .PAX
- .XIP (a Gatekeeper warning will be shown for non-signed files)

DMG files when renamed as:
- .CDR
- .DC42
- .DMG
- .IMG
- .ISO
- .SMI

2. The OS itself (macOS) itself will open and execute some file
formats even when renamed to a different extension. Gatekeeper
protection is not bypassed. The following extensions are affected:

To duplicate the first issue, create a ZIP file containing any content
(we used the EICAR test file) and rename to include a file extension
as any of the compression formats above for ZIP. (AS, CPGZ, PAX or
XIP). Send this file to a macOS computer via USB or email or a link;
download and double click. The ZIP file will open correctly.

You can also do the same thing but with a DMG file for any of the DMG
file formats listed above (DC42, ISO, etc).

To duplicate the second issue, create a PKG file containing some code
or take an existing one, rename as .MPKG and transfer to a macOS
computer. Double click to execute.

All testing was done in May 2016 on a MacBook Pro running MacOS
v10.11.3 (El Capitan), and re-tested again in April 2017 on a MacBook
running MacOS v10.12.04 (Sierra). It is unclear whether later versions
of MacOS are affected since we did not perform testing on versions
past v10.12.04 (Sierra).


There are two issues:
1. Human users and anti-malware software are not aware that macOS
supports a large number of legacy compression file types and may not
be properly looking out for them or scanning them.
Because of the “sniffing” behavior, it would be trivial for an
attacker to package malware inside a well known format like ZIP or DMG
rename it to one of these extensions.
2. Anti-virus software may fail to scan such archives because they do
not expect a ZIP file to be packaged that way.

The information in this article was originally discovered while
analyzing a non-Apple application running on macOS (a separate
advisory will be published in the future).

Our recommendations are as follows:
- Apple should consider deprecating or adding a warning for these
extensions and removing the “sniffing” support.
- Anti-malware software for macOS should support all of these formats,
as well as accounting for the possibility of one format being renamed
as another


The vendor (Apple) does not consider this to be a security issue as follows:
>> After examining your report we do not see any actual security implications.
>> All of the extensions provided in your report are supported disk image formats and will be treated equally.

>> After examining your report we do not see any actual security implications. Archive Utility opens archive files and the extensions you provided are archive extensions.

>> After examining your report we do not see any actual security implications. The Installer app makes it clear when executable code is running even if the file has been renamed.

As per advice of Apple’s security team, we also contacted multiple
antivirus vendors that provide AV software for macOS to check if they
are affected by this issue. Here is what we got back:

Vendors That Responded:
- Avast – not affected
- Avira – not affected
- AVG – related bug for engine versions prior to 4668 has been fixed
earlier (see CVE-2017-9977 and our blog post); other products not
- BitDefender – not affected
- Cisco – one product impacted, tracked by bug identifier CSCve34034 –
no CVE has been issued:
Cisco AMP Virtual Private Cloud Appliance – The Cisco AMP appliance
does not rely on the file extension when processing ZIP archives or
PKG install packages. However, older versions relied on file extension
to detect DMG files and so is susceptible to one of the scan evasion
problems described in the advisory. The DMG portion is now fixed in
software release 1.4.5.
- ClamXAV (Canimaan Software) – not affected
- Comodo – not affected
- CyberByte – not affected
- Dr. Web – not affected
- ESet – not affected
- F-Secure – not affected
- Intego – not affected
- Kaspersky – not affected
- Malware Bytes – not affected
- Protect Works – not affected
- QuickHeal – not affected
- Sophos – not affected
- Symantec – not affected
- Trend Micro – not affected
- Webroot – not affected

Other Vendors:
- 360 Total Security – pending
- BullGuard – no response
- EScanAV – no response
- GData – pending
- MacKeeper – no response
- McAfee – no response
- Panda – no response
- QuikAV – pending
- Total Defense – pending


Apple Product Security Followup Numbers: 638059697,  640528823 and 640528841
Cisco Ref # PSIRT-1814664974


Advisory written by Yakov Shafranovich.


2016-03-21: Report # 638059697 submitted
2016-05-04: Reports # 640528823 and 640528841 submitted
2016-05-21: Report # 640528823 rejected
2016-06-22: Report # 638059697 rejected
2016-06-23: Report # 640528841 rejected

2017-03-15: Advisory provided to the vendor for comment
2017-04-23: Retested on macOS Sierra, updated and resent to vendor for comment
2017-04-28: Reply from vendor received
2017-05-01: Retested on a fresh install of macOS Sierra, revised
advisory sent to vendor for comment
2017-05-01: Notifications go out to AV vendors

2018-01-24: Second time that notifications go out to AV vendors
2018-02-10: Third and final time that notifications go out to AV vendors
2018-02-10: Final advisory shared with the vendor (Apple) for comment
2018-02-25: Public disclosure

Sent through the Full Disclosure mailing list
Web Archives & RSS: http://seclists.org/fulldisclosure/