Slashdot Mirror

← Back to Stories (view on slashdot.org)

Newly Found TrueCrypt Flaw Allows Full System Compromise

Posted by timothy on from the so-maybe-move-on dept.

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.

57 of 106 comments (clear)

  1. Veracrypt by Anonymous Coward · · Score: 5, Informative

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

    Time to update.

  2. Clarification? by EmagGeek · · 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.

    1. Re:Clarification? by mlw4428 · · Score: 5, Informative

      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.

    2. Re:Clarification? by Zardus · · Score: 4, 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.

      --
      You can mod your friends, you can mod your nose, but you can't mod your friend's nose.
    3. Re:Clarification? by The+MAZZTer · · Score: 2

      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.

    4. Re:Clarification? by amorsen · · Score: 1

      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.

      --
      Finally! A year of moderation! Ready for 2019?
    5. Re:Clarification? by Cley+Faye · · Score: 1

      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.

    6. Re:Clarification? by Gr8Apes · · 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 to maintain that windows is wholly unsuited for any purpose.

      --
      The cesspool just got a check and balance.
    7. Re:Clarification? by GuB-42 · · Score: 3, 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.
      - 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.

    8. Re:Clarification? by mlw4428 · · Score: 4, Insightful

      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.

    9. Re:Clarification? by vux984 · · Score: 1

      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.

    10. Re:Clarification? by Anonymous Coward · · Score: 1

      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.

    11. Re:Clarification? by Mikkeles · · Score: 1

      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!:)

      --
      Great minds think alike; fools seldom differ.
    12. Re:Clarification? by Gr8Apes · · Score: 1

      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.

      --
      The cesspool just got a check and balance.
    13. Re:Clarification? by cfalcon · · Score: 1

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

    14. Re:Clarification? by hairyfeet · · Score: 1

      Riiiight, I'll just leave these here then.

      --
      ACs don't waste your time replying, your posts are never seen by me.
    15. Re:Clarification? by piojo · · Score: 1

      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.

      --
      A cat can't teach a dog to bark.
    16. Re:Clarification? by Burz · · Score: 1

      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.

    17. Re:Clarification? by Burz · · Score: 1

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

    18. Re:Clarification? by Gr8Apes · · Score: 1

      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.

      --
      The cesspool just got a check and balance.
    19. Re:Clarification? by cdrudge · · Score: 1

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

    20. Re:Clarification? by kmoser · · 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.

  3. You are chasing ghosts. You cannot hide. by fustakrakich · · Score: 2

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

    --
    “He’s not deformed, he’s just drunk!”
  4. Auditing Failure? What? by mlw4428 · · Score: 1

    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?

  5. In case anyone is wondering by Anonymous Coward · · Score: 5, Informative

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

  6. See? by Lirodon · · Score: 4, Interesting

    This is why it was discontinued. Stop using TrueCrypt.

    1. Re:See? by Anonymous Coward · · 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.

    2. Re:See? by Anonymous Coward · · 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 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.)

    3. Re:See? by Anonymous Coward · · 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.)

    4. Re:See? by lgw · · Score: 1

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
  7. Important Details by Anonymous Coward · · 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.

    1. Re:Important Details by Spy+Handler · · Score: 1

      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?

    2. Re:Important Details by lister+king+of+smeg · · Score: 4, 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
      and
      CipherShed
      are examples

      --
      ---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
    3. Re:Important Details by Anonymous Coward · · Score: 1

      ROT13 and Notepad

    4. Re:Important Details by cfalcon · · Score: 1

      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.

    5. Re:Important Details by cfalcon · · Score: 1

      No, but they are based on the audited code.

    6. Re:Important Details by Burz · · Score: 1

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

    7. Re:Important Details by antdude · · Score: 1

      But which one is better?

      --
      Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  8. This is why I still use ScramDisk by Spy+Handler · · Score: 1

    and Windows 95

  9. despite professional code audits by TsuruchiBrian · · 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?

    1. Re:despite professional code audits by thegarbz · · Score: 1

      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.

    2. Re:despite professional code audits by SeaFox · · Score: 2

      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.

    3. Re:despite professional code audits by lgw · · Score: 1

      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.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    4. Re:despite professional code audits by TsuruchiBrian · · Score: 1

      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.

    5. Re:despite professional code audits by TsuruchiBrian · · Score: 1

      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.

  10. Feature! by AntEater · · Score: 1

    Really, this just increases "plausable deniability"

    --
    Alex, I'll take keybindings not used by Emacs for $400....
  11. Re:Can't understand the obsession with TrueCrypt by unrtst · · Score: 3, 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.

  12. Reiterate: data encrypted with TrueCrypt is safe by LichtSpektren · · Score: 4, Informative

    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.

  13. Re:Reiterate: data encrypted with TrueCrypt is saf by LichtSpektren · · Score: 2

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

  14. Why this doesn't matter and why I'm not upgrading. by beermang · · 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 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.

  15. Not encryption flaw by seven+of+five · · Score: 1

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

  16. What about portable? by ancientt · · Score: 1

    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.

    --
    B) Eliminate all the stupid users. This is frowned upon by society.
  17. Re: Can't understand the obsession with TrueCrypt by buchanmilne · · Score: 1

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

  18. Re:Why this doesn't matter and why I'm not upgradi by Anonymous Coward · · 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.

  19. Re:Reiterate: data encrypted with TrueCrypt is saf by Kjella · · Score: 1

    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.

    --
    Live today, because you never know what tomorrow brings
  20. Re:Reiterate: data encrypted with TrueCrypt is saf by cfalcon · · Score: 1

    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.

  21. LibreCrypt & TrueCrypt by kevlar_rat · · Score: 1

    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.

    --
    Moderated Usenet