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.
This is a Windows-only issue -- so nothing to see here, move along.
The VeraCrypt commits fixing the 2 "undisclosed" vulnerabilities:
https://github.com/veracrypt/V...
https://github.com/veracrypt/V...
TrueCrypt encrypted volumes remain no more or less vulnerable because of this. But, you still should not be using TrueCrypt.
Then what should I be using, O wise one?
any of the forks
VeraCrypt
and
CipherShed
are examples
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
It's in the driver which operates at an elevated permission level.
That's a flaw in the windows security architecture. Since they removed the ability to selectively elevate permissions on threads and processes with the 2008R2 codebase, you have to run the entire process at the highest permission level required instead of selectively elevating permissions temporarily.
Stupid.
Windows can't necessarily account for all potential flaws in software. Nor can any Kernel.
That is true, but its inherently flawed security architecture makes even the slightest flaw a major security problem, hence the overwhelmingly large number of exploits in windows, and why I continue to maintain that windows is wholly unsuited for any purpose.
The cesspool just got a check and balance.
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.