Yesterday Jacob Appelbaum discovered an input sanitation bug in OnionShare 0.3. It is now fixed, and you should upgrade to the latest version before using it again. You can download the latest version from https://onionshare.org/.
Here’s how the bug worked
If the recipient loaded that exact URL, it displayed “Download page loaded” in the GUI. But if the recipient loaded a different URL at the same Tor hidden service address, such as:
The recipient would receive a 404 error and the OnionShare would display “Other page has been loaded: /some_other_url” to the sender. This string, “some_other_url”, is the input that was not being sanitized. If the recipient loaded:
This is a serious vulnerability because the recipient can use it to deanonymize the sender by forcing webkit to load a resource on a website that the attacker controls. This resource will be loaded over the normal internet, not Tor, so the receiver can check their web server log to find the sender’s IP address.
Additionally, I’ve discovered that the version of webkit that comes with Qt4’s QtWebKit framework is scarily old, and doesn’t get automatic webkit updates. It’s possible that there are year-old public webkit exploits could be used by the receiver to not only deanonymize the sender, but escalate to arbitrary code execution.
What is not affected
If an outside attacker monitors the network traffic of either the sender or the receiver, they still couldn’t compromise the file being sent or the anonymity of either party. The attacker in this case must be the receiver (or someone who eavesdropped on the OnionShare URL that was sent, and started making requests to it before the legitimate receiver downloaded it).
How the fix works
OnionShare 0.4 fixes this bug in a couple ways. First, the input is now sanitized, so when the receiver loads:
An important future plan for OnionShare is automatic updating for Windows and OSX, and to be included in Linux distro repositories to use the package manager’s automatic updates. Here’s the issue on GitHub, but for now users have to update manually.
At first it seemed like using webkit to build desktop app GUIs was excellent. It makes it quick and simple to deploy powerful, featureful, HTML5-based desktop programs. But considering potential bugs like this one, and that the version of webkit that ships with GUI libraries like Qt and GTK are abysmally old and don’t get security updates, it now seems like this is a bad way of building secure software. I plan on rebuilding the OnionShare GUI using pure Qt widgets, and not including webkit at all. This will dramatically decrease the client-side attack surface. Here’s the issue on GitHub.
When you’re using OnionShare in Tails there is an additional risk. You’re required to run it as the root user because it needs to open a hole in the local firewall (this will no longer be necessary when we remove webkit), and only the root user in Tails can connect to the Tor control port to start a new hidden service. It would be much better if OnionShare ran as the unprivileged amnesia user, and a separate root processes was started just for the specific tasks that require root. Here’s the issue on GitHub.