{"id":33148,"date":"2021-07-15T16:26:19","date_gmt":"2021-07-15T20:26:19","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=33148"},"modified":"2021-07-15T16:26:19","modified_gmt":"2021-07-15T20:26:19","slug":"leaking-files-with-textedit","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/07\/15\/leaking-files-with-textedit\/","title":{"rendered":"Leaking Files With TextEdit"},"content":{"rendered":"

Paulos Yibelo<\/a> (tweet<\/a>, Hacker News<\/a>):<\/p>\n

I quickly realized that TextEdit can be tricked into thinking the file opened is an RTF-HTML file even when the file extension is TXT. The ability to inject HTML into a TXT file obviously opened lots of potential attack vectors.<\/p>\n

[…]<\/p>\n

I found out the CSS property <style> @import { \"url \"} <\/style><\/code> was allowed to load local CSS files. However, the only scheme that worked was file:\/\/\/<\/tt> and not even http\/s:\/\/<\/tt>. While this means we can’t make external requests, it also means we can hit or open other files that are stored locally on the device. This creates a very obvious DOS vulnerability that acts like a blind SSRF by writing a recursive file inclusion or, reading files with infinite data streams like \/dev\/urandom<\/tt>, \/dev\/zero<\/tt>. a 2kb text file can crash your mac. COOL, but completely useless.<\/p>\n

[…]<\/p>\n

While they did a good job blocking TextEdit from making external requests, [AutoFS] was the one thing they forgot when they allowed file:\/\/\/<\/tt> scheme, on OSX file:\/\/\/net\/11.22.33.44\/a.css<\/tt> connects to 11.22.33.44.<\/p>\n

[…]<\/p>\n

By combining the <style><\/code> CSS attribute with the <iframedoc><\/code> attribute, an attacker can first include an unclosed style tag, embed the contents of the file they want to steal and then leak the content as dangling parameters to their evil site as soon as the file is open.<\/p>\n<\/blockquote>\n

This was addressed<\/a> in macOS 10.15.1.<\/p>\n\n

Previously:<\/p>\n