LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 01-30-2015, 04:46 PM   #16
cepheus11
Member
 
Registered: Nov 2010
Location: Germany
Distribution: Gentoo
Posts: 212

Rep: Reputation: 57

Quote:
Originally Posted by sag47 View Post
How hard is it to download an executable and run it on a remote system (assuming there's not firewall protections prohibiting it)?
Very hard. And firewalls are the norm these days. How would you run a program on my computer, if you control a website I visit? Statistically, this is possible (zero day exploits), but how does it make a difference if I use truecrypt for my data? Again, not truecrypt's fault.

Quote:
I don't buy this assumption that it's the program he wrote that is flawed.
I deduced this from his description of what the program does: It runs its first parameter as a program. /bin/bash in his example. With c knowledge, very easy to write. And he deliberately put the executable with suid bit in file flags in the container. That's the whole trick, and this trick would be possible with many filesystems. Udev is smarter these days - my ext2 usb stick is mounted with nosuid - but you are blowing up the proportion of "truecrypt's fault" a bit. A cautious user could still open the container with "--filesystem=none" and mount with "nosuid,nodev".

Quote:
Originally Posted by mhogomchungu
If there is a linux based public computer with TrueCrypt installed for the public to use to access their TrueCrypt
volumes,then through this trick,any user can get root access on that computer.
Let me rephrase this a bit: If there is a linux based public computer with /bin/mount installed for the public to use to access their unencrypted volumes,then through this trick,any user can get root access on that computer.

Again, not exactly truecrypt's fault.
 
Old 01-30-2015, 10:36 PM   #17
sag47
Senior Member
 
Registered: Sep 2009
Location: Philly, PA
Distribution: Kubuntu x64, RHEL, Fedora Core, FreeBSD, Windows x64
Posts: 1,579
Blog Entries: 35

Rep: Reputation: 397Reputation: 397Reputation: 397Reputation: 397
Quote:
Originally Posted by cepheus11 View Post
Very hard. And firewalls are the norm these days. How would you run a program on my computer, if you control a website I visit? Statistically, this is possible (zero day exploits), but how does it make a difference if I use truecrypt for my data? Again, not truecrypt's fault.
I don't think you understand the point I made and took it out of context with zero day exploits. You're very mistaken if you think most computer firewalls (including servers) are strict prohibiting outbound traffic. Inbound, sure, but not outbound.

I'll reiterate. This can be mitigated by changing the default options truecrypt uses to mount the filesystem. It is entirely truecrypts fault if an executable can be launched from a truecrypt mounted filesystem and gain root without normal authorization. That is what is called an exploit.
 
Old 01-31-2015, 04:37 AM   #18
cepheus11
Member
 
Registered: Nov 2010
Location: Germany
Distribution: Gentoo
Posts: 212

Rep: Reputation: 57
Quote:
You're very mistaken if you think most computer firewalls (including servers) are strict prohibiting outbound traffic.
I fail to see how outbound traffic is relevant here: The task is "get an suid binary to run on my computer". Downloading mhogomchungu's container and executing the "owned" program by hand does not count - everybody can infest their containers by downloading something randomly from the oh-so-trustworthy internet and running it. That's how most private computers get infected - by user naivety or stupidity.

The rest of your post: Fair point. I tried different scenarios with normal unencrypted filesystems and it seems that consolekit/polkit forbids suid option with removable devices. Which is good. A normal user cannot run mount directly with a filesystem not in fstab. Truecrypt developers could have done better by using nosuid and nodev by default for internal devices, and using consolekit/polkit/systemd for removable devices. These forbid suid anyway.

mhogomchungu constructs two scenarios which I think should be treated differently:

1. Truecrypt usage on your own workstation. Cryptsetup-luks should be the software of choice, but maybe container exchange with windows is needed. Truecrypt asks for root/sudo password, which means unauthorized users cannot use truecrypt at all. You know the passwords, and if you care about suid/dev, you do the following (as root):

Code:
truecrypt -t --fs-options=nosuid,nodev /path/to/container /path/to/mountpoint
2. Truecrypt on a public computer accessible to anyone. This is not responsibly possible. Truecrypt asks for root/user password and tries to use sudo or root directly. Without password, truecrypt is not usable at all. I hope noone is stupid enough to configure a public computer in that way. Users could just become root directly, without using truecrypt and an own suid binary in a container.

Last edited by cepheus11; 02-01-2015 at 05:57 AM. Reason: mountopts can be passed to truecrypt directly, only one command necessary
 
Old 01-31-2015, 09:58 PM   #19
sag47
Senior Member
 
Registered: Sep 2009
Location: Philly, PA
Distribution: Kubuntu x64, RHEL, Fedora Core, FreeBSD, Windows x64
Posts: 1,579
Blog Entries: 35

Rep: Reputation: 397Reputation: 397Reputation: 397Reputation: 397
Quote:
Originally Posted by cepheus11 View Post
I fail to see how outbound traffic is relevant here
Outbound traffic was defending the point that it is not hard to download a remote binary on a system that has already been remotely compromised. The original scenario I painted was a system that was remotely compromised through other means and then truecrypt was the avenue to exploit for root access (in an unlikely scenario that a truecrypt volume was mounted at the same time as the remote compromise).

Quote:
Originally Posted by cepheus11 View Post
The rest of your post: Fair point. I tried different scenarios with normal unencrypted filesystems and it seems that consolekit/polkit forbids suid option with removable devices. Which is good. A normal user cannot run mount directly with a filesystem not in fstab. Truecrypt developers could have done better by using nosuid and nodev by default for internal devices, and using consolekit/polkit/systemd for removable devices. These forbid suid anyway.

mhogomchungu constructs two scenarios which I think should be treated differently:
Other users' scenarios or opinions aside I was defending that the issue posted by the first post of mhogomchungu: was that root access being able to be gained from a truecrypt mounted volume was a bug in truecrypt. Others were defending that it was not truecrypt's problem. I disagreed and drove home the point that it was an exploit that used truecrypt mounted volumes; hence it being a root problem with truecrypt.

I agree with your assessment, cepheus11, that there are better ways to secure your data and that they should be used instead of depending on something no longer maintained. Best practices should be adhered and that includes not accessing anything of importance from a public computer.

Last edited by sag47; 01-31-2015 at 09:59 PM.
 
Old 02-01-2015, 05:54 AM   #20
cepheus11
Member
 
Registered: Nov 2010
Location: Germany
Distribution: Gentoo
Posts: 212

Rep: Reputation: 57
Quote:
a system that was remotely compromised through other means and then truecrypt was the avenue to exploit for root access
Okay I see. I don't know the rationale of the truecrypt developers or if they even thought about that, but "nosuid,nodev" as a default would have been better indeed.

I was critisizing mhogomchungu's exploit because it depended on the user to download his volume from the internet and executing a program from it. I could provide a volume with the same content unencrypted, with the instruction:

Code:
losetup /dev/loop0 /path/to/file
mount /dev/loop0 /path/to/mountpoint
And then as a user:
Code:
/path/to/mountpoint/owned
And it would work in the same way, so one could say "losetup/mount is broken because suid is default".

Last edited by cepheus11; 02-01-2015 at 11:14 AM. Reason: drop root rights before "owned"
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cross-platform encryption alternative to TrueCrypt yzT! Linux - Software 4 06-07-2014 04:24 AM
[SOLVED] PC-BSD(FreeBSD) Truecrypt Alternative Zyblin *BSD 4 12-04-2013 01:11 PM
[SOLVED] Automount Truecrypt, Truecrypt command lline OS Arch Linux yanfaun Linux - Software 5 09-26-2010 07:37 PM
Truecrypt Or Truecrypt Alternative On Centos? b10m3ch4 Linux - Server 5 12-18-2009 03:42 AM
Alternative for windows software in linux sawant priyanka Linux - Software 4 05-14-2009 08:58 AM


All times are GMT -5. The time now is 10:08 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration