Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

German BSI withholds Truecrypt security report

golem.de

Post reply on HN
Print view View original

81–86 of 86 posts

Re: German BSI withholds Truecrypt security report

#81

Post by JdeBP »

saagarjha wrote: post #67
mehrdadn wrote: post #52

Earlier quoted context omitted.

Can I just point out that this is just one vivid example of why tying setuid permissions to a file is a terrible design to begin with? Permissions should be derived from the execution context at run time. (People might hate me for saying this, but this is one of those design decisions Windows fundamentally gets right.)

How do you suggest implementing passwd without setuid?

Using the design of the LSASS is one way, as mentioned. Others include OpenWall's tcb, and Daniel Rench's userdirs.

* https://www.openwall.com/tcb/

* https://web.archive.org/web/20030919191907/http://dren.ch:80...

Re: German BSI withholds Truecrypt security report

#82

Post by tinus_hn »

aasasd wrote: post #28
jmakov wrote: post #13

"... in the simplest case a user can mount a Truecrypt volume that contains a file with suid root permission that will open a shell. Golem.de was able to replicate this scenario in a current version of Veracrypt."

This surprised me the most―never thought about this before. Aren't all permission-supporting filesystems vulnerable to this if mounting by a user is permitted? I presume filesystems don't go through the files and downgrade root ownership.

If you’re mounting a filesystem provided by the user you’re supposed to use the nosuid option which tells the kernel to ignore setuid bits on the filesystem.

Re: German BSI withholds Truecrypt security report

#83

Post by unixreply55 »

cyphar wrote: post #53
aasasd wrote: post #40

Earlier quoted context omitted.

Ah, so even though filesystems don't go through files, they still can block the operation of suid. This suggests then that Veracrypt can simply enable the nosuid option when mounting a device.

And they should also add nodev, to block a similar attack where you add a bunch of block devices with 777 permissions, in an attempt to make the block device "/" is mounted from be readable to a user and thus able to read (and write) any file on the host.

I didn't know of this attack, sounds interesting :) can you explain in a bit more detail how it would work?

Re: German BSI withholds Truecrypt security report

#84

Post by aasasd »

unixreply55 wrote: post #83
cyphar wrote: post #53

Earlier quoted context omitted.

And they should also add nodev, to block a similar attack where you add a bunch of block devices with 777 permissions, in an attempt to make the block device "/" is mounted from be readable to a user and thus able to read (and write) any file on the host.

I didn't know of this attack, sounds interesting :) can you explain in a bit more detail how it would work?

Sounds like it works exactly as described by cyphar. The OS trusts permissions that are set on the files, so if you slip it a device ‘file’ writable by anyone then it will let mere users write to the device even if it points to the root filesystem. Devices are denoted simply by numbers on the file inode in the filesystem, it's not difficult to make one that corresponds to the real disk drive.

Re: German BSI withholds Truecrypt security report

#85

Post by cyphar »

aasasd wrote: post #84
unixreply55 wrote: post #83

Earlier quoted context omitted.

I didn't know of this attack, sounds interesting :) can you explain in a bit more detail how it would work?

Sounds like it works exactly as described by cyphar. The OS trusts permissions that are set on the files, so if you slip it a device ‘file’ writable by anyone then it will let mere users write to the device even if it points to the root filesystem. Devices are denoted simply by numbers on the file inode in the filesystem, it's not difficult to make one that corresponds to the real disk drive.

Right, the attack would be something like:

    # On a machine where you have root, do the following in a Truecrypt volume:
    for maj in {0..4096}; do
      for min in {0..1048576}; do
        mknod block-${maj}.${min} b $maj $min
        mknod char-${maj}.${min} c $maj $min
      done
    done
    chmod a+rwx {block,char}-*
All devices which represent a block device (namely, hard drives and similar media) have some (major, minor) value. There are currently[1] 4096 values for the major number 1048576 for the minor number, so we can just create all of them (or you could just create the first 256 since it's very rare for the number to go above that).

And now when you mount the volume on a machine (with needing root, because that's what TrueCrypt allows you to do), the mounted filesystem contains every possible block and character device with read/write permissions for every user on the system. Therefore, one of the block devices (you can check by doing an ls in /dev) will correspond to the root filesystem and the user can now read or write to it directly.

By adding "nodev", the kernel will not permit any user to access character or block device inodes on the filesystem (even if you would normally have permissions).

[1]: https://elixir.bootlin.com/linux/v5.4.3/source/include/linux...

Re: German BSI withholds Truecrypt security report

#86

Post by exikyut »

ATsch wrote: post #78
exikyut wrote: post #77

Earlier quoted context omitted.

Shhhhhhhhhh. Stop giving systemd more ideas. (/s) (But seriously, imagine a world where you can't get root because D-Bus crashed.)

PolicyKit essentially already does this, and all of the systemd *ctl commands support authentication via polkit

TIL (so that's what the whole PolicyKit thing was all about).

Now I'm wondering what its worst case crash behavior is like.

Post reply on HN