The author was looking from Universal XSS in Safari. This vulnerability is essentially just as bad as complete browser takeover since you can run code on any website, such as banks or Facebook.
After reading through several writeups for Safari UXSS bugs, the author decided to focus on
Web Archive files. These files are created by Safari as an alternative to HTML when a user saves a website locally.
An insanely powerful
feature of these files is that they specify the web origin that the content should be rendered in and the code for the website being ran. From an
article in 2013, if an attacker can modify this file, it would lead to code execution by design.
There are two things that need to happen for this to work. First, forcibly get a user to download a file. Second, get them to open this file in the browser. If this was done, UXSS could be achieved. The author decided to look at custom URI schemes that specifically are allowlisted so they do not cause popups. After looking around, they settled on ShareBear because it was used for downloading files.
With the ShareBear application, the app validates if the user wants to open the file from the custom URI. However, this ask only happens if the user has not opened the file before! So, the user could click on the link, agree once, only to have the file changed to a completely different file type later. Yikes! This looks like it is waiting to get abused.
Unfortunately for the attacker, we cannot simply change the file type: gatekeeper gets in the way. This is because ShareBear gives files the com.apple.guarantine attribute.
Are there any other file types we can use? Apple has applications loaded as DMG files and shortcuts. While digging around with Shortcuts, the goal was to find a file type that would tell Safari to open the Web Archive without triggering the prompt. Symlinks tend to bypass things so I thought the shortcuts was a clever way to go with this.
By creating a shortcut to the Web Archive file, Safari would happily open it with no verification required from GateKeeper! Now, we can use a shortcut to open the Polymorphic file that we downloaded earlier that is now a Web Archive file. At this point, we have UXSS by clicking on a single link.
Another way to open the Web Archive file was also found. The obvious way to open Safari is via Launch Services with a local HTML file. When this is opened, via the file URI scheme, other file URIs can be accessed. When using this with a Web Archive Safari hangs.
For whatever reason, Safari does not perform validation for a Web Archive file if it has a host value in the file URI! Damn, this is such a weird bug that led to terrible consequences. Fuzzing and playing around for the win!
Another way to exploit this the vulnerability was via osax files or "Scripting Additions". The XML-based parser contained an AppleScript application that could contain HTML. It turns out that this HTML renderer and JavaScript application did not follow the Same Origin Policy (SOP). Now, stealing files is trivial to do, since Gatekeeper will happily open these files for us.
The final vulnerability was completed unrelated but still interesting. While fuzzing the icloud-sharing URI, they noticed a lack of domain validation when opening the file in a new tab. Since Safari lacks the URL to open a new tab but does not validate it, this allows an attacker to open arbitrary tabs. When in an iFrame, this should not be possible, leading to a sandbox escape of some sort.
Amazing research with so many weird rabbit holes. To me, there are a few main takeaways:
- Read the docs! This helps you zoom in on the fruitful surface quickly and learn expected vs. unexpected functionality to find bugs.
- Even in the web, fuzzing is useful. The author appeared to have found 2 bugs via fuzzing.
- Don't be afraid to go back to old research! Sometimes, little hints of ideas come back to be useful in the future, which was the case with the Web Archive files exploitation.