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.

Comments

Veracrypt

[Anonymous Coward]

VeraCrypt 1.15 that was released Saturday, contains patches for the two vulnerabilities

Time to update.

Clarification?

[EmagGeek]

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?

[mlw4428]

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.

Re:Clarification?

[Zardus]

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:Clarification?

[Anonymous Coward]

I think it's because TrueCrypt runs as a driver and hence prileged itself. So if it mishandles certain things it can let escalation through....

Just speculating though

Re:Clarification?

[Anonymous Coward]

Because TC probably has a system level driver.

Re:Clarification?

[The MAZZTer]

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.

Re:Clarification?

[Anonymous Coward]

TrueCrypt is a driver, not just some regular software running in user mode.

Re:Clarification?

[cdrudge]

I really wish there was a way to make those URL thingies clickable. You could even just make microkernel and monolithic take you straight there so you wouldn't have to break the flow of the sentence with the URL in parenthesis.

Re:Clarification?

[amorsen]

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 ideas I can think of are completely impractical.

Re:Clarification?

[Anonymous Coward]

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. Since it's impossible to prove a negative, the number of flaws in a closed-source system can never be determined and thereby always must be considered more insecure. Even if we subtract out the effect of low-quality coding/design inherent in the Microsoft ecosphere.

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.

Re:Clarification?

[Anonymous Coward]

I like the original format better. Call me crazy. I can read the whole link. It really doesn't break the flow. Breaking the flow is me having to hover or click the link to see what the link is.

Re:Clarification?

[Cley Faye]

Beyond other replies about a driver having privilege to do whatever it want (for obvious reasons), the fact that TrueCrypt needed a driver in the first place is part of the issue. It would be nice to have an interface to provide custom filesystems that could run in userspace. On windows, of course; that exists on other OS.

Re:Clarification?

[Gr8Apes]

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.

Re:Clarification?

[Anonymous Coward]

So you implement a trusted computing module that has very simplified interfaces and only knows how to do high-privilege operations, after sufficiently-authenticating the user and filtering the request. Not rocket surgery.

Re:Clarification?

[GuB-42]

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.
- Bootloader (BIOS, EFI, ...) checks that the OS kernel is signed by a trusted authority
- 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:Clarification?

[mlw4428]

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.

Re:Clarification?

[vux984]

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: Clarification?

[Anonymous Coward]

This is the dumbest comment here. Thread level security has nothing to do with this truecrypt flaw.

Re:Clarification?

[Anonymous Coward]

How dare you walk all over Anonymous Coward's righteous indignation and smug superiority by introducing rational discussion and pesky things like 'facts'? "Everybody I know who runs Windows has hundreds of viruses and reboots daily" is much more fun.

Re:Clarification?

[Anonymous Coward]

Or, you know, the comment system could detect that there is a link in the text and make it clickable, instead of requiring the poster to resort to writing their own fucking HTML. Slashdot is the only site I visit that expects people to write HTML, and it's fucking stupid.

Re:Clarification?

[Mikkeles]

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: Clarification?

[Anonymous Coward]

And how long before it was patched after the discovery? How bout windows 20 year old exploirs... still unpatched?

Re:Clarification?

[Anonymous Coward]

> As seen by other flaws in open source systems (Heartbleed anyone?) the number of "eyes" checking the code doesn't really matter.

Is it your intention to be misleading and to promote closed source software? Because it looks like you just found a few of the rare examples of major security flaws in open source while ignoring the impossible to ignore number of closed source ones. If you have a few pages on one pile supporting your claim and ignore the hoarder's sized paper mountain of shit stacked up to the ceiling and filling the rest of the room pointing the other way, why would you make the claim they're on equal footing? The evidence over many years shows the exact opposite.

Re:Clarification?

[Anonymous Coward]

1. The key phrase is "adoption rate". Closed source only has the resources of the company, Open Source has the entire world of developers as a potential resource. So NO, closed source companies don't necessarily have more resources. Since, quite frankly, Open Source is the infrastructure of the modern world, there are also many stakeholder companies affected, even for-profit ones. So the development resources at *one* company also doesn't necessarily have more resources than the development resources of *many* companies across the world.

2. Whether Open or Closed source, it's more dependent on the relevant decision-makers whether or not security auditing will occur. Both Open and Closed source have examples of both strong security practices and weak practices.

