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
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