oss-security - CVE request: /tmp usage race condition in onionshare

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160523181917.GA19626@sisay.ephaone.org>
Date: Mon, 23 May 2016 20:19:17 +0200
From: Michael Scherer <misc@...b.org>
To: oss-security@...ts.openwall.com
Subject: CVE request: /tmp usage race condition in onionshare

Hi,

I found a rather complicated issue regarding /tmp and onionshare, a
utility to share file over tor hidden services.

See
https://github.com/micahflee/onionshare/blob/master/onionshare/hs.py#L105
for the start of the problem.

And https://www.torproject.org/docs/tor-hidden-service.html.en for
more details on what happen for hidden services.

So onionshare use /tmp/onionshare to create a temporary directory
$HS that is then used for the creation of a tor hidden service, as
HiddenServiceDir configuration.  Then, the tor daemon create 2 files
in $HS, one for the hidden service hostname, the other for the
private key

But onionshare doesn't verify the owner or the exact permission of
/tmp/onionshare.  So if a attacker pre-create a directory
/tmp/onionshare with 777 permissions and him as a owner, he can use
a race condition to inject his own files in the share.

Since the file 'hostname' is created by tor, then opened and read by
onionshare, the attacker could use inotify on the temporary
directory and rename the $HS dir (since he own /tmp/onionshare) and
substitute his own directory with a crafted hostname directing to
his own hiddenservice, thus permitting him to inject his own
hiddenservices and so own files in the exchange, which seems to be a
potential problem.

I suspect that using setgid on /tmp/onionshare might also give
interesting potential attacks.  For example, if umask is not properly
set, the attacker could steal the private key and hostname, thus
being able to place himself as man in the middle during the
exchange, which make the previous attack easier (since the attacker
just have to set a proxy, rather than guessing the filename or
something like this)

I am also not 100% sure that
https://github.com/micahflee/onionshare/blob/master/onionshare/hs.py#L217
and
https://github.com/micahflee/onionshare/blob/master/onionshare/hs.py#L116
are safe if a attacker control the directory that will be used for
shutil.rmtree.

I tried to contact upstream 5 months ago without results.

So I guess I can go public and provides a patch once I have a CVE id 
assigned ( or any others kind of way to identify the vuln...)

-- 
Michael Scherer

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.