3. The only thing that breaks the tie is that Open source *can* be audited and fixed if people have enough interest, even if unlikely. With Closed source, if the company actively embraces weak security practices, it's usually *impossible* to fix this. It's not merely an issue of lack of source code to modify, it's also an issue that *legally* you're not even *allowed* to modify the code even if you had the source or could reverse engineer it.

Re:Clarification?

[Gr8Apes]

That's less trivial than you imply, and requires an extra hop or three. Then again, you likely won't be elevating processes 1000 times a second so from a performance standpoint you should be ok. And it still would be simpler if you could just execute an elevated authenticated process when you needed to from a low-privilege process. Instead you have to devise something to side-step the security infrastructure.

Re:Clarification?

[cfalcon]

It would be a shit lot more than 10% for something that does direct disk I/O man.

Re:Clarification?

[Anonymous Coward]

does linux allow running driver code without elevated permissions? i was under the impression that driver code effectively ran as root, so a rogue driver could manipulate any memory address in the system.

Re: Clarification?

[Anonymous Coward]

You could do a combination of both. Show the full link, but make it clickable.

Re:Clarification?

[Anonymous Coward]

Desktop PCs do not make up 90% of 'systems', whatever you intended by that word. Your made up stats are dead on arrival.

Re:Clarification?

[hairyfeet]

Riiiight, I'll just leave these here then.

Re:Clarification?

[Anonymous Coward]

You really think closed source companies do that level of auditing? There's barely enough time to write a solid spec before compiling/shipping, never mind unit tests. Proprietary code = do whatever it takes to get it out the door to generate revenue asap. Period.

But the heart of the question is why would anyone run sensitive software like Truecrypt on a system like Windows? Given the vast number of keylogged Windows machines out there's the real danger of developing a false sense of security by the user.

Bottom line is use *nix in any form. Leave Windows to the gamers.

Re:Clarification?

[piojo]

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:Clarification?

[Burz]

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

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:Clarification?

[Burz]

An open source example would be Anti Evil Maid which is a part of Qubes OS.

Re:Clarification?

[Anonymous Coward]

Yeah, because secure boot of UEFI is the panacea of security and cannot be broken right? /s

Re:Clarification?

[Gr8Apes]

Linux does have user land drivers, so yes, it does allow running without elevated permissions. But, this answer comes with caveats, as obviously not all drivers can run in user land. However, drivers are but a small set of the exposure in windows. In my case I was creating an orange book compatible set of web services, and windows was one designated platform. Considering the requirements were met I guess that project was a success. However, I wound up working against the OS at almost every level to get there because the security architecture is flawed from the bottom up. Had we done the project with the OS 1 revision earlier it would have been almost like the linux implementation in approach, because you could still manipulate security tokens by spawning processes and substituting an authenticated user token. In 2008R2, all of those APIs were no-op, with no explanation nor documentation for many months until people like me had finished digging through the crap MS gave us. Speaking of, the MSDN site is another large pile of almost wholly useless crap at this point. I have come to the conclusion it only exists to show people how much more useful other sites such as SO are, which speaks for itself.

Re:Clarification?

[cdrudge]

Fair enough, but then at least still hyperlink them and don't leave them as plain text.

Re:Clarification?

[Anonymous Coward]

And what percentage of Linux systems are run by "consumers" with zero or even negative security awareness? Android anyone?

Re:Clarification?

[kmoser]

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.

Windows only.

[Anonymous Coward]

This is a Windows-only issue -- so nothing to see here, move along.

You are chasing ghosts. You cannot hide.

[fustakrakich]

But I still want to see how high you can build the wall.

Auditing Failure? What?

[mlw4428]

Am I wrong in the belief that the focus of the audit was to find intentional backdoors or cryptographic weaknesses, not necessarily exploitable bugs in the software?

Re:Auditing Failure? What?

[Anonymous Coward]

The iSec audit was also trying to find potential glaring vulnerabilities, but it's easy to miss bugs in Windows driver code...

In case anyone is wondering

[Anonymous Coward]

The VeraCrypt commits fixing the 2 "undisclosed" vulnerabilities:
https://github.com/veracrypt/V...
https://github.com/veracrypt/V...

still encrypted?

[Anonymous Coward]

while bad it doesn't sound like it allows for breaking the encryption so at least the data remains secure.

See?

[Lirodon]

This is why it was discontinued. Stop using TrueCrypt.

Re:See?

[Anonymous Coward]

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:See?

[Anonymous Coward]

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 server for other users.
(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.)

Re:See?

