Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Encryption Bug Privacy Software

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.
This discussion has been archived. No new comments can be posted.

Newly Found TrueCrypt Flaw Allows Full System Compromise

Comments Filter:
  • Veracrypt (Score:5, Informative)

    by Anonymous Coward on Tuesday September 29, 2015 @01:24PM (#50620835)

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

    Time to update.

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

      by mlw4428 ( 1029576 ) on Tuesday September 29, 2015 @01:27PM (#50620857)
      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: (Score:1, Informative)

        by Gr8Apes ( 679165 )

        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

        • by kmoser ( 1469707 )

          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.

      • 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? (Score:5, Insightful)

      by Zardus ( 464755 ) <yans@yancomm.net> on Tuesday September 29, 2015 @01:30PM (#50620875) Homepage Journal

      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.

      • by cdrudge ( 68377 )

        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.

    • 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.
    • by amorsen ( 7485 )

      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)

        by GuB-42 ( 2483988 ) on Tuesday September 29, 2015 @02:49PM (#50621443)

        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.

    • 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.
  • But I still want to see how high you can build the wall.

  • 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?
  • by Anonymous Coward on Tuesday September 29, 2015 @01:31PM (#50620891)

    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)

    by Lirodon ( 2847623 ) on Tuesday September 29, 2015 @01:33PM (#50620909)
    This is why it was discontinued. Stop using TrueCrypt.
    • by 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.

    • by 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 serv

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

      • by lgw ( 121541 )

        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)

    by Anonymous Coward on Tuesday September 29, 2015 @01:33PM (#50620917)

    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.

    • 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?

    • by cfalcon ( 779563 )

      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

  • by TsuruchiBrian ( 2731979 ) on Tuesday September 29, 2015 @01:38PM (#50620961)

    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?

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

      • by lgw ( 121541 )

        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.

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

    • by SeaFox ( 739806 )

      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.

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

  • Really, this just increases "plausable deniability"

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

  • by LichtSpektren ( 4201985 ) on Tuesday September 29, 2015 @02:36PM (#50621365)
    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.
  • 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

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

  • Not a problem with the encryption, but sounds like a way to elevate user privileges on the sly.
  • 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.

Little known fact about Middle Earth: The Hobbits had a very sophisticated computer network! It was a Tolkien Ring...

Working...