Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 20 Oct 2014 05:59:05 +0200
From: Michael Scherer <misc@...b.org>
To: oss-security@...ts.openwall.com
Subject: CVEs request: Incorrect temporary file handling && silent code
 execution in Tomb, a commandline tool to easily operate encryption of
 secret data

Hi,

While looking around, I stumbled accross this :

https://github.com/dyne/Tomb/blob/master/tomb#L153
https://github.com/dyne/Tomb/blob/master/tomb#L59

so the tool is using a predictible filename in /tmp ( albeit not easy to predict ),
and it is used without verification if the file exist already.

So a attacker could pre-create the file with proper r/w acl for his own user,
and then wait until the script use the file. Since the code is run as root
to mount and operate the file like :

https://github.com/dyne/Tomb/blob/master/tomb#L2465
( check_priv running the script as root with sudo )

The tmp_create function will always succeed to change uid and change permissions.
And even if it doesn't, there is no return code verification anyway...

So if a file already exist with suitable name ( which can statistically happen, especially
since the pid is likely predictible ) and suitable permission, a attacker with access
to the system could steal temporary file. One of those file is the temporary key to encrypt
the tomb.

Ironically, a fix for this would be to use /run/user for temporary file but the author 
seems to not like systemd from what I gathered.



A second issue is that the tool is running a script coming from the encrypted filesystem
on open without any option to avoid it, nor any documentation about it :

https://github.com/dyne/Tomb/blob/master/tomb#L1718

So a attacker could give a key and the file to a victim that would run it without
being able to confirm it need to be run. Since the tool can be used with multiple
users ( as seen by a feature logging the last user access in the tomb ), this can be used
to execute code as another user.

The documentation explictely say this is safe to do
https://github.com/dyne/Tomb/blob/master/doc/Tomb_User_Manual.org

And totally ignore to mention that feature.


Can 2 differents CVE be assigned for this, I will take care of contacting upstream via
github tracker ?

-- 
Michael Scherer

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