[Anonymous Coward]

>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:See?

[lgw]

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.

Re:See?

[Anonymous Coward]

I provided for this category with "paranoids".

Ever heard the quote: "Just because you're paranoid doesn't mean they aren't out to get you."?

I consider paranoia to be a virtue and think most people float around in blissful ignorance. You're talking to a guy who takes his laptop to the urinal with him so he can leave his backpack unattended and won't drink from an unsealed beverage container after it leaves his supervision.

Important Details

[Anonymous Coward]

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:Important Details

[Spy Handler]

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

[Anonymous Coward]

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

Except they did look at this exact driver code and it was more than just a crypto audit.

Re:Important Details

[lister king of smeg]

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

Re:Important Details

[Anonymous Coward]

ROT13 and Notepad

Re:Important Details

[Anonymous Coward]

any of the forks
VeraCrypt
and
CipherShed
are examples

None of which have recieved audits, let along one as strong as what TC got.

Re:Important Details

[Anonymous Coward]

Another item is that someone has to be running as a user on the Windows system. This isn't a remote root hole. It isn't trivial, but it is something that has a relatively limited scope.

It does drive a point home that sandboxing can leave one vulnerable, because even with a sandbox running as a limited part of a user context, a hole like this can give a process free reign of the system, so the best defense against things like this would be virtualization. This is why Windows Server 2016 is having Docker containers in their own Hyper-V VMs with a "mini" Windows OS.

Re:Important Details

[cfalcon]

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 is nothing he couldn't have accomplished with unlimited physical access to the machine, and not a flaw with truecrypt's disk safety, but it's still an interesting flaw.

Re:Important Details

[cfalcon]

No, but they are based on the audited code.

Re:Important Details

[Anonymous Coward]

I agree that this was the reason the audit didn't find it, but that only shows that the audit was incompetent, since these kind of bugs are exactly the kind of bugs that people using security software should be worried about. In this particular case, the vulnerabilities could have been used, if exploited effectively, to snoop the password and keyfiles of a TrueCrypt volume when it is accessed by the user.

Re:Important Details

[Burz]

On Linux there is also tcplay (in Debian and others) and Linux cryptsetup also understands truecrypt formats.

Re:Important Details

[antdude]

But which one is better?

does it matter? Does it break the encryption?

[Anonymous Coward]

Does this bug allow anyone to bypass the encryption? It doesn't seem to do that. without a password/Key your still locked out. The vulnerability in truecrypt wasn't the software it was the software designers.

This is why I still use ScramDisk

[Spy Handler]

and Windows 95

despite professional code audits

[TsuruchiBrian]

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:despite professional code audits

[thegarbz]

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:despite professional code audits

[SeaFox]

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:despite professional code audits

[Anonymous Coward]

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?

"professional security audits" are incompetent is one way of reading the context of the post, but an alternative is "bugs will probably still remain even after multiple security audits [professional or otherwise]."

At least that's how I read it.

But don't let that stop you from being a douchebag.

Re:despite professional code audits

[lgw]

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 is easy enough to read.

Re: despite professional code audits

[Anonymous Coward]

Take your pesky facts elsewhere. AC wants to troll TrueCrypt and everyone connected with it, and you're ruining it for him.

Re:despite professional code audits

[TsuruchiBrian]

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.

Re:despite professional code audits

[TsuruchiBrian]

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.

Windows only

[Anonymous Coward]

So, this is Windows only behavior. Even then, not your biggest privacy threat if you're running Windows >=7.

Well it all makes sense now.

[Anonymous Coward]

Looks like someone found the NSA backdoor.

Feature!

[AntEater]

Really, this just increases "plausable deniability"

Re:Can't understand the obsession with TrueCrypt

[unrtst]

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.

Yet another reason...

[LVSlushdat]

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

Re:Linux?

[Anonymous Coward]

I am surprised that you can't be bothered to skim through the article to understand that this is a Windows-only problem. Try to be more diligent next time lest you make a fool of yourself in public again.

Reiterate: data encrypted with TrueCrypt is safe

[LichtSpektren]

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.

VeraCrypt is affected, too!

[Anonymous Coward]

http://www.openwall.com/lists/...

Veracrypt says not intentional backdoors

[Anonymous Coward]

