Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 24 May 2016 19:34:29 -0400 (EDT)
From: cve-assign@...re.org
To: misc@...b.org
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE request: /tmp usage race condition in onionshare

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> 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
> 
> 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.
> 
> 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

As far as we can tell, there is only one primary problem: the product
accepts the existence of a pre-created /tmp/onionshare for which
ownership and all permission bits are controlled by the attacker.
(Control over the setgid bit isn't really an independent problem with
a realistically independent solution.)

Use CVE-2016-5026.


> 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.

Nobody has commented on this today, so we are not going to assign a
separate CVE ID related to an shutil.rmtree impact unless there is
further research by someone.

The code has "self.cleanup_filenames.append(self.hidserv_dir)" and the
product should have been designed so that self.hidserv_dir is never
something controlled by an arbitrary unauthorized local user. Possibly
you are envisioning a threat model in which the attacker controls the
process running tor but not the process running onionshare. In that
situation, it might be important to understand whether there's any
symlink following in shutil.rmtree, because this might allow the tor
process to trigger unlink actions with the privileges of the
onionshare process.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at
  http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJXRORnAAoJEHb/MwWLVhi2AjAP/213PqKqOX4HRjUx4vU2Y4gd
PUqAk17+LR9BgsIbWJTCl1kcXGSlpHHqsgq/8W3OP+Aumsr6iLy5ksZmw7D9xgyW
wYOslFWUA6z9Drt/P24OxiDrHfpqRAxyPclAQJbSgNwmBk9iQK9Tpb+ACLDr3yOU
XBcbnBr1QKT2kOFogdB8bx+Qz/uhR9wAJ0f37nJ+iI3Y6pzeKzMDEHl/je9/Pa+X
iHjUPuKYHU/A+X+2mN3nBmuXJerijn/MBKjgxW3L4DCNOr5NUC1UQ2WULE9WIds1
DS6CvpaVsZXSA5Q094HFvo0M2AoyfePpQuVuGgPZ3tens//In3pr3xkKPT316HW4
eKNH7I9L6Xc604a64TzFmSQnWui7ZlOwFy/0aR8p2mZCBYEKqMkV1OvFx78EE0pw
QpZMRuoz3EcnwNfIhKYpzVzCf1UOKw7srdIfuxnLO6dAPQhMnios26mU7BnxxlLR
4UiZQWeDMZVBqwd+NJnL1NupgAs/4H1mQ+vKIn/obpYnTxGb8q1+x61eyk1Ueh/O
JFBj4gfMnO7v/zA0wtlDK/otE9j/XxWHTw9gKH7BAr3wdbJFPoYnng2CMRFjBva3
Kq4j/ml0BclQDxmk4/3PVc19rO56h0EgMKccArJSVANjMrj3YDmKlTcS2YcaJIVa
zFC5SNEvmY0EdRR6f2gX
=RzaD
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists

Your e-mail address:

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

Powered by Openwall GNU/*/Linux - Powered by OpenVZ