Date: Mon, 5 Feb 2018 13:07:20 +0100 From: Simon McVittie <smcv@...ian.org> To: oss-security@...ts.openwall.com Subject: Re: KDE Notification URI Loading Issues On Mon, 05 Feb 2018 at 01:01:30 +0100, Jason A. Donenfeld wrote: > Essentially, chat programs or the like that render remote data into > notifications allow remote users to inject some limited subset of > HTML, which is then rendered by the KDE notification UI. I think this is for the chat programs to fix, really: they're the boundary between untrusted and trusted content. The Notifications implementation can't be expected to know which applications generate notifications internally from trusted code, and which applications interpolate untrusted content into notifications. Arguably the chat programs should be parsing messages into an internal representation that is designed to be unable to represent anything potentially malicious, then re-serializing that internal representation to HTML for the notification. A minimal implementation would be to strip all HTML from the version of the chat message that goes to the notifications API, and only include the text content. That probably doesn't work for protocols whose users make extensive use of image-based "custom smilies" and pseudo-emoji, though. > Aside from the fact that this places a great deal of faith in QUrl Which other URL parser would you have used in Qt-based programs? If QUrl isn't correctly implemented, the solution would seem to be to fix it, not to implement a parallel URL parser with different bugs? > it also very explicitly allows for > local files to be specified. I'm told that this is intended by the > spec, and changing the behavior would be a violation of the spec. Is > the spec then broken? The developers think not, and believe that > programs using the global notification mechanism should be responsible > for supplying their own whitelist sanitization. Presumably these global notifications are either an implementation of the freedesktop.org Notifications API, or something very similar. If so, they're intended for many uses, not just chat - for instance my GNOME desktop uses notifications for "low disk space on /home", "you have a meeting in 15 minutes" and "now playing: <song title>", among others. Chat clients are interesting because they process untrusted content, not because they are the only user of this API. My understanding is that, if a local application that is not chat and does not process untrusted data wants to include an icon or image in its notifications, the intention of the spec is that it can do so; for instance media players that show "now playing:" notifications often include the album cover from the user's music library in the notification. Forbidding that would remove functionality from all notification clients, not just chat programs. Similarly, if a chat client translates ":-)" into an <img> that references an icon from the user's icon theme (for example it might be file:///usr/share/icons/Adwaita/48x48/emotes/face-smile.png on GNOME) then that's something we can trust not to be malicious (if there's malicious content in /usr/share we have much bigger problems). I personally don't want text smilies translated to images, but some people do. > - Should we audit all consumers of it and duplicate the whitelist > parsing situation and open various bug reports? The consumers that process untrusted data (chat clients etc.) and send HTML in their notifications, yes; all consumers of the same API, probably not, because many of them don't process untrusted data. If a chat client sends partially or fully attacker-supplied HTML in its notifications then it's almost certainly passing the same HTML to a WebKit WebView or a similar general-purpose HTML renderer to display the message in its own window, for which it will need to take very similar precautions anyway. > - Should we just live with IRC clients that allow remote users to load > arbitrary files into memory If the text-only IRC protocol can do this then something has gone very wrong. There's a de facto standard for mIRC-compatible colours, bold and italic in IRC (which would be translated into very simple HTML for clients that use HTML notifications or a WebView to render messages), but I'm not aware of anything that would be translated into an <img>, except for possibly translating text smilies like ":-)" or emoji into a file:/// reference to a trusted, local icon from the icon theme. smcv
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.