Slashdot Mirror
Newly Found TrueCrypt Flaw Allows Full System Compromise
itwbennett writes: James Forshaw, a member of Google's Project Zero team has found a pair of flaws in the discontinued encryption utility TrueCrypt that could allow attackers to obtain elevated privileges on a system if they have access to a limited user account. 'It's impossible to tell if the new flaws discovered by Forshaw were introduced intentionally or not, but they do show that despite professional code audits, serious bugs can remain undiscovered,' writes Lucian Constantin.
VeraCrypt 1.15 that was released Saturday, contains patches for the two vulnerabilities
Time to update.
It's in the driver which operates at an elevated permission level. If there's a bug in the driver code which allows code execution (buffer overflow comes to mind) that code would be running with elevated privileges. Windows can't necessarily account for all potential flaws in software. Nor can any Kernel.
But I still want to see how high you can build the wall.
“He’s not deformed, he’s just drunk!”
While that might be true in a true microkernel (https://en.wikipedia.org/wiki/Microkernel) design, modern OSes are all at least partially monolithic (https://en.wikipedia.org/wiki/Monolithic_kernel) to avoid the performance penalty of inter-process communications between kernel components. Because of this, drivers tend to run with the same privileges as the kernel. Not sure if that's the case here (TrueCrypt does have a driver, but I didn't RTA to see if that's where the vuln is), but a security vuln in a driver would definitely bypass whatever protections the OS offered.
You can mod your friends, you can mod your nose, but you can't mod your friend's nose.
The VeraCrypt commits fixing the 2 "undisclosed" vulnerabilities:
https://github.com/veracrypt/V...
https://github.com/veracrypt/V...
It is a flaw in the TrueCrypt driver, which, as a driver, runs with special privileges and access normal apps don't have. Drivers require elevation to install and I believe there is a separate install verification dialog for some types of drivers thus Windows has already done its job of protecting you the best it can.
This is why it was discontinued. Stop using TrueCrypt.
This is not a compromise of the TrueCrypt encryption!
This is a bug in the TrueCrypt driver that is installed on Windows systems. The bug allows an account on an already running and "decrypted" system to achieve elevated credentials. This would not be very much different than a printer driver bug.
The fact that this is not an actual compromise of TrueCrypt and its encryption, is likely why it was not found in the audit. It is not a vulnerability that they weer worried about and did not look for anything like it.
TrueCrypt encrypted volumes remain no more or less vulnerable because of this. But, you still should not be using TrueCrypt.
despite professional code audits, serious bugs can remain undiscovered
Doesn't google finding this bug count as on more professional code audit successfully discovering a bug?
When a scientist discovers a new theory do we lament the fact that we've proven that we didn't know everything beforehand?
Did anyone really think that we could possibly ever have a large piece of software with no bugs?
What's wrong with dm-crypt that is shipped as default disk encryption backend by most distros?
Those distros do not include Windows or Mac OS.
AFAICT, FreeBSD doesn't support dm-crypt / luks either.
FreeBSD's go to encryption is Geli, which isn't supported by Linux distros.
eCryptFS works on FreeBSD and Linux, but it's not block level encryption.
TrueCrypt/VeraCrypt/CipherShed... they provide block level encryption that is cross platform. That's a feature that the others lack. It's theoretically possible for dm-crypt/luks to have a MacOS, WIndows, and FreeBSD driver (which would also probably require the filesystem drivers, as ext4 isn't well supported on those either), but it's not easy. Thus the obsession with Truecrypt.
For all of those too lazy to RTFA or summary, the flaw in TrueCrypt is that its driver in Windows is an attack vector to gain escalated privileges.
There is nothing to suggest that any data encrypted is in danger.
That being said, you should use VeraCrypt for Windows, since it's still being actively maintained.
I am not aware of any security technology which can stop an attacker who has broken the file system driver for the root file system. I am not sure what that kind of technology would even look like -- all the ideas I can think of are completely impractical.
It would look like what a lot of people here tend to hate. ...) checks that the OS kernel is signed by a trusted authority
- Bootloader (BIOS, EFI,
- The kernel checks that each module and system file has the correct signature before it is loaded
If the root filesystem driver is compromised, it can tamper with system files but because the signature won't match, the kernel will refuse them. And it can't patch the kernel either because it will be refused by the bootloader.
Samsung KNOX is a full stack implementation working from the bootloader to user applications. On PCs you can start with the UEFI secure boot. Unfortunately, all these solutions tend to impose some root of trust and often don't go well with opensource communities.
Wasn't it just in January when the Linux GHOST bug was found? If memory serves it impacted something like 15 or so years worth of Linux versions and allowed code execution. I think the better stance to take is that regardless of how open or closed the source code is, complex systems should never be considered secure. As seen by other flaws in open source systems (Heartbleed anyone?) the number of "eyes" checking the code doesn't really matter. The fact is that both closed source and open source software faults in that they don't get enough security auditing done. That's because it's insanely time consuming. The biggest difference between open sourced and closed source software is that generally closed source companies have more resources than open source source groups and thus should be expected to do security auditing once their software reaches a certain adoption rate.
Your response indicates confusion on several levels.
First of all, the point of encryption is that even if an evildoer (E.D.) were to intercept your data, he wouldn't be able to read it unless he had the key. So even if E.D. acquired root access to your Windows computer, he couldn't read your encrypted data.
Most people use encryption to prevent somebody from stealing their phone/laptop and copying the data off of the drive. This vulnerability in TrueCrypt does not aid the E.D. if they stole your physical drive, since they still need the key to load the encrypted drive. It also doesn't help the E.D. from getting your encrypted data off of an Internet server.
So what's this vulnerability about? If the E.D. already has access to your computer, but doesn't have admin access, but does notice TrueCrypt is already installed, he can use it to gain admin access from your privilege-restricted user account. However, most Windows users run with admin privileges constantly anyway, so this is not problematic for them for the most part. It's a security concern, however, if you're a sysadmin and you have users on your server that use TrueCrypt. But the data encrypted thereby is totally safe (except for the usual attack vectors: keyloggers, brute force password breaking, etc.).