“I too like to live dangerously”, Accidentally Finding RCE in Signal Desktop via HTML Injection in Quoted Replies

Remediation TL;DR

If you’re a concerned Signal user please update to the latest version of Signal Desktop (fixed in version v1.11.0) which addresses all of these issues. Note that the mobile apps for Signal were not affected by this issue.

Background Information

If you’re an avid follower of all that is security-Twitter, then you’ve probably heard about the impressive finding of Remote Code Execution (RCE) via HTML markup injection in Signal Desktop by Iván Ariel Barrera Oro (@HacKanCuBa), Alfredo Ortega (@ortegaalfredo) and Juliano Rizzo (@julianor):

Shortly after seeing this Tweet I wanted to validate if this finding was indeed real so I played around with my own copy of Signal Desktop to see if I could reproduce these results. I previously worked with @LittleJoeTables and @infosec_au on research investigating exploitation of web-on-desktop type apps and so I was fairly certain I knew what I was looking at. I began playing around with the Signal Desktop app trying to get arbitrary HTML markup to be evaluated but it didn’t appear to be straightforward. After trying a few different fields (name, plain message, etc) I eventually found that if you created a message with HTML markup (say, <h1>Test</h1>), and you then did a Quoted Reply message to that message, the original markup would be evaluated as HTML! I then posted on Twitter than I was able to reproduce the problem:

“Wait a Minute…”

However, something was not quite right. I later applied the Signal update and yet I was still able to exploit my issue so I thought there was something wrong with my install. I uninstalled Signal Desktop and didn’t think much of it until I later read the writeup done by the security researchers. Upon reading the writeup I realized the researchers were just sending vanilla Signal messages which were being interpreted as HTML, and not the Quoted Replies that I had been using. I messaged @HacKanCuBa on Twitter to discuss this oddity, and he tried my method on his copy of Signal Desktop to find…the exploit still worked! As it turns out both were separate very similar vulnerabilities resulting in the same impact. Who could have guessed that?

After this realization we quickly notified Signal of the issue. They had a patch out in hours which was very impressive and they even added in some extra mitigations to prevent the problem from occurring again.

Vulnerability Root Cause

For the full writeup on the original vulnerability, see this article. Here we’ll dive into the root cause of my particular variant (CVE-2018-11101) and show how Signal fixed it.

The core of the vulnerability was in the use of React’s dangerouslySetInnerHTML in order to render the contents of a Quoted Reply message. The relevant code can be found in Quote.tsx and is the following:

  public renderText() {
    const { i18n, text, attachments } = this.props;

    if (text) {
      return (
        <div className="text" dangerouslySetInnerHTML=\{\{ __html: text \}\} />
      );
    }
...trimmed for brevity...

To quote the React documentation itself:

_dangerouslySetInnerHTML is React’s replacement for using innerHTML in the browser DOM. In general, setting HTML from code is risky because it’s easy to inadvertently expose your users to a cross-site scripting (XSS) attack. So, you can set HTML directly from React, but you have to type out dangerouslySetInnerHTML and pass an object with a _html key, to remind yourself that it’s dangerous.</a>

Much like innerHTML, use of dangerouslySetInnerHTML is, well, dangerous and can cause lead to XSS like what occurred in the Signal Desktop app. This allowed for the quoted reply text to be evaluated as HTML and served for the base of this exploit.

Signal fixed this by removing the usage of dangerouslySetInnerHTML, along with further tightening the app’s CSP.

All said and done this vulnerability was present in the Signal Desktop app for about three weeks total before being patched (starting in 1.8.0).

Going Forward

Thanks to some help from my friends @aegarbutt and @LittleJoeTables we were able to compile a list of strategic defense-in-depth recommendations for Signal Desktop which we’ve sent to the Signal security team per their request. At the end of the day there will always be new “hot” vulnerabilities, but the “vendor” response is generally what separates the wheat from the chaff. The Signal team’s quick patch time along with a strong interest in mitigating vulnerabilities of this type in the future was encouraging to see. I’ll remain a Signal user for the foreseeable future :)

Exploit Video

Timeline

  • 4:31 PM – May 11, 2018 PST – Discovery of exploit, although originally mistaken by me for a duplicate.
  • ~3:30 PM – May 14, 2018 PST – Revelation that exploit works against latest version of Signal
  • 3:57 PM – May 14, 2018 PST – Vulnerability disclosed to Signal Security
  • 4:21 PM – May 14 2018 PST – Signal requests 24 hours before disclosure to ensure users patch. States a patch will be out in 2-3 hours.
  • ~5:47 PM – May 14 2018 PST – Patch pushed to all Signal Desktop users

Credits

Special thanks to the following folks:

_

About the Author

Matthew Bryant (mandatory)

Matthew Bryant (mandatory)
Security researcher who needs to sleep more. Opinions expressed are solely my own and do not express the views or opinions of my employer.
Follow @mandatoryprogrammer
Read More

"Zero-Days" Without Incident - Compromising Angular via Expired npm Publisher Email Domains

**NOTE:** *If you're just looking for the high level points, see the"[The TL;DR Summary & High-LevelPoints](#the-tldr-summary--high-level...… Continue reading

Video Downloader and Video Downloader Plus Chrome Extension Hijack Exploit - UXSS via CSP Bypass (~15.5 Million Affected)

Published on February 22, 2019

Kicking the Rims – A Guide for Securely Writing and Auditing Chrome Extensions

Published on June 12, 2018