oss-security - CVEs request: Incorrect temporary file handling && silent code execution in Tomb, a commandline tool to easily operate encryption of secret data

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

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

Message-ID: <20141020035905.GA24459@sisay.ephaone.org>
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

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.