Newly Found TrueCrypt Flaw Allows Full System Compromise 106
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 (Score:5, Informative)
VeraCrypt 1.15 that was released Saturday, contains patches for the two vulnerabilities
Time to update.
Clarification? (Score:1)
Is the bug in TrueCrypt, or is the bug in Windows? It seems to me that Windows should be able to stop a limited user from gaining administrative privileges, regardless of the software that is being used to attempt it.
Why is it the responsibility of TrueCrypt to prevent user rights elevation in Windows? It thought that was Windows' responsibility.
Re:Clarification? (Score:5, Informative)
Re:Clarification? (Score:5, Insightful)
Re: (Score:1)
Re: (Score:2)
You can't get away from complexity. What you can do is organize the system around a simplified choke point with the complex parts (even hardware like NICs) mapped into unprivileged VMs. In this case, Qubes OS utilizes a type 1 hypervisor as if it were a microkernel... https:www.qubes-os.org [qubes-os.org]
And yes, the proportion of eyes to LOC does seem to matter for Xen (it runs AWS and EC2) and this is why it was chosen for Qubes desktop.
Re: (Score:2)
And this is of course obvious from an anecdotal standpoint given the vast majority of viruses and bot-ted Windows systems out there over the last decade.
The anecdotal standpoint just observes that 90%+ of all systems are running windows; including a vast majority run by "consumers" and a "small business" with zero or even negative security awareness.
Re: (Score:2)
Re: (Score:2)
True but it's always safer to run security-sensitive software on a non-Windows system.
This is empirically provable because Windows is closed source...
You've got your empirical and theoretical mixed up. In theory, you can prove an open source system has no bugs. Empirically, bugs continue to be found in both open and closed source software.
Re: (Score:1, Informative)
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 t
Re: (Score:1)
Re: (Score:1)
Re: (Score:1)
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.
Ralph Nader would say it's unsafe at any clock speed.
Re: (Score:2)
The only solution to this aspect of privilege escalation is to not embed drivers in the kernel.
(But: "Oh-noes, there's a 10% performance loss", says the Ruby programmer!:)
Re: (Score:2)
It would be a shit lot more than 10% for something that does direct disk I/O man.
Re:Clarification? (Score:5, Insightful)
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.
Re: (Score:1)
I really wish there was a way to make those URL thingies clickable. You could even just make microkernel [wikipedia.org] and monolithic [wikipedia.org] take you straight there so you wouldn't have to break the flow of the sentence with the URL in parenthesis.
Re: (Score:2)
Fair enough, but then at least still hyperlink them and don't leave them as plain text.
Re: (Score:3)
Re: (Score:2)
Even if Windows was a microkernel and TrueCrypt was running without privileges and so on, I think that many users use TrueCrypt to encrypt their system partition. Once TrueCrypt is compromised, the attacker can replace e.g. SVCHOST.EXE or another critical Windows system file with anything they want. 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 ide
Re:Clarification? (Score:4, Interesting)
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.
Re: (Score:2)
An open source example would be Anti Evil Maid [blogspot.com] which is a part of Qubes OS.
Re: (Score:2)
You are chasing ghosts. You cannot hide. (Score:2)
But I still want to see how high you can build the wall.
Auditing Failure? What? (Score:2)
In case anyone is wondering (Score:5, Informative)
The VeraCrypt commits fixing the 2 "undisclosed" vulnerabilities:
https://github.com/veracrypt/V... [github.com]
https://github.com/veracrypt/V... [github.com]
See? (Score:5, Interesting)
Re: (Score:1)
This is why it was discontinued. Stop using TrueCrypt.
Cart before the horse? TrueCrypt is vulnerable because it was discontinued. If it had been allowed to continue, then these same flaws would be patched in it, too. Not to say that people shouldn't move to VeraCrypt, but... the only reason VeraCrypt patched the vulnerabilities is because it IS actively maintained.
Re: (Score:1)
It's highly unlikely the two things are related. There was a bootloader keylogger for Truecrypt published in 2600 magazine. Coldboot attacks and tampering with physical access to devices are not new threat vectors. This threat is of higher concern to server administrators than it is to Truecrypt's primary demographic: professional criminals and paranoids who don't want to screw around with GPG.
Either of these two groups already knows not to leave a computer unsupervised and not to use their laptop as a serv
Re: (Score:1)
>professional criminals and paranoids
Sure.
Nobody else could have anything to 'hide', no ?
(I regularly carry other people's personal data around on removable media and I rather want to lose one with everything in a Truecrypt container than everything plain readable. Of course this is probably not three-letter-agency-proof, but most people/entities will have a rather hard time getting the data.)
Re: (Score:2)
Yes, this literally means keeping a laptop by your side 24/7 from date of purchase in cash until it's retirement from service... IE: In to the bathroom, in to restaraunts, in your carry on luggage, never leaving it in a hotel room, etc.
Bruce Schneier has commented in the past that the most safe approach is buying a laptop from a random brick-and-mortar store, prepping it to be secure, then keeping it locked in a vault whenever you're not physically holding it. Not perfect but security never is - make sure you choose a good safe though.
Important Details (Score:5, Insightful)
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.
Re: (Score:2)
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?
Re:Important Details (Score:5, Informative)
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 [wikipedia.org]
and
CipherShed [wikipedia.org]
are examples
Re: (Score:2)
No, but they are based on the audited code.
Re: (Score:2)
On Linux there is also tcplay (in Debian and others) and Linux cryptsetup also understands truecrypt formats.
Re: (Score:2)
But which one is better?
Re: (Score:1)
ROT13 and Notepad
Re: (Score:2)
Well, more properly, it means that if you have installed Truecrypt on your machine, and your son launches Truecrypt, he can:
1)- Create a Truecrypt volume of his own.
2)- Mount it.
3)- Now that it is mounted, he can, via the exploit, gain admin. [that is what is claimed, at least]
4)- Now that he has admin, he can do whatever- install a keylogger, whatever.
He doesn't get to decrypt some other drive (unless he keylogs the password) and you had to trust him enough to give him a user account on your box. This
This is why I still use ScramDisk (Score:2)
and Windows 95
despite professional code audits (Score:5, Insightful)
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?
Re: (Score:2)
Hardly. I think the distinction here is that someone paid someone money to look at a code and tell us if it was safe. They said yes, turns out the answer is no.
They are exactly right in that professional audits can miss serious bugs, and with that concept we can now not guarantee that even after Google apparently has been looking at the code that it's all safe.
Re: (Score:2)
thegarbz said
someone paid someone money to look at a code and tell us if it was safe. They said yes, turns out the answer is no.
The audit team said
Overall, the source code for both the bootloader and the Windows kernel driver did not meet expected standards for
secure code
What part of that sounded like "safe" to you? The report [opencryptoaudit.org] is easy enough to read.
Re: (Score:2)
Hardly. I think the distinction here is that someone paid someone money to look at a code and tell us if it was safe. They said yes, turns out the answer is no.
Finding software that is free of defects is like finding a unicorn.
They are exactly right in that professional audits can miss serious bugs, and with that concept we can now not guarantee that even after Google apparently has been looking at the code that it's all safe.
You can't guarantee that *any* code is safe.
In fact it is probably safer now that this bug has been found than before it was found.
There are bugs in nearly every piece of software. Finding a bug isn't necessarily an indication of poor quality relative to other software, but it is usually an indication that that software will be better shortly.
Re: (Score:3)
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?
Google locating a single bug isn't the same as a comprehensive examination of the entire codebase. The problem here is supposedly someone else has done that entire review and not found an issue someone else located with what was likely testing on only a small portion of the "reviewed" code (the driver). This calls into question the quality of the rest of the review.
Re: (Score:2)
Google locating a single bug isn't the same as a comprehensive examination of the entire codebase.
I think you are pretty much guaranteed that any examination of a large codebase will not be comprehensive.
The problem here is supposedly someone else has done that entire review and not found an issue someone else located with what was likely testing on only a small portion of the "reviewed" code (the driver). This calls into question the quality of the rest of the review.
Can you call something into question if it is already in question?
That's like saying finding a corrupt politician calls into question the integrity of the political system.
Feature! (Score:2)
Really, this just increases "plausable deniability"
Yet another reason... (Score:1)
Just another reason why I'm sooooo glad I moved off Windows after I retired.. I spent over 20 years picking up after Windows (and its users) and when I quit that grind, I decided I was done with MS products.. Haven't had a need for Windows since about 2011...
Reiterate: data encrypted with TrueCrypt is safe (Score:5, Informative)
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.
Re: (Score:3)
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 physic
Re: (Score:2)
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.).
Well except that gaining admin privileges probably means he gets to install a key logger, so the next time anyone types a password the container is compromised. True, as such the intruder could use any other non-Truecrypt related bug to do it. But it's not good that Truecrypt opens that door. Then again, if you're really worried about what other users might do to your machine physically or logically you'd probably keep it as a single-user system you keep to yourself. In that use case, this vulnerability doe
Re: (Score:2)
Right, but it's still a problem where a Windows user can mess with that Windows box. That's an attack vector, but it's not the damned kingdom.
Why this doesn't matter and why I'm not upgrading. (Score:1)
Don't think I'm upgrading to Veracrypt just yet.
For one, if I'm only upgrading for the local security vulnerabilities. Aren't there likely at least a few dozen other Windows or driver vulnerabilities that would allow an attacker to get administrator from an unprivileged account? Isn't trying to fix local security in Windows like trying to plug swiss cheese?
When I see stuff like this in the changelog I start to get worried, REAL worried:
1.13 (August 9th, 2015):
Windows:
Solve TOR c
Re: (Score:1)
Just look at the shenanigans they're pulling with that idiotic PIM (personal iteration modifier). It seems they don't understand crypto and how important it is to have 1) strong passwords 2) simple usability.
Not encryption flaw (Score:2)
What about portable? (Score:2)
I always liked portable edition because I would prefer not to have someone point to an installed program as proof I have something to hide. Portable TrueCrypt didn't require admin privileges so there wouldn't be a potential privilege escalation issue. The ability to run as an unprivileged user was the biggest thing I missed when I switched over to bitlocker.
Re:Can't understand the obsession with TrueCrypt (Score:4, Informative)
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.
Re: Can't understand the obsession with TrueCrypt (Score:2)
"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."
For Windows, you mean like https://github.com/t-d-k/Libre... [github.com] (previously http://sourceforge.net/project... [sourceforge.net])
LibreCrypt & TrueCrypt (Score:1)