TrueCrypt 4.3 for Linux from http://www.truecrypt.org/ It seems to be possible to perform various denial of service attacks on a Linux computer running TrueCrypt in set-uid root mode, or possible introduce evil binaries into normally trusted locations. I tested this on the latest version, 4.3, which corrected another vulnerability, but it still seems insecure. The following command mounts a file-based container over /usr/bin. This can be done by a non-root user provided TrueCrypt is in set-uid mode, and the file container does not have to contain any files: tim# truecrypt -u myvolume.tc /usr/bin This could result in system binaries becoming inaccessible, or if the user has copied his own binaries into the file container, they could potentially replace legitimate system binaries with malicious ones, e.g. a /usr/bin/sudo that does something nasty. To do this I did the following (as non-root). # truecrypt -c # create a FAT32 volume called test.tc # truecrypt -u test.tc tmpdir # mount in a tmp dir in my home dir # cd tmpdir # cp ../badbinary ./sudo # copy in an evil binary from somewhere # chmod +x sudo # truecrypt -d # unmount the volume # truecrypt -u test.tc /usr/bin # mount same volume over /usr/bin All other system binaries (e.g. screen etc.) are now inaccessible, but if a user (or root) runs sudo (or whatever the user names it) in the meantime before someone realises something is wrong, the malicious binary will be executed. Because the umount and truecrypt binaries reside in /usr/bin, if they have been "masked" by an empty container mounted on /usr/bin, it may not be possible to recover the system without a reboot. It also seems possible to arbitrarily deny users local (and possibly remote) access to the system, for example through the following command: tim# truecrypt -u myvolume.tc /home/sally Even if the user does not have write access to /home/sally, the unrestricted set-uid operation means that "tim" has now "mounted over" sally's home directory. If sally is currently logged in, her files will appear to "disappear" because they have been mounted over. If user sally tries to log in, in my tests she cannot then log in graphically because some of her configuration files have become inaccessible. User sally has been denied access to the system by a non-root user. I believe there also may be another vulnerability here. If user sally could log in (e.g. through a terminal), any files she writes to "/home/sally" will actually be re-directed to the volume mounted by user tim. If the file-hosted volume is FAT32, user tim could potentially "steal" files as they are written not to sally's regular home directory but to the FAT32 volume. I have been unable to test this successfully though since it seems user sally cannot log in after this denial of service is performed. There seems to be other ways to perform a DoS too. Mounting a volume (even if empty) over /tmp affects operation of the system (users cannot log in through X), and mounting over /var/log could be done to subvert system log messages to a FAT32 volume that can be read by any user. A "workaround" is to remove the set-uid bit from /usr/bin/truecrypt, but then only root can mount TrueCrypt volumes. It seems there needs to be much tigher control on where non-root users can mount their volumes to. -- Tim Rees
Thx Timothy. Any reason to keep this restricted? There seems to be another issue as well: CVE-2007-1589 TrueCrypt before 4.3, when set-euid mode is used on Linux, allows local users to cause a denial of service (filesystem unavailability) by dismounting a volume mounted by a different user.
Initial report is puclib here: http://www.securityfocus.com/archive/1/464064 Crypto please advise.
Hmmm... What can I say? I can remove the setuid from binaries...
Alon would be a fine workaround but if upstream plans to fix this soonish we could wait for that. Do you know of any upstream plans to fix this?
Upstream is very unresponsive to any modification/request. For example, as a policy they don't support new kernel versions... And they won't accept simple fixes to their building system. So I really don't know what they are planning and when.
I think removing the setuid and putting a note in the ebuild about the security implications of making it setuid, would be sufficient. Security any other opinions?
Hmmm... After looking at the output, Gentoo ebuilds never put the suid... So we have never had this issue... :)
Hmm normally we would issue an advisory even though we're not vulnerable in the default configuration as I take it some users might have made it setuid themselves. However as there is no upstream fix for this one I think we have two possibilities: - Releasing a GLSA with only a workaround. - Put an enote saying that ppl should be careful with making it setuid (as per comment #6). Security what do you say?
If the users manually set it setuid, they must know what they are doing. I vote noglsa. I would have voted Yes if setuid was the default configuration.
I vote no - we're not vulnerable in the default config.
Ok, closing as INVALID. Alon feel free to add an enote if you want.