[Veracrypt's] Idrassi said he agrees with Forshaw that the vulnerabilities were not intentionally introduced and that they are the types of flaws that could have been known and exploited for years. --Kaspersky threatpost

But I can't find a statement by Forshaw that he thinks it wasn't intentional, only this tweet:

To clarify my last tweet, not saying the bugs were intentionally added.

Re:Reiterate: data encrypted with TrueCrypt is saf

[Anonymous Coward]

How is the data safe, when the system hosting the data gets pwnzed with full privilege?

Re:Reiterate: data encrypted with TrueCrypt is saf

[LichtSpektren]

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.).

Conspiracy

[Anonymous Coward]

The NSA has been unsuccessful in cracking TrueCrypt partitions so they need to convince people to switch to VeraCrypt, which they can access. Just like Tor exit nodes need to be populated with criminals so the intelligence officers are more difficult to identify.

Re:Conspiracy

[Anonymous Coward]

The NSA has been unsuccessful in cracking TrueCrypt partitions so they need to convince people to switch to VeraCrypt, which they can access.

Such claims need to be supported with evidence of their truthfulness, not pretending they are true because you said it and that it is impossible to disprove. I presume you prefer a world of chaos since that is the result of throwing unfounded claims around as if they were facts.

Re:Linux?

[Anonymous Coward]

Oh yeah, you sure put that Anonymous Coward in his or her place...surely they'll think twice before dirtying the name: Anonymous Coward.

Idiot.

Why this doesn't matter and why I'm not upgrading.

[beermang]

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 crashing when run from a VeraCrypt volume.

How does this even happen? What about all the other applications and games that I play? What if Veracrypt breaks them? Also reading about people having crashes when dismounting volumes and etc.

Someone try to convince me otherwise, but I think I'm just going to keep truecrypt and hope maybe someone releases a truecrypt with only those vulnerabilities patched as the encryption seems "good enough".

Plus I'm running an encrypted system drive which I assume I'll have to decrypt and re-encrypt with veracrypt. The fact they had to add truecrypt container support later also makes me wonder how much this is really based off of truecrypt and what all they changed.

Seems strange that something based on truecrypt can't even mount truecrypt volumes until later releases, and also I'm assuming still no support for truecrypt system volumes.

Not encryption flaw

[seven of five]

Not a problem with the encryption, but sounds like a way to elevate user privileges on the sly.

Re:Linux?

[Anonymous Coward]

TrueCrypt runs on a "computer"?

What about portable?

[ancientt]

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

[buchanmilne]

"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... (previously http://sourceforge.net/project...)

wrong wrong WRONG

[Anonymous Coward]

"but they do show that despite professional code audits, serious bugs can remain undiscovered"

The code audit was for intentional backdoors in the encryption, this is the program gaining OS privileges, nothing more.

Goddamn buzzfeed, I mean slashdot, stop with the clickbait headlines and FUD articles.

Re:Why this doesn't matter and why I'm not upgradi

[Anonymous Coward]

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.

Re:Reiterate: data encrypted with TrueCrypt is saf

[Kjella]

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 does nothing.

Re:Reiterate: data encrypted with TrueCrypt is saf

[cfalcon]

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.

Re:Reiterate: data encrypted with TrueCrypt is saf

[Anonymous Coward]

I recall at the time that Truecrypt announced it was ceasing development the speculation that they shut down rather than comply with putting in a back door (a la Lavabit). Given that, and the fact that Veracrypt hasn't received such an in-depth audit to my knowledge, I'm not convinced ditching the final version of Truecrypt (which did pass an audit) for Veracrypt is actually prudent.

There is the Truecrypt flaw in the article, but I use Linux anyway. Could there be another flaw? Sure, but the same is true of Veracrypt, and with Veracrypt there is the back-door concern.

So full disk encryption is still safe...

[Anonymous Coward]

If you are the only person that uses your machine and you run full disk encryption which requires you to put in a password to boot the box then there's no elevation of rights because you're the only person that can log on

Re:So full disk encryption is still safe...

[Anonymous Coward]

The problem is with Enterprise laptops where the machine is locked down without admin privileges to avoid tampering and modification of company-issued-laptops.

On Windows

[Anonymous Coward]

wonder why there is no mention of that in the title or blurb?

Re:Can't understand the obsession with TrueCrypt

[Anonymous Coward]

Because people want things that don't fucking suck. Get Linus' dick out of your ass.

LibreCrypt & TrueCrypt

[kevlar_rat]

True, but you should be aware that by a surprising coincidence a very similar bug has been found in LibreCrypt at the same time as this TrueCrypt bug.