4 ms·
It sounds like you are trying to deflect the fault away from TrueCrypt.I looked at the link you provided and i opened a TrueCrypt volume with this command: [ro
by mhogomchungu 12y ago
It sounds like you are trying to deflect the fault away from TrueCrypt.I looked at the link you provided and i opened a TrueCrypt volume with this command:
[root@mtz zc]# truecrypt ./rrr.img ../ink -p xxx
[root@mtz zc]#
So i opened it from the command line,i looked at the mounted volume and it was also mounted without "nosuid" option and hence the same problematic behavior is there even when TrueCrypt is used from the terminal.
Even when using the CLI component,TrueCrypt automatically does the mounting and hence its TrueCrypt's fault.
The mounting part is not done by a third party script that just happen to be bundled with TrueCrypt,it is done as a core part of TrueCrypt.The "mount" command is set here[1] and executed here[2]. You can walk up the code path to see where the "nosuid" options should have been set but isnt.
Its kind of hard to follow discussions here so if you want to take this further then respond to my email address at mhogomchungu at Gmail Dot com
[1] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c/src/Core/Unix/CoreUnix.cpp#L376 https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...
[2] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c/src/Platform/Unix/Process.cpp#L83 https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...
ps:
ciphershed is a TrueCrypt fork.You can look up TrueCrypt's original source code if you dont trust the link i gave as i couldnt find easily taggable TrueCrypt source code online
- simoncion 12y agoThere's a reason why I've not included my email address in my HN profile. I'll keep the discussion here. :) So, if you check the truecrypt manpage [0] (or the code in that GH repo that you linked to) you'll see the presence of the --mount-options option. This allows you to pass along any and all options to mount(8) that you wish to pass along... including nosuid. The problem you're describing isn't in TrueCrypt the crypto software, it's in its mount(8) wrapper code. TC behaves as block device encryption software, with a wrapper around mount(8) to handle volume mounting, if you want to also mount those volumes. The wrapper around mount behaves exactly as it should... which is that its defaults are the same defaults as mount, and it provides you options (through --mount-options) to change those defaults, by passing those options to mount. Any other behavior would violate expectations and, thus be grossly incorrect. If you're concerned about others passing you a backdoor flagged with the suid bit, then the TrueCrypt authors gave you a method to mount all TC volumes with the nosuid option set by default. (And, if you're really concerned about the scenario that you outlined, you need a wrapper around mount, anyway, as ALL filesystems that support suid-flagged binaries are "vulnerable" to this "attack".) TC doesn't need to be changed because of this. :) [0] http://www.irongeek.com/i.php?page=backtrack-3-man/truecrypt http://www.irongeek.com/i.php?page=backtrack-3-man/truecrypt
- mhogomchungu 12y agoImagine yourself a linux lab operator at a university somewhere and TrueCrypt is installed in the lab computers for students to use to access their TrueCrypt volumes.Most students will expect to have access to TrueCrypt,the GUI application as that is how most people use TrueCrypt. Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?. Simple answer,you cant. Yes,TrueCrypt gives you an option to pass the "nosuid" option.But thats like having a system that requires a password but gives you an option to not provide it with the default behavior being the option of not providing it. The student who will sit on that computer lab with a TrueCrypt GUI window open will be the one who gets to decide if they want to set the option or not and with the option being off by default,the student will just execute the exploit without changing anything. I should also say that i am mhogomchungu,the founder of zuluCrypt[1] that does block device encryption and also general purpose mounting with zuluMount,a tool that ships with zuluCrypt and hence i have looked at this problem very closely and for years now and i have closely followed how other FOSS projects reason with problems associated with mount command usage and their implementations to work around the problems.There are also other bunch or wrongs that TrueCrypt is doing and i know this from looking at how things are implemented "from inside" and not how they appear from outside. Somebody using zuluCrypt to gain root shell and i will take full responsibility for it,somebody use udisks to get root shell access and i will place responsibility fully on udisks and i am fairly certain they will do the same. [1] https://code.google.com/p/zulucrypt/ https://code.google.com/p/zulucrypt/
- simoncion 12y ago> Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?. Two answers, both simple: 1) You could ask that question about any FS that Linux supports that supports suid binaries. This issue isn't unique to TrueCrypt. This was mentioned upthread by wglb [0], but you brushed him aside with talk of "standard practice". 2) Rename '/bin/mount' to '/bin/mount-real'. Replace /bin/mount with a shell script that checks the desired mountpoint against the mountpoints listed in /etc/fstab (and others, like autofs). If the desired mountpoint is not listed there, add nosuid to the options passed along to /bin/mount-real. Do tell me what I missed here, I only spent two minutes thinking through it. [0] https://news.ycombinator.com/item?id=8059532 https://news.ycombinator.com/item?id=8059532