Signal-desktop: local code execution via trusted path in signal-desktop package on linux

[n0bd]

i was recently doing some research on vulnerabilities regarding trusted paths and i discovered an issue within signal-desktop which allows for code execution

signal-desktop attempts to load both getconf and ldd binaries from the $PATH environment variable which can directly lead to code execution on a victims machine, if there happens to be a malicious getconf or ldd binary within the users path.

a demonstration of this can be observed here https://asciinema.org/a/ShagWWsiksFY8f4mY2rrvKuIa

[paskalem]

A simple reply

Sent from my iPhone

On Jan 3, 2019, at 9:35 PM, n0bd [e-mail] wrote:

please ignore the formatting problems. github markup is retarded.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[n0bd]

@paskalem is threre any reason in particular you felt the need to quote the previous comment which i deleted after editing the initial report?

[strugee]

What would be the solution here? Honestly it seems to me that if an attacker can place arbitrary malicious binaries into $PATH you have much bigger problems, because AFAIK $PATH by default just contains system directories unless the user has customized it to point to something in ~. So either the attacker has root and can modify system directories in $PATH, in which case it's game over anyway because the attacker has root, or the user has intentionally added user-writable directories to $PATH. In the latter case probably the user did that because they use the commandline and in that case they could be fooled into running a malicious ls binary much more easily.

I obviously am not a regular contributor to Signal Desktop but it doesn't seem like this is their issue to solve. The right solution is to make sure that arbitrary executables can't be written to stuff in $PATH. Am I missing something obvious? (I certainly could be.)

[n0bd]

@strugee

The right solution is to make sure that arbitrary executables can't be written to stuff in $PATH

this approach would not work because the $PATH environment variable can be manipulated by users to point to a controlled writable directory, thus defeating the approach you have mentioned above.

relative paths should not be relied upon for attempting to execute binaries, and as opposed to checking the users provided $PATH environment variable, any attempts at loading or interfacing with external binaries should at the very least use a path such as /bin:/usr/bin:/usr/sbin:/usr/local/bin

for a better example of this attack scenario, the report for keybase-redirector on hackerone (is a good reference (https://hackerone.com/reports/426944)

the fix to keybase-redirector involved assuring that the $PATH env variable is always set to /bin:/usr/bin:/usr/sbin:/usr/local/bin as can be observed here https://github.com/keybase/kbfs/pull/1869/commits/fcb91ce89947d57f38f8887b7fe3e8a3f1f1fd2f

i havent had any spare time to further investigate the actual cause of this in the case of signal-desktop at the time of writing this comment

[scottnonnenberg-signal]

The HackerOne report deals with a service running as root, creating a privilege escalation risk, which is not the case here.

An attacker who can modify environment variables or replace system binaries on the user's path will already have control of the machine.