
German BSI withholds Truecrypt security report - rffn
https://www.golem.de/news/encryption-software-german-bsi-withholds-truecrypt-security-report-1912-145552.html
======
60654
Note, the title is no longer accurate. There's an update at the end of the
article, along with a download link:

> Shortly before we published this article the BSI has allowed to publish the
> Truecrypt documents. They can be downloaded from the Frag den Staat web
> page. Update from December 16th 2019, 13:22

~~~
hvidgaard
Either they had to do that, or they had to be ready for the barrage of
incoming requests for the documents.

~~~
usrusr
Which gives the "withhold" part of the story a strong push towards Hanlon's
Razor, once the topic escalated to higher ranks the copyright ceased to be a
hindrance.

Or more precisely, towards an organizational variety of Hanlon's Razor, where
stupidity takes the form of the organizational failure mode of underlings not
being authorized to do what would have been the right thing.

Curiously, a less colloquial formulation of Hanlon's Razor would replace
stupidity with incompetence and this, when translated to German contains a
hint of a precisely matching double entendre: in German, "Kompetenz" is used
for two separate things. For being able to (like in English) and being
authorized to. It's not a full double entendre because the negated form
"Inkompetenz" is exclusive to the mental ability, just like the English
counterpart, but what's a good aphorism without subtle extra layers?

~~~
Certhas
Scheinbare Bösartigkeit kann oft durch mangelnde Kompetenz erklärt werden. ;)

------
Grumbledour
It is sad to see the state still making freedom of information requests so
difficult and using copyright as a flimsy excuse to hinder citizens to share
the information when they finally manage to get it out of them.

I find it especially sad to see something like this held back by an entity
that claims to want to protect security in information technology and doubly
so since this information would be relevant to the developers and many state
entities that use the software and its successor.

The BSI is sadly often toothless when it comes to actually enforcing security
standards on federal entities but to see them not even trying to educate on
such matters, when they clearly know better, squanders a lot of trust one may
have in them.

~~~
chmod775
> since this information would be relevant to the developers and many state
> entities that use the software and its successor.

The BSI actually _did_ communicate the findings of the report to the TrueCrypt
developers in 2010, which the developers ignored:

> The results were communicated to the Truecrypt foundation, however the
> Truecrypt developers didn't consider them to be relevant. BSI furthermore
> says that the results were not intended to be published.

(From page 2 of the article)

~~~
Grumbledour
Yes, but they neglected to tell the veracrypt developers once truecrypt
stopped being developed. Though they also do know many municipalities using
both applications. They should have told the veracrypt developers and advised
the municipalities to switch to the newer version. And the whole argument
about the information being outdated by then when both are clearly in use
seems negligent of their duties.

~~~
chmod775
Veracrypt didn't exist back then and Truecrypt would only be 'deprecated' five
years later. This was in 2010.

Personally I would've given up after a few months of trying to get a
vulnerability fixed. Can't really blame them this got buried after five years.

------
jmakov
"... 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."

~~~
aasasd
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.

~~~
unixreply55
Yes; that is why it is recommended that untrustworthy drives be mounted with
the `nosuid` flag.

~~~
aasasd
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.

~~~
cyphar
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.

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

~~~
aasasd
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.

~~~
cyphar
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...](https://elixir.bootlin.com/linux/v5.4.3/source/include/linux/kdev_t.h#L10)

------
cantrevealname
The casual user stumbling on this article is going to think that TrueCrypt or
VeraCrypt has been broken. There’s a big difference between attacks on a live
system when a volume is being used, versus cases in which an encrypted volume
is lost, stolen, or copied.

It needs to be firmly said that there is still _no known way_ to recover
plaintext from an unmounted TrueCrypt or VeraCrypt volume on a powered-off
system without knowing the pass phrase. TrueCrypt and VeraCrypt are still
totally secure for the standard use-case of protecting your powered-off laptop
being stolen, or your backup drives being lost, or an encrypted volume that
you’ve copied over to Dropbox being compromised.

~~~
gruez
>The casual user stumbling on this article is going to think that TrueCrypt or
VeraCrypt has been broken.

And why should the casual user use TrueCrypt/VeraCrypt when
Bitlocker/Filevault works out of the box and is built into the operating
system? I feel like that most people using veracrypt do so because it's open
source, and they're distrustful of the software vendors. For that threat
model, you need to have protections against evil maid attacks, which
TrueCrypt/VeraCrypt does not have.

------
chmod775
> As Truecrypt got no further releases the software is still vulnerable for
> all those weaknesses. [...]

> The BSI knew all that. [...]

> The results were communicated to the Truecrypt foundation, however the
> Truecrypt developers didn't consider them to be relevant. BSI furthermore
> says that the results were not intended to be published.

This is looking pretty terrible for Truecrypt. It means they ignored a
vulnerability report and kept the vulnerabilities around for five years.

~~~
blattimwind
Truecrypt has been abandoned for ~seven years or so.

~~~
chmod775
This was in 2010. Truecrypt wouldn't be 'deprecated' for like five more years
after that.

------
EsssM7QVMehFPAs
Why would they release an audit that effectively provides them with zero-days
into encrypted suspect disks.

They release now because no one is using TrueCrypt any longer..

~~~
lucb1e
Because there weren't any real zero days in the report in the first place. The
article mentions that it's mainly minor things like failing to clear memory,
which is only helpful in rare circumstances.

------
unnouinceput
I use VeraCrypt and none of this are of my concern in my daily use of it. Can
anyone tell me if my containers are still safe from prying eyes since I upload
them to cloud? I need specific answers from anyone working on VeraCrypt, not
general answers of "yeah, they are unsafe" that usually HN does.

~~~
Zenbit_UX
Since you're uploading them to the cloud do keep in mind that given 60 years
of computer advancement, today's encryption standards will be unlikely to
withstand tomorrow's hardware...

~~~
tgsovlerkhgsel
Counterpoint: DES was broken because of the short key length, something that
had been criticized very early on.

Asymmetric crypto will likely fall soon; symmetric crypto with conservative
key length choices, e.g. AES-256, may stand for a long time (including the age
of quantum computers).

------
pushedx
Is there a solid alternative to TrueCrypt with most of the features that’s
been implemented with a proof-checking system such as OcaML Mirage?

------
kjaftaedi
If you're going to comment, it's highly preferable that you read the article
where all of this is explained.

~~~
yorwba
Somehow I didn't notice the article was paginated. Thanks for pointing that
out.

------
onetimemanytime
Much safer to assume that a decent nation state can decrypt Truecrypt and a
lot of other things. You can hide stuff from your wife, friends or banana
Republic countries, but I wouldn't bet against NSA with 30 years in jail.

~~~
treljherthj
True, but not by outright cracking the encryption.

They will get your password instead, by implanting your keyboard, putting a
camera behind you on the wall, or grabbing you just after you've entered your
password.

~~~
onetimemanytime
Good point. Another thing: even if they can decrypt it, they'd save that for
Osama types, not ruin it over a small tax case. Otherwise bad guys would stop
using it. Maybe decrypt but not use in court...

~~~
iudqnolq
One tool is parallel construction. First they find out what you did through an
illegal/classified method, then they use the benefit of knowing the answer to
construct a way to figure out the same information legally.

For example, an agency illegally taps your phone and find out you'll be
driving with something illegal in your car along a certain route. The agency
then tells some state troopers to notice $your_car driving unsafely at
$location and pull you over for a routine traffic stop and search your car.

It's unlikely they'd take even that risk on a tax case, though.

------
intc
FWIF: [https://truecrypt.ch/](https://truecrypt.ch/)

