Slashdot Mirror


First Phase of TrueCrypt Audit Turns Up No Backdoors

msm1267 (2804139) writes "A initial audit of the popular open source encryption software TrueCrypt turned up fewer than a dozen vulnerabilities, none of which so far point toward a backdoor surreptitiously inserted into the codebase. A report on the first phase of the audit was released today (PDF) by iSEC Partners, which was contracted by the Open Crypto Audit Project (OCAP), a grassroots effort that not only conducted a successful fundraising effort to initiate the audit, but raised important questions about the integrity of the software.

The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver; architecture and code reviews were performed, as well as penetration tests including fuzzing interfaces, said Kenneth White, senior security engineer at Social & Scientific Systems. The second phase of the audit will look at whether the various encryption cipher suites, random number generators and critical key algorithms have been implemented correctly."

171 comments

  1. Wow by cold+fjord · · Score: 3, Informative
    --
    much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    1. Re:Wow by Anonymous Coward · · Score: 0, Interesting

      The same OpenBSD that shipped an OpenSSL version with the heartbleed bug? Hmmm...

    2. Re:Wow by Anonymous Coward · · Score: 1

      Difference between an Internal and External audit.

    3. Re:Wow by Anonymous Coward · · Score: 0, Interesting

      Didn't say or imply that, but they claim to be auditing the code they ship yet seem to have missed the massive bug in one of the major parts of the system when used as a server.

    4. Re:Wow by Anonymous Coward · · Score: 0, Interesting

      Ah, ok. It's just I've seen enough "LOL Theo wrote Heartbleed. I mean, OpenSSH, OpenSSL, what's the difference?"-like posts these few days and jumped to conclusions. Still, I don't see it painting them as liars.

      It took half a year for this first phase of audit of one package to complete - imagine how long would a single point release take with comprehensive audit of every package? They do find and fix bugs in 3rd party packages, but of course they can't catch every bug when they're limited by resources and time and stretched over every part of OS.

    5. Re:Wow by Anonymous Coward · · Score: 2, Interesting

      Oh, you mean they should be auditing everybody else's code too?

      Umm, yeah? Since that's what they claim to do:

      The process we follow to increase security is simply a comprehensive file-by-file analysis of every critical software component.

      http://www.openbsd.org/securit...

      Or are you going to claim that OpenSSL is not a critical software component?

    6. Re:Wow by Anonymous Coward · · Score: 0

      Wow, to think that when they "fail" it only makes them equal to everyone else.

    7. Re:Wow by Anonymous Coward · · Score: 0

      And bitcoin isn't a Ponzi scheme either....

    8. Re:Wow by Anonymous Coward · · Score: 0

      You did kinda imply that.

  2. To Crypt or Not To Crypt by Anonymous Coward · · Score: 0

    Think I honed a few TC segments in Olly a while back, but nothing serious. I'd much rather have a few bugs than intentional back-doors. Fix those severe bugs described in he audit release and you got yourself user for life, TC.

    1. Re:To Crypt or Not To Crypt by WaywardGeek · · Score: 2

      I use TrueCrypt. Not that it likely matters given all the other back-doors on my Lenovo Wintel laptop, but I use a passphrase from Hell, and I suspect even the NSA's biggest cracker would have trouble with it.

      Other than the backdoors in various places on this toxic waste dump of security, the biggest security threat to my passphrase from Hell is TrueCrypt itself. TrueCrypt by default does 100% useless password strengthening (key stretching or whatever it's called). It's strongest mode, which you have to select manually, is 2000 rounds of SHA-256. I can buy SHA256 boxes that do 1 Giga-hash/second per $10. Figure a government has a few million at least for such boxes, and go compute how strong your password needs to be, and it isn't pretty.

      I use my password and TrueCrypt to protect my data. Why didn't it occur to the TrueCrypt authors to protect my password? I mean, Bcrypt at least, come on...

      --
      Celebrate failure, and then learn from it - Nolan Bushnell
    2. Re:To Crypt or Not To Crypt by cbhacking · · Score: 2

      A good strong PBKDF2 is probably sufficient, but yeah, 2k rounds is pathetic. iPhones were doing better (admittedly, their passphrases tend to be very short) several years ago, and that's on a mobile CPU. Having a limit of 2k rounds doesn't even make sense, it's not like it's harder to code it for more rounds or something. The only real limit should probably be 0xFFFFFFFF rounds (assuming 32-bit ints) because why have a limit at all?

      --
      There's no place I could be, since I've found Serenity...
    3. Re:To Crypt or Not To Crypt by AmiMoJo · · Score: 3, Insightful

      You should use a passfile as well as a password. Makes it much harder for an attacker because something like a hardware keylogger or audio analysis to recover keystrokes can't see which file you selected. When it comes to breaking your key there is no way to know after the fact that a keyfile was used, so they will probably waste a large amount of time trying a dictionary attack on the password before even realizing that they need to also try any of the 100,000+ files on your computer as well. That is assuming you used a file on your computer, if it was on an external drive they didn't collect when they grabbed it they are screwed. Keep a few corrupt USB flash drives around just to make the wonder if they had it but broke it.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    4. Re:To Crypt or Not To Crypt by BitZtream · · Score: 3, Interesting

      I don't think you understand whats going on. PBKDF has absolutely nothing to do with 'protecting' your password. Its done because passwords suck ass for encryption keys.

      TrueCrypt is taking your password and turning it into something USEFUL as a key for encryption, not 'protecting it'.

      Standard passwords are pathetically low on entropy, a full twitter or SMS post is still not 256 bits of useful entropy, and its unlikely your passwords are anywhere near that. I admit I don't know your password, but if you're only using the standard character set, I can safely say its pathetically low on entropy. You need full binary keys generated from good random sources, but you'll never remember that, will you? Imaging trying to type it somewhere.

      What the hashing does is takes your password and contorts it into a larger key that is more useful than whatever pathetic string of text you throw at it. It does so in such a way that, like all hashing processes are supposed to, you can't go backwards because bits are discarded along the way.

      2000 rounds is pretty low, but thats only a tiny small part of the encryption/decryption process. And your password (as I understand true crypt) really just projects are larger private key, which is what is actually used for encryption. Its been a while since I've looked at or used TrueCrypt, so I may be wrong about that last particular bit.

      For a full description: http://en.wikipedia.org/wiki/P...

      I do write encryption software for a living. And again, its not about protecting your password or making it harder to guess, its about turning your crappy password into a useful encryption key, nothing more.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    5. Re:To Crypt or Not To Crypt by heypete · · Score: 1

      Keyfiles don't work for system encryption with TrueCrypt: you can only use passwords (or passphrases, of course).

    6. Re:To Crypt or Not To Crypt by WaywardGeek · · Score: 2

      I don't do this for a living, but I'm not totally ignorant about this topic. TrueCrypt does a poor job strengthening passwords. TC's users would be far better protected if TC ran something even as lame as PBKDF2 for a full second, with rounds somewhere in the 100's of thousands or millions. Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it. This is why I say that the user's password is at risk due to TC, not just the data TC encrypts.

      To give TC some credit, OpenSSL has the same lame password strengthening as TC, putting id_rsa passphrases at risk, in addition to the user's private key. So, there seems to be plenty of lameness to go around. I hear that a Bcrypt option is in the bleeding edge version of OpenSSL. I which they'd push out that patch along with the Heartbleed fix.

      --
      Celebrate failure, and then learn from it - Nolan Bushnell
    7. Re:To Crypt or Not To Crypt by AmiMoJo · · Score: 1, Insightful

      True, but if you are that paranoid you can use a VM with the hardfile in an encrypted container on the host OS that is protected by a keyfile.

      It's actually a nice way to do it because you can have the host OS as something like a read-only bootable Linux DVD, and use it as an outer layer that somewhat mitigates attacks on the host OS. For example if the host OS was running a VPN/Tor and sending all traffic from the inner host OS over that there would be no way, short of the user making a mistake, for the host to get the IP address of your internet connection. It also prevents apps in the host OS from leaking data outside of the VPN/Tor, and allows you to spoof the network card's MAC address at a (virtual) hardware level, and limits hardware fingerprinting of the machine the host is really running on.

      You can also Wireshark the host OS if you are really paranoid, see if it sends any packets to nsa.gov.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    8. Re:To Crypt or Not To Crypt by WaywardGeek · · Score: 1

      I just added a keyfile as you suggested. I put it on a couple of USB keys, so I have a backup, and now in theory my encrypted volume can't be mounted without having the physical key. That should greatly increase my passphrase protection, as well as the volume contents (basically a list of all my various user/password credentials at various sites). I'm still running TC in Windows, and several times I've answered "yes" to let various programs make changes to my hard disk, and my machine probably comes with back-doors from both Lenovo and Microsoft and maybe even Intel. I don't trust our company's closed-source VPN provider, either. So, I still don't feel secure, but at least it's an improvement. Thanks for the tip.

      --
      Celebrate failure, and then learn from it - Nolan Bushnell
    9. Re:To Crypt or Not To Crypt by Unordained · · Score: 1

      Not only does TC do a poor job protecting my data, but when an attacker does manage to guess a user's low-entropy password, he can then try that password all over the place to see where else the user has used it

      That's not at all unique to TrueCrypt. If someone guesses a user's password, it's the user's fault they used the same password elsewhere.

      Password-strengthening before encryption is not the same as salting & hashing passwords for later authentication, where rainbow tables and "guessing" a password makes sense -- we're not talking about storing the resulting strengthened password where it could directly attacked ... unless, maybe, perhaps you're trying to say this is stored in-memory while the system is running, and that's the kind of attack you're trying to describe? I don't see why the strengthened password would even need to be kept in memory once it's used to unlock the real keys, which TC will need at runtime for crypto. Having to re-fetch the real keys based on the password at every i/o would be prohibitively expensive.

    10. Re:To Crypt or Not To Crypt by WaywardGeek · · Score: 1

      I'm always amazed at how hard something as simple as password hashing can be. Yes, it's the user's fault for reusing passwords, but we should try and protect him anyway, because it's very common. Part of the job of the computer security industry is protecting stupid people. Improving this is situation one reason for the Password Hashing Competition.

      You are right that password strengthening before encryption is a different problem from user authentication, but the solutions tend to be the same. You can use Bcrypt or Scrypt for strengthening a password hash on an authentication server just like you can while deriving a volume decryption key. The main difference seems to be that a common server may not have a significant fraction of a second to spend on authenticating a user/password combo. TC has some additional constraints, like the volume needs to appear as random data, making it harder to embed various encryption parameters, such as which key stretching algorithm is in use. To an attacker, he doesn't care whether the password/salt is protecting a login account or an encrypted volume. To him, it's just so many rounds of PBKDF2 (or whatever), and then a quick check to see if he got the right answer, and do as many in parallel as possible. Salt is used either way to defeat rainbow tables, so instead attackers use GPU farms to do massively parallel brute force guessing, where each guess is user/salt specific.

      However, the two cases I've mentioned are both encryption: TC encrypted volumes, and OpenSSh id_rsa private keys. We could argue about how much effort a server should put into protecting it's user's passwords, but both TC and OpenSSh do *nothing* more than a typical server, devoting only a millisecond to key stretching. That's just lame.

      --
      Celebrate failure, and then learn from it - Nolan Bushnell
    11. Re:To Crypt or Not To Crypt by wiredlogic · · Score: 1

      A passphrase from hell doesn't protect you from a keylogger. It does, however, put the burden on whatever organization hacks your computer to justify why they installed a keylogger since you can demonstrate that the long password couldn't possibly be brute forced. If they try to hide their tracks it is difficult to use a parallel reconstruction to explain away how they got the long password. Just don't ever fall for the trap of thinking you are invulnerable.

      --
      I am becoming gerund, destroyer of verbs.
    12. Re:To Crypt or Not To Crypt by david_thornley · · Score: 1

      Yeah, it's the users fault for not being able to remember 37 different strong passwords which change from time to time. (I haven't counted the passwords I use from time to time, but three dozen feels in the ballpark.) Heck, I can't remember that many, and I use a system, as well as having many low-security accounts on the same password.

      If you try a system that approximately nobody seems able to use, after extensive efforts at user education, and the system sounds impractical to everybody who knows something about human factors, just maybe that system sucks in the real world. Similarly, if you build a site that is much like four hundred thousand other sites, and expect your users to do something for you they won't be able to do for another fifty, you may be disappointed.

      Remember, all these systems would be much easier to build and maintain if it wasn't for all those blasted users.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
  3. Hard to understate by Anonymous Coward · · Score: 2, Insightful

    just important this audit is...

    1. Re:Hard to understate by wonkey_monkey · · Score: 2, Informative

      Hard to understate

      It's not really important at all.

      There, that was easy.

      Or, assuming the AC meant "overstate":

      Without this audit the lives of every person on this planet are doomed to end in fiery death when the Earth plummets into the Sun in 2017!

      Also easy.

      --
      systemd is Roko's Basilisk.
  4. Technically if an NSA backdoor existed by WillAffleckUW · · Score: 1, Insightful

    Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

    So, what we can say is that it's clean, insofar as they are permitted to report.

    Verify, then trust.

    --
    -- Tigger warning: This post may contain tiggers! --
    1. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 1, Insightful

      Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

      So, what we can say is that it's clean, insofar as they are permitted to report.

      Verify, then trust.

      "Finally, iSEC found no evidence of backdoors or otherwise intentionally malicious code in the
      assessed areas" - so I guess they are permitted to lie.

    2. Re:Technically if an NSA backdoor existed by masonc · · Score: 3, Interesting

      The code is being audited in America. That's pretty funny.
      How about an audit in a country where the NSA cannot tell the auditors to shutup?

      --
      CM www.cometenergysystems.com Blog: http://caribbeanrenewable.blogspot.com/
    3. Re:Technically if an NSA backdoor existed by techno-vampire · · Score: 4, Interesting

      Tell me this: if the NSA did put a backdoor in the package and if this audit found it, how would the NSA know about it in time to prevent it being reported? Sending a security letter to the auditors would just be considered proof that there was a backdoor to be hidden. The auditors may have been forced not to reveal anything about it to the general public, but you can bet that the people over at TrueCrypt would have found out about it and eliminated it as soon as possible, although they'd probably have had to pretend that they found the flaw themselves to protect both themselves and the auditors.

      --
      Good, inexpensive web hosting
    4. Re:Technically if an NSA backdoor existed by vux984 · · Score: 5, Insightful

      Technically, if an NSA backdoor existed in the codebase, you would be prevented from reporting it by an NSA letter, subject to immeadiate imprisonment and confiscation.

      Two responses.

      First, I suspect if they were confronted with an NSL they could go the lavabit route and simply suspend the audit project with no explanation. IANAL but I don't think the NSA can compel them to falsify the audit results.

      Second, if they are smart, they can have it audited multi-nationally with independent auditors to make it harder for any government gag orders to stick.

    5. Re:Technically if an NSA backdoor existed by WillAffleckUW · · Score: 0

      See, that's my point.

      The audit needs to occur in a place that does not utilize the backdoors the NSA and GCHQ and other agencies are.

      Which rules out Canada, the UK, and the USA.

      At the bare minimum.

      Verify. Then trust.

      --
      -- Tigger warning: This post may contain tiggers! --
    6. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 2, Insightful

      And Germany and France and South Korea and Japan and Brazil and China and Australia and New Zealand, etc. Or do you honestly think only those 3 countries spy on their citizens?

    7. Re:Technically if an NSA backdoor existed by ewibble · · Score: 1

      Um put an agent inside iSEC, although we know the NSA would above that. Spying is not their job.

    8. Re:Technically if an NSA backdoor existed by WillAffleckUW · · Score: 1

      True. I for one know that Australia and China definitely do.

      My point is that you need to set it up so that you have three auditors for each part, each in a different "security" region.

      And give them "unsafe" code words to embed in a place where other auditors can see if they have been compromised.

      Has to be done in a sealed room without electricity, of course (or at least no circuits in) when you set up the code words.

      Otherwise, we had the technology in the 80s to hear it, so I can guarantee we can still hear it.

      Technically they would have to disrobe and shower and scrub if you really wanted to be safe.

      (thinking about this makes it sound like an episode of Get Smart ....)

      Verify. Then trust.

      --
      -- Tigger warning: This post may contain tiggers! --
    9. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      Well the prudent thing would be to send a letter as soon as the audit was organized, before they had time to uncover anything.

    10. Re:Technically if an NSA backdoor existed by Charliemopps · · Score: 4, Interesting

      The problem with the NSA is we have no idea what their capabilities are, technologically or legally. They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them. So if they did come to you with a NSL, no matter how ridiculous or unconstitutional it was, what choice would you have? You could go to the media, but how embedded in the media are they? Do they have standing NSLs with all the media organizations out there? You could go outside the country, but those newspapers are government by their own countries version of the NSA who's working in close relationship with ours. This really is a Global totalitarian secret police state. They haven't started herding people into camps or anything, but really... what's to stop them?

    11. Re:Technically if an NSA backdoor existed by vux984 · · Score: 4, Insightful

      Do they have standing NSLs with all the media organizations out there?

      I think there'd be less Snowden leak coverage if there were. :)

      You could go outside the country, but those newspapers are government by their own countries version of the NSA who's working in close relationship with ours

      Like China & Russia? Governements want their own security as much as their own intelligence agencies want to break it... there's too many pieces moving in opposite directions for there to be a credible global coverup of a transparent audit of open source software.

    12. Re:Technically if an NSA backdoor existed by viperidaenz · · Score: 2

      Why does it rule those countries out?
      You you perform your audits in all 3 countries, the only things being missed are backdoors put in by all 3 securities agencies cooperating together.
      Add in China or some other "we don't like USA" country and you get better odds.

    13. Re:Technically if an NSA backdoor existed by WillAffleckUW · · Score: 1

      No, my point is that you can't choose three countries which work together to spy on their citizens - for example, choosing Canada, US, and UK would be self-defeating.

      You need one in each region, so that the "odd man out" will be obvious when it "fails" to report a flaw the other two report.

      --
      -- Tigger warning: This post may contain tiggers! --
    14. Re:Technically if an NSA backdoor existed by PopeRatzo · · Score: 1

      The code is being audited in America.

      Is there something preventing an audit elsewhere? Is it illegal to send the source code overseas? And how are these audits done? There aren't a lot of details in TFA. Is it like a big Wiki where anybody can look at the code and report what they find, or are the auditors vetted with specific sections assigned them?

      I'm asking seriously. I'm not a developer, so I don't know. But I worry about security and snooping.

      --
      You are welcome on my lawn.
    15. Re:Technically if an NSA backdoor existed by 2fuf · · Score: 1

      > I guess they are permitted to lie

      one doesn't need permission to do it anyway

    16. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      The second sentence addresses that very situation. Do you need a dopey YouTube video to read it out for you?

    17. Re:Technically if an NSA backdoor existed by Antique+Geekmeister · · Score: 1

      The NSA was _able_ put in back doors. According to the report, the build environments were not safe enough and well enough controlled, or verified, to _prevent_ back doors. Given the NSA's strong interest in having one, and their level of skill, I'm afraid I'd have to assume that they did, indeed, create one. Whether a system that is at risk of such a back door is good enough for personal or even business is something you'd have to decide on a personal basis.

      It does seem a good step in the right direction for open source tools to _get_ a thorough security audit, rather than merely relying on "many eyes" to ensure security.

    18. Re:Technically if an NSA backdoor existed by ColdWetDog · · Score: 1

      Oh just post it on Slashdot. We'll do the rest.

      --
      Faster! Faster! Faster would be better!
    19. Re:Technically if an NSA backdoor existed by VortexCortex · · Score: 0

      The problem with the NSA

      The problem with the NSA is the same as all other problems: They Exist.

      Government agencies have long since proven they can't be trusted with secrecy. A secret oversight committee just moves the problem around.

    20. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      And what if a security agency discovers a backdoor they didn't put in themselves? Even if they are against the country that put it in, they may not be interested in sharing information about that backdoor if they could still use it one way or another.

    21. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 1

      ...what's to stop them?

      Fear of American Citizens who have not yet disarmed.

    22. Re:Technically if an NSA backdoor existed by cold+fjord · · Score: 0

      . They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them.

      They are only "violating" the cartoon version of the constitution. The real Constitution is doing ok, at least for this issue.

      This really is a Global totalitarian secret police state. They haven't started herding people into camps or anything, but really... what's to stop them?

      Do you have any links to info about those "FEMA death camps" you care to share?

      --
      much of left-wing thought is a kind of playing with fire by people who don't even know that fire is hot - George Orwell
    23. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      So IOW, the NSA could send a letter regardless and ruin the trust people place in TrueCrypt?

    24. Re:Technically if an NSA backdoor existed by CrimsonAvenger · · Score: 1

      The problem with the NSA is we have no idea what their capabilities are, technologically or legally.

      Well, if you read all NSA-related legislation, you should have a good idea of their LEGAL capabilities are.

      Which, unfortunately means reading basically ALL legislation passed since NSA was founded, since a rider could have been inserted into unrelated legislation quite easily.

      They are clearly violating the constitution already and there seems to be no one willing or capable of stopping them.

      There are several people CAPABLE of stopping them. The President, for one, being their boss. Congress can always just defund them.

      Alas, neither the President nor Congress seems to be WILLING to stop them. Consider this carefully next time you pick a President/Senator/Congressman.

      Oh, and try not to fall for the "hope and change" line again. It wasn't true when Obama said it, nor when Bush used his equivalent, nor when Clinton used his variation, nor when Reagan said words to that effect, nor when Nixon said it, nor when Johnson said it, nor Kennedy, nor....

      ALL Presidential candidates (except the guys who were former VPs, who usually use a "we'll continue the hope and change of the last eight years") use a variation on that theme. ALL of them are lying.

      --

      "I do not agree with what you say, but I will defend to the death your right to say it"
    25. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      "Finally, iSEC found no evidence of backdoors or otherwise intentionally malicious code" is pretty definitive. they are not permitted to lie by law. good point.

    26. Re:Technically if an NSA backdoor existed by BitZtream · · Score: 1

      If you find a back door, you publish it IMMEDIATELY, and let the NSA found out that you know about it by reading it on Google News.

      Their security letter doesn't do much at that point.

      What do you do, find the bug and then go ask them if you can publish it?

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    27. Re:Technically if an NSA backdoor existed by LurkerXXX · · Score: 1

      No, you think you've found a possible security hole and you email your friend Mike and ask him to look over it and see what he thinks. The NSA intercepts the email, and immediatly sends you the security letter.

    28. Re:Technically if an NSA backdoor existed by flyingfsck · · Score: 1

      "They haven't started herding people into camps or anything" Uhmmm... never heard of Gitmo?

      --
      Excuse me, but please get off my Pennisetum Clandestinum, eh!
    29. Re:Technically if an NSA backdoor existed by Threni · · Score: 1

      The source code is available here:

      http://www.truecrypt.org/downl...

      Nothing to stop anyone anywhere from looking. And I don't see how a " NSA letter " , even to someone in the USA, would stop them from exercising their first amendment rights and writing whatever they wanted, or from adding comments to the code and posting them somewhere, etc.

    30. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      Yes, I am pretty sure that China doesn't work together with NSA. Whether or not they are spying - that's off-topic.

      To be completely sure, make the audit in Russia. Hardly anyone else is interested in NSA secrets, despite they already have most of them, thanks to Mr. Snowden.

    31. Re:Technically if an NSA backdoor existed by david_thornley · · Score: 1

      [Citation Needed]

      Seriously, where do you get this? You aren't allowed to disclose that you got certain specific requests. Where do you get from there to a ban on free speech in general?

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    32. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      That would be Russia and China.

    33. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 1

      That only works with tinfoil particles in the soap.

    34. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      If you are too stupid for Operational Security, then General Darwin Of One Percent Security will try to nuke your genes. Think or perish.

    35. Re:Technically if an NSA backdoor existed by PopeRatzo · · Score: 1

      Thanks for the info. That's what I'd assumed, and hoped.

      So I'm not sure where this idea that these audits are "American only" or that there is something preventing someone from pointing out a vulnerability comes from.

      Generally, I trust stuff that has lots of eyes on it.

      --
      You are welcome on my lawn.
    36. Re:Technically if an NSA backdoor existed by infinitelink · · Score: 1

      NSA letters, if my occassional skimming on the topic is correct, are gag orders about themselves as well. There are apparently ways to legally respond in the public to these without revealing one has been received but it involves not talking rather than talking.

      --
      Intelligent idiots are we. | Evil men do not understand justice.
    37. Re:Technically if an NSA backdoor existed by Anonymous Coward · · Score: 0

      Just like the Syrian Government is falling the the heavily armed Rebel forces there. Your piddly little semi auto AR15 you bought at Wal-Mart is not going to stop the US government.

  5. also by JustNiz · · Score: 1

    Since Snowden's revelation about the NSA's clandestine $10 million contract with RSA,
      I hope that as well as checking that the code implements some known encryption algorithm properly, that they also confirm that the algorithm itself is mathematically unadulterated (by the NSA or whoever).

    1. Re:also by Shakrai · · Score: 5, Insightful

      Since Snowden's revelation about the NSA's clandestine $10 million contract with RSA,

      If you're on NSA's radar you've got bigger problems than TrueCrypt's trustworthiness or lack thereof. The NSA doesn't have to have a back door into AES (or the other algorithms) when they have an arsenal of zero day exploits, side channel attacks, social engineering, and TEMPEST techniques at their disposal. The average user should be far more concerned about these attack vectors (from any source, not just NSA) than the security of the underlying encryption algorithm.

      The Diceware FAQ sums up the problem rather succinctly: "Of course, if you are worried about an organization that can break a seven word passphrase in order to read your e-mail, there are a number of other issues you should be concerned with -- such as how well you pay the team of armed guards that are protecting your computer 24 hours a day."

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    2. Re:also by rahvin112 · · Score: 4, Interesting

      Oh hell, they'll just sneak into your home in the middle of the night and plant a hardware bug or key logger into your computer.

      One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer. They got a child pornographer like this, his use of true crypt didn't help because they had video of him entering the password and simply entered the password once they seized the computer.

      True Crypt cannot reasonably protect you from law enforcement nor state sponsored spying like the NSA. It might protect you from some non-tech police agency in some shit hole country being able to access it but then they just use the standard non-tech password extraction method.

      Obligatory XKCD. http://xkcd.com/538/

    3. Re:also by Kjella · · Score: 3, Insightful

      If you're on NSA's radar you've got bigger problems than TrueCrypt's trustworthiness or lack thereof.

      In case you've been sleeping under a rock for the last year, the target of the NSA is everyone. Not that they put you on the same level as the Chinese military of course, but nobody's under their radar and if they can grab your data or metadata easily they will because you could be a terrorist or at least the friend of a friend of a friend of a terrorist. It's not that the average joe would stand a chance if they threw everything in their arsenal at us, but those "zero day exploits, side channel attacks, social engineering, and TEMPEST techniques" don't come free and using them highly increases the chances of exposing them. The question is more like "Does NSA grab all the TrueCrypt containers used as backup on Dropbox/GDrive/whatever and rifle through everyone's data?" than "If the NSA really wants the contents of my laptop, would this really stop them?"

      --
      Live today, because you never know what tomorrow brings
    4. Re:also by Anonymous Coward · · Score: 0

      One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer.

      Paranoid much?

    5. Re:also by Lost+Race · · Score: 2

      Snowden basically walked out of the NSA with all their secrets; who's to say a few dozen or hundred other contractors didn't do the same thing before him? Everything the NSA knew or had access to before 2013 was most likely available in blackhat circles through clandestine leaks.

      Any backdoors in TrueCrypt would be a security disaster, and the NSA has already proven itself willing and able to put backdoors in highly trusted security software. It's also proven itself incapable of keeping secrets.

      Worrying about NSA-planted vulnerabilities is not the same thing as worrying about a direct attack from the NSA itself.

    6. Re:also by BitZtream · · Score: 1

      The NSA doesn't target anymore than a fisherman targets every tuna.

      They are doing a dragnet, if you become a person of interest ... THEN they have this big collection of data on you to use, but before that, you're just another random datapoint that they aren't expending resources on ... or wasting their precious exploits on.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    7. Re:also by Shakrai · · Score: 1

      The metadata argument wears thin on me. If my phone number is two or three levels removed from a terrorist I really don't see why it's objectionable that the Government take a precursory look at my call logs. They'll quickly find that I'm a rather boring sort, whose connection with the terrorist was likely limited to ordering the same take out, and my privacy isn't significantly impacted by having someone review my call logs after obtaining a court order.

      Traditional police investigative techniques would be at least as invasive, if not more so. Ever been interviewed by the police because you're one or two levels removed from a criminal suspect they're attempting to establish a case against?

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
    8. Re:also by phorm · · Score: 1

      One of their favorite tactics used by law enforcement is to install cameras in your residence facing where you normally use your computer

      At that point I'm pretty sure there should be a warrant involved...

    9. Re:also by rahvin112 · · Score: 1

      There was, that's the entire point. You can't win against the state. The state can take action by force, the warrant is a check on that system but regardless no matter what you do and the technical precautions you take the state, if patient and cautious, can easily acquire the information to breech those protections. It can range from the camera put in you house to the $5 wrench. Those advocating for true crypt to protect you from the state are simply wrong that it can protect you.

    10. Re:also by david_thornley · · Score: 1

      And when somebody at NSA examines or leaks your metadata, and your wife finds out about the emails to your mistress, or your employer finds out about the emails to a competitor about possibly taking a job there, or somebody finds out about your emails to a $DISEASE support group, or your fondness for Albanian furry porn, no matter how legal, you may have problems, or at least embarrassment.

      If your call logs are actually secure barring a court order, you're fine. If they leak (something like LOVEINT or a successful snoopy sysadmin), that's a problem.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    11. Re:also by phorm · · Score: 1

      Well, here's the thing. They had enough on the guy to get the warrant to plant the camera. No encryption (or in the case of heartbleed, broken encryption), and they can likely find ways to snarf all that information without a warrant, in which case it could (more easily) become a case of "find people fitting profiles we don't like, then sift through all this information and look for something that sticks"

    12. Re:also by Shakrai · · Score: 1

      That argument is bogus, insofar as an employee at Verizon could just as easily leak my call logs, yet few people take exception to Verizon storing such data.

      --
      I want peace on earth and goodwill toward man.
      We are the United States Government! We don't do that sort of thing.
  6. A triumph for FOSS by FuzzNugget · · Score: 2

    This is why open source is so important.

    1. Re:A triumph for FOSS by jones_supa · · Score: 4, Insightful

      No. This is why thorough code audits are important.

    2. Re:A triumph for FOSS by Warbothong · · Score: 2

      This is why open source is so important.

      How so? TrueCrypt is neither Open Source or Free Software. It's freeware (ie. proprietary).

    3. Re:A triumph for FOSS by Anonymous Coward · · Score: 0

      T r u e C r y p t
      Free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux

      How so? TrueCrypt is neither Open Source or Free Software. It's freeware (ie. proprietary).

      Right, TrueCrypt is not "Open Source", it's "open-source".

    4. Re:A triumph for FOSS by rippeltippel · · Score: 1
      T r u e C r y p t Free open-source disk encryption software for Windows 7/Vista/XP, Mac OS X, and Linux

      How so? TrueCrypt is neither Open Source or Free Software. It's freeware (ie. proprietary).

      Right, TrueCrypt is not "Open Source", it's "open-source".

    5. Re:A triumph for FOSS by AmiMoJo · · Score: 1

      Yes, but who will audit the audit? Because it is open source we can meta-audit, much like how Slashdot meta-moderates. Otherwise the audit would be useless to us, much like a corporation paying for an audit of itself and presenting that to the public as proof of its good work.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    6. Re:A triumph for FOSS by BitZtream · · Score: 1

      Yes ... you can meta-audit ... how's OpenSSL working for you?

      Open source is only useful if someone looks AND has the skills to understand it.

      Just being open source doesn't mean dick and you fanboys really should get that through your head. You all stand around waxing on about how 'many eyes' see it ... assuming SOMEONE ELSE is looking ... and no one actually is because ... because ... 'its open source! anyone can look!!@$!@%!@%&'

      When are you guys going to actually come back to reality. OSS is great for many reasons, but that doesn't magically make it better than any particular piece of non-OSS. Stop pretending it does.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    7. Re:A triumph for FOSS by TangoMargarine · · Score: 1

      Yeah, because it's so easy for the public to audit closed-source software.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
  7. Re: by Anonymous Coward · · Score: 1

    ITT: People who (a) don't know how US law actually works and (b) assume that everyone in the world is bound by US law.

  8. Bootloader & Windows Driver by Anonymous Coward · · Score: 4, Insightful

    The first phase of the audit focused on the TrueCrypt bootloader and Windows kernel driver. Not really surprising that they didn't find any critical security issues in those parts. The high value bugs should be in the crypto parts and how they are implemented.

    1. Re:Bootloader & Windows Driver by Anonymous Coward · · Score: 2, Informative

      What? I should probably assume you are joking, but in case you are not:

      This is a stupid statement. If someone is American and they have a bank account in another country, both are able to be true. They are an American with an off shore bank account. Similarly, just because the NSA is American and have impacted the concept of security does not mean that Americans can not evaluate or produce secure code. And just to be more antagonizing than you are being, guess what? you used 'American' and 'security' in the same sentence while trying to explain that its impossible to do so. In fact, the NSA is an American agency and I would say that they have been leading the way in developing methods of intrusion, and circumventing security. So clearly Americans understand security so well, we know how to get around what exists today. Anyone hiring you for anything other than to take food orders is either stupid or naive.

    2. Re:Bootloader & Windows Driver by viperidaenz · · Score: 2

      It depends why you're hiring an American to do your security audit.

      Is it stupid for someone in China to hire an American to look for back-doors that may have been added by a Chinese Government agency?

    3. Re:Bootloader & Windows Driver by epyT-R · · Score: 3, Informative

      The crypto is implemented in the driver, as well as the bootloader. The application known as truecrypt just flips their configuration bits around, loads keys into ram, and tells the driver when to mount/dismount containers etc. The bootloader needs to know enough to mount the system partition and hook into BIOS so that the regular OS bootloader can take over using it's normal calls. Once it loads the kernel and related drivers, truecrypt.sys takes over handling container IO.

        The separate formatting utility probably contains some too since it's used to create containers..

  9. what about compilers ? by Anonymous Coward · · Score: 2, Insightful

    isn't it possible to just have your backdoor be inserted by the compiler ?

    1. Re:what about compilers ? by r.freeman · · Score: 1

      Yeap, that is an option. Dunno which idiot mod downvoted your insightfull question and why...

    2. Re:what about compilers ? by Anonymous Coward · · Score: 0
      I modded this statement as Redundant, it's similar to claiming water is wet or fire is hot.

      If you've read the report you'd know the auditors are addressing the question of traceability of the compilation.

    3. Re:what about compilers ? by Anonymous Coward · · Score: 0

      Off topic. If there's a backdoor in the compiler, then guess what? That's a problem with the compiler, not TrueCrypt. I'm not sure why anyone would think that would show up in TC's sourcecode.

    4. Re:what about compilers ? by Anonymous Coward · · Score: 0

      It's not off topic. It would not be in the source, but it would be in the binary that most people use, so it is very much to the subject.

  10. memset() is bad? by Anonymous Coward · · Score: 5, Interesting

    I've been coding in C a long time and one of the medium security faults makes no sense to me:
    "Windows kernel driver uses memset() to clear sensitive data"
    The reasoning they give is:
    "...However, in a handful of places, memset() is used to clear potentially sensitive data. Calls to memset() run the risk of being optimized out by the compiler."

    WTF?!?
    I suppose a smart compiler can optimize out a memset() if it's directly preceeded by a calloc() or something, but I have never had any compiler ever just ignore my request to memset().
    What am I missing here?

    1. Re:memset() is bad? by Anonymous Coward · · Score: 4, Informative
    2. Re:memset() is bad? by Anonymous Coward · · Score: 2, Informative

      https://www.securecoding.cert.org/confluence/display/cplusplus/MSC06-CPP.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data

    3. Re:memset() is bad? by canajin56 · · Score: 5, Informative

      As a special case, MSVC++ removes memset(array,value,sizeof(array)) if array isn't read again before the end of its scope.

      For example

      void Foo()
      {
      char password[MAX_PASSWORD_LEN];
      InputPassword(password);
      ProcessPassword(password);
      memset(password, 0, sizeof(password));
      }

      The MS compiler will delete the memset. In Windows you should use RtlSecureZeroMemory to zero out memory you want to keep secure.

      --
      ASCII stupid question, get a stupid ANSI
    4. Re:memset() is bad? by Anonymous Coward · · Score: 0

      It sounds as though they're concerned that the compiler may optimize away a memset used to sanitize a block of memory immediately before freeing it. I would imagine that if the compiler can prove that a read does not occur (or, perhaps even has no side-effects) after a write, it would be legal to optimize that write away. Though, IANAL(anguage)L.

    5. Re:memset() is bad? by philcolbourn · · Score: 4, Interesting

      Say you store a password in a memory buffer. Use it. Then overwrite it with a call to memset. If this buffer is never used again, a compiler may think this is a wasted write and optimise-out this call to memset.

    6. Re:memset() is bad? by viperidaenz · · Score: 1

      If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?

    7. Re:memset() is bad? by theskipper · · Score: 2

      Great article. Including the openssl bug(s) he pointed out...was expecting something esoteric but turned out to be really straightforward i.e. the type of error you make at 2am, taking the size of the pointer instead of the actual size of the buffer.

    8. Re:memset() is bad? by fisted · · Score: 1

      No idea why the paper talks about the compiler optimizing it out, that's obviously wrong. However, in the next paragraph, it reveals that swapspace is the reason. You might, after the page fault and swap-in, initialize the buffer via memset -- however this doesn't erase the previous data from swap space. Apparently, some "secure" memset-like routine does that.

    9. Re:memset() is bad? by rdnetto · · Score: 1

      If you call memset on some allocated memory and then free that memory, what (apart from clearing sensitive data from physical RAM) functional difference does removing the call to memset make? None?

      The longer the data remains in memory, the wider the window to read it via some other exploit. (Also, anything running as root could potentially access it.) This is precisely what happened with Heartbleed.

      --
      Most human behaviour can be explained in terms of identity.
    10. Re:memset() is bad? by Anonymous Coward · · Score: 0

      Why do you think optimising out memset is "obviously wrong"?

      I've encountered precisely this in Java when conducting micro performance tests. If the compiler thinks that there is no effect of performing a computation (in the sense that nothing else in your program depends on the result), it can get optimised away entirely.

      To prevent this, I had to perform some genuinely useless calculations (in the context of the running application), hold on to intermediate results, and output the final calculation precisely to prevent the compiler getting rid of code which was running millions of times (the compiler will specifically optimise code that runs a lot...) and for which I only actually wanted timings.

    11. Re:memset() is bad? by BitZtream · · Score: 1

      That and memset in windows doesn't zero by default, as an optimization, until the page is hit (or some such pattern that I don't fully recall)

      Theres a specific kernel API for zeroing memory because memset, even if called, may choose not to do anything. ZeroMemory is the generic way, SecureZeroMemory removes the 'option' to actually do the zeroing from the kernel and always does it.

      Using memset to scrub memory on Windows, then not doing anything with it that requires the memory to actually be in active use ... the memory will never be written too.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    12. Re:memset() is bad? by david_thornley · · Score: 1

      What you're missing is that some compilers get very aggressive about removing code when optimizing. I don't have the C standard here, but the C++ standard says the compiler can do anything as long as it keeps volatile variable access and calls of I/O library routines the same, in the same order. This means that, if you have a chunk of memory and memset() it and nothing of that chunk is referenced for an I/O operation or volatile variable access, it can go.

      Whether this is a good thing is debatable. I'm glad compilers have modes like that, for when I'm just writing a program and want it to run as fast as possible. On the other hand, you can get yourself into trouble that way, particularly if you don't carefully avoid the possibility of undefined behavior.

      --
      "When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
    13. Re:memset() is bad? by viperidaenz · · Score: 1

      But the program performs functionally the same.
      That's the rule followed when doing compiler optimisations.

      memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.

      You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.

    14. Re:memset() is bad? by rdnetto · · Score: 1

      But the program performs functionally the same.
      That's the rule followed when doing compiler optimisations.

      memset has nothing to do with Heartbleed by the way, nor does any compiler optimisation.

      The program will generate the same output yes, but the security implications are not the same.
      This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable. Furthermore, the most common reason for using custom mallocs in security-critical applications is to do exactly that - to zero all memory immediately upon freeing.

      Zeroing memory like this is a common practice in such cases.

      You also don't guarantee the original data is overwritten. If your application is paged out of RAM before the call to memset, when it gets loaded back in to RAM it can be pointing to a different physical memory location. You're now overwriting.... something completely different.

      This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.

      Now, what is true is that additional copies of the data could be made, but you'd need to have escalated to root to access anything in a pagefile (at which point your system is completely compromised anyway), and I'm not even sure if direct access to L1 cache is possible.

      --
      Most human behaviour can be explained in terms of identity.
    15. Re:memset() is bad? by viperidaenz · · Score: 1

      This is actually tangentially related to heartbleed - if the memory had been zeroed when freed, the scope of the exploit would have been greatly reduced, as only currently allocated blocks would have been vulnerable

      The blocks holding the certificate private key are always allocated, so always vulnerable.

      This is completely incorrect. Until it is freed (or realloc'ed), the address returned by malloc will point to the same data, regardless of whether it is in the L1 cache, RAM, or paged to disk. Were this not the case, each program would need to implement its own MMU.

      So virtual memory is completely useless, because paging to disk doesn't free up the physical RAM or other processes?

      Perhaps you should have read the article linked in the article you linked. http://www.viva64.com/en/k/004...

      There is SecureZeroMemory() function in the depths of Win32 API. Its description is rather concise and reads that this function overwrites a memory region with zeroes and is designed in such way that the compiler never eliminates a call of this function during code optimization.

      So don't use memset to zero memory.

      There is still the risk that another process reads data from RAM that another process was using, unless the OS zeros out the memory before allocating it.
      That's something you can't get around in application code because you don't control the other applications.

  11. Re:The truth about APK by Anonymous Coward · · Score: 0

    Utilization of the HOSTS file would not allow you to avoid police detection; it is only useful as an anti-malware tool. Where do you get your information from?

  12. The Next Question by Nom+du+Keyboard · · Score: 0

    The next question to answer is: Can Heartbleed compromise True Crypt?

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
    1. Re:The Next Question by TangoMargarine · · Score: 1

      Does TrueCrypt use SSL?

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
  13. Re:The truth about APK by r.freeman · · Score: 1

    what the fuck did I just read?

  14. The backdoor is not in the source by kbg · · Score: 3

    The backdoor is not in the source it is in the MVC++ compiler. NSA is not stupid, putting the backdoor in the source itself would be risky, it would be much wiser to put the backdoor in the MVC++ compiler itself.

  15. Re:The truth about APK by Anonymous Coward · · Score: 0

    I am unfamiliar with the drama surrounding apk, but I do know that people who run around accusing others of pedophilia are usually just using it as ad hominem.

  16. Re:Nothing like $140k to vet opensores by epyT-R · · Score: 2

    at least the sores are open, so that one may take a puss sample and analyse it for disease. When the sores are closed, who knows what you'll wake up with in the morning.

  17. Re:Why are we trusting a Republican group? by epyT-R · · Score: 1

    Why would you trust the liberals? I wouldn't trust either.

  18. Re:The truth about APK by thexfile · · Score: 1

    WTF. A troll with a cause.

  19. Re:The truth about APK by Anonymous Coward · · Score: 0

    The punishment for making this accusation maliciously should be worse than the crime itself.

  20. Port to GCC, then ensure no backdoors in GCC by tepples · · Score: 5, Interesting

    One way to detect a backdoored compiler to a fairly high certainty is diverse double-compiling, a method described by David A. Wheeler that bootstraps a compiler's source code through several other compilers. For example, GCC compiled with (GCC compiled with Visual Studio) should be bit for bit identical to GCC compiled with (GCC compiled with Clang) and to GCC compiled with (GCC compiled with Intel's compiler). But this works only if the compiler's source code is available. So to thwart allegations of a backdoor in Visual Studio, perhaps a better choice is to improve MinGW (GCC for Windows) or Clang for Windows to where it can compile a working copy of TrueCrypt.

    1. Re:Port to GCC, then ensure no backdoors in GCC by steelfood · · Score: 1

      We know there's a difference between Windows containers and Linux containers, that being the ~64KB of random data at the end of the header for a Windows container instead of ~64KB of 0's in a Linux container.

      This difference is not a result of some difference in the source code of Truecrypt when compiled under Windows. Where could the backdoor be?

      --
      "If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
  21. Re:Why are we trusting a Republican group? by kwbauer · · Score: 1

    Due, Bush has been out of office for 6 years now. I know things are moving fast but please do try to keep up.

  22. It Assumes Bounds Checking without Implementing It by Sanians · · Score: 2

    WTF?!?

    WTF indeed.

    There seems to be a major trend towards making compilers create code that is as different as possible from what the programmer wrote without being so different that the programmer actually notices. One might assume it's a secret NSA plot to defeat security measures in all software everywhere. You know, if one was incredibly paranoid, that is.

    It's hard to say whether this is justified behavior. As an example, consider this code from a link an AC posted:

    int
    crypto_pk_private_sign_digest(....)
    {
    char digest[DIGEST_LEN]; ....
    memset(digest, 0, sizeof(digest));
    return r;
    }

    Exploit mitigation code like this is a case of writing code which we expect to never have any effect, just in case we're wrong and it does have an effect. Then the compiler comes along and decides for itself that the code we wrote will never have any effect and removes it. It's kind of hard to blame it for noticing the uselessness of the operation when we ourselves expected the code to likely have no effect when we wrote it, but then, the whole reason we wrote it is because we thought we might be wrong. Should the compiler then assume that we might be wrong as well, and that we might access that memory using a different pointer?

    Does it make sense to compile with optimization enabled when, by including things like the memset() call to clear memory we're finished using, we clearly have goals other than optimization?

    The article mentions the fix being the use of a different function which won't be optimized away, but I wonder if even that is a legitimate fix. Our "digest" array is just another variable that the compiler is free to do whatever it wants with in the name of optimization. If it will make the program run faster, it's free to make two copies of it. Then our new never-optimized-away function will end up erasing only one copy of the variable.

    So problem here isn't the use of memset() rather than some other function. The problem is that we're asking the compiler to create code that doesn't match what we've written. It should be no surprise then when it goes ahead and does that. Thus, I don't think it's correct to claim that the error here is the failure to use the correct function to clear the memory. I think the error is in asking the compiler to generate code that isn't identical to the source code.

    The core of the problem is that C isn't a language that allows us to clearly tell the compiler exactly what we want to happen. Without bounds checking on pointer use, every pointer is effectively a pointer to all memory. Thus, when a pointer falls out of scope, it doesn't mean anything. That memory can still be accessed via any other pointer anywhere in the program. If C enforced bounds checking, such that accessing the data in "digest" via any other pointer was impossible, then the compiler could safely work under the assumption that once "digest" falls out of scope, the data it points to will never be accessed again, and thus removing the memset() call would be a safe thing to do since it truly would have no effect.

    It really seems ridiculous when you think about it. Compilers assume that bounds on pointers will be respected, yet make no attempt whatsoever to enforce those bounds, essentially guaranteeing that they will not be respected since programmers are imperfect.

    Consider what the compiler will do when it encounters code like this:

    int a[4];
    int b[4];
    int c[4];
    b[-1] = 0;

    Despite the obvious error in the above code, GCC will compile it without error. It will then perform optimizations that assume that neither a[] nor c[] have been affected by the assignment to b[]. It seems rather ridiculous that anyone is expected to create secure software in such an environment. Either the compiler should enforce bounds checking, or it should assume that any pointer operation ca

  23. Re:The truth about APK by Number42 · · Score: 0

    Where the hell did this discussion spring up from? Is this some sort of subtle attack against the Android app format? I don't get it.

  24. sizeof() is ambiguous by Sanians · · Score: 2

    was expecting something esoteric but turned out to be really straightforward

    I think you failed to notice that the page talks about two separate bugs. In the first one, the memset() really is completely removed by optimization.

    the type of error you make at 2am, taking the size of the pointer instead of the actual size of the buffer

    I'd argue that's an error one might make any time of the day. The sizeof() operator is ambiguous. Consider the following example:

    #include <stdio.h>
    void main() {
        char a[100];
        char *b = a;
        printf("address of a is %p\n", a);
        printf("address of b is %p\n", b);
        printf("size of a is %lu\n", sizeof(a));
        printf("size of b is %lu\n", sizeof(b));
    };

    One might assume that, since both "a" and "b" function identically (e.g., both "a[7] = 0" and "b[7] = 0" are valid, as are both "strlen(a)" and "strlen(b)"), then using the sizeof() operator on each of them should return similar results. However, that isn't the case, as sizeof(a) gives us the size of an array while sizeof(b) gives us the size of a pointer.

    It would make more sense if sizeof(a[]) returned the size of the array while sizeof(a) and sizeof(b) both returned the size of a pointer. As it presently works, sizeof() is a somewhat scary operator to use. I usually end up using a printf() to verify that it is giving me the size of what I want the size of rather than assume I know what it is doing.

    1. Re:sizeof() is ambiguous by Anonymous Coward · · Score: 0

      sizeof() isn't ambiguous. You just have to understand how to use it.
      AC

  25. Backdoor? Why bother? by Anonymous Coward · · Score: 0

    There's no need to have a backdoor when Windows sends them your TrueCrypt password.

  26. Re:The truth about APK by K.+S.+Kyosuke · · Score: 1, Flamebait

    I am unfamiliar with the drama surrounding apk

    Nah, that's mostly just the iDevice users badmouthing Android.

    --
    Ezekiel 23:20
  27. Re:The truth about APK by Anonymous Coward · · Score: 0

    Utilization of the HOSTS file would not allow you to avoid police detection; it is only useful as an anti-malware tool.

    Actually, it's useful for no such thing. People lulled into false sense of security had better install PeerBlock with agressive lists of malicious IP addresses. A hosts file, my ass!

  28. Re:The truth about APK by Anonymous Coward · · Score: 0

    I think it is just a mentally disturbed person talking to himself. Just ignore it.

  29. Re:The truth about APK by GuB-42 · · Score: 1

    APKs rape children ?
    Sorry Apple shill, but you are going too far.

  30. Not paranoid enough by Anonymous Coward · · Score: 0

    The backdoor's in the compiler.

    Best NSA troll of all time!

  31. The truth about hosts files by Anonymous Coward · · Score: 0

    It does much more than that for speed, security, reliablity, + anonymity http://start64.com/index.php?o... [start64.com] shown in 17 points there where apk has it hosted along with sites in the security community (like malwarebytes' hpHosts website). Apk's made a good program that does what he stated in that link above in 17 points for the good of any end user of customized host files and that botnet masters and malware makers hate since it stops them dead, saves you bandwidth + tracking advertisers take from you along with infecting you with malicious script, gives you reliablity against DNS redirection flaws from fastflux and dynamic dns using botnets as well as downed dns servers, and even added anonymity against dns request logs or getting past dnsbl you may not like. It doesn't stop police using deep packet inspection or the nsa with their practically man-in-the-middle attack using discrete math graph theory techniques or BGP misuse. However it does more than any single browser addon and even fixes dns security issues with less parts and its native to any OS with a standard bsd derived ip stack.(which is most all out there if not all) for more speed, security, reliablity, and anonymity.

    Reposting again since it was minus moderated for some dumb reason earlier here http://it.slashdot.org/comment...

  32. Re:The truth about APK by Anonymous Coward · · Score: 0

    It does much more than that for speed, security, reliablity, + anonymity http://start64.com/index.php?o... [start64.com] shown in 17 points there where apk has it hosted along with sites in the security community (like malwarebytes' hpHosts website). Apk's made a good program that does what he stated in that link above in 17 points for the good of any end user of customized host files and that botnet masters and malware makers hate since it stops them dead, saves you bandwidth + tracking advertisers take from you along with infecting you with malicious script, gives you reliablity against DNS redirection flaws from fastflux and dynamic dns using botnets as well as downed dns servers, and even added anonymity against dns request logs or getting past dnsbl you may not like. It doesn't stop police using deep packet inspection or the nsa with their practically man-in-the-middle attack using discrete math graph theory techniques or BGP misuse. However it does more than any single browser addon and even fixes dns security issues with less parts and its native to any OS with a standard bsd derived ip stack.(which is most all out there if not all) for more speed, security, reliablity, and anonymity.

    Reposting again since it was minus moderated for some dumb reason earlier here http://it.slashdot.org/comment...

  33. The truth about hosts files by Anonymous Coward · · Score: 0

    It does much more than that for speed, security, reliablity, + anonymity http://start64.com/index.php?o... [start64.com] shown in 17 points there where apk has it hosted along with sites in the security community (like malwarebytes' hpHosts website). Apk's made a good program that does what he stated in that link above in 17 points for the good of any end user of customized host files and that botnet masters and malware makers hate since it stops them dead, saves you bandwidth + tracking advertisers take from you along with infecting you with malicious script, gives you reliablity against DNS redirection flaws from fastflux and dynamic dns using botnets as well as downed dns servers, and even added anonymity against dns request logs or getting past dnsbl you may not like. It doesn't stop police using deep packet inspection or the nsa with their practically man-in-the-middle attack using discrete math graph theory techniques or BGP misuse. However it does more than any single browser addon and even fixes dns security issues with less parts and its native to any OS with a standard bsd derived ip stack.(which is most all out there if not all) for more speed, security, reliablity, and anonymity.

    Reposting again since it was minus moderated for some dumb reason earlier here http://it.slashdot.org/comment...

  34. Funny you mention PeerBlock... apk by Anonymous Coward · · Score: 0

    Which adds MORE layered in filtering drivers, since the NEXT addition to my APK Hosts File Engine http://start64.com/index.php?o... is going to do the SAME THING PeerBlock does, albeit with LESS MOVING PARTS & ROOM FOR BREAKDOWN due to complexity - how?

    Just by doing what I do @ slashdot manually for IP addresses connecting to me that offer ME no value & only slowups & tracking, in fact (shearing away crap that tracks & slows me up):

    I monitored this site after applying my custom hosts file using a gui version of netstat -ano pretty much (NIRSOFT Network Latency Viewer).

    I discovered that yes, thehosts file 'shears off' MANY things that send you ads here, and track you, but SOME OF THEM ARE SERVED BY IP ADDRESS... thus, the hosts file's NOT effective vs. those served by IP!

    (HOWEVER, Firewalls, like Windows' is, only operate on IP addresses)...

    So, what to do?

    Well, lol this:

    I HAVE ALREADY BUILT THE PROTOTYPE FOR THIS that adds the IP ADDRESS of such connections in my program here... & it works - ONLY 2 THINGS CONNECT TO ME ON ANY SLASHDOT SITE, & I get what I want only. NO tracking. NO scripts, etc.

    Then, I ran minus a hosts file - I sped up noticeably, due to less crap to connect to & EVEN MORE with the hosts file running alongside it.. AND, less tracking is my guess too (bonus).

    It works... & I've already sent others here as well (Hairyfeet for example, a widely known member here I like) a ruleset for the Windows firewall for this site in fact.

    APK

    P.S.=> I am just doing what I do with hosts ( especially with less moving parts complexity + room for breakdown & slowdown using slower usermode layered on browser addons that do less + not as well as hosts)

    OR

    Even shoring up DNS (hosts fix its shortcomings in security & redirection issues from numerous malicious sources)

    Simply by USING WHAT YOU NATIVELY HAVE ALREADY, in the Windows firewall driver - NOT ADDING ON "MORE MOVING PARTS", like PeerBlock does...

    ... apk

  35. The truth about hosts files by Anonymous Coward · · Score: 0

    It does much more than that for speed, security, reliablity, + anonymity http://start64.com/index.php?o... [start64.com] shown in 17 points there where apk has it hosted along with sites in the security community (like malwarebytes' hpHosts website). Apk's made a good program that does what he stated in that link above in 17 points for the good of any end user of customized host files and that botnet masters and malware makers hate since it stops them dead, saves you bandwidth + tracking advertisers take from you along with infecting you with malicious script, gives you reliablity against DNS redirection flaws from fastflux and dynamic dns using botnets as well as downed dns servers, and even added anonymity against dns request logs or getting past dnsbl you may not like. It doesn't stop police using deep packet inspection or the nsa with their practically man-in-the-middle attack using discrete math graph theory techniques or BGP misuse. However it does more than any single browser addon and even fixes dns security issues with less parts and its native to any OS with a standard bsd derived ip stack.(which is most all out there if not all) for more speed, security, reliablity, and anonymity.

    Reposting again since it was minus moderated for some dumb reason earlier here http://it.slashdot.org/comment...

  36. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  37. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  38. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  39. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  40. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  41. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  42. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  43. Re:The truth about APK by Anonymous Coward · · Score: 0

    More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

  44. So by Anonymous Coward · · Score: 0

    ...secret courts and secret evidence is something American ? I guess somebody was right about that Poisoning The Bodily Fluids Of Justice.

    Felix Tschershinsky has won over the U.S. apparently.

  45. I never SAID it did: Show me where I have... apk by Anonymous Coward · · Score: 0

    Show a post of ME saying that, from earlier than the past month or so (of me dealing with the libelous cowardly little trolls like Tom or Zontar - who also impersonate me, or libel me etc.) go for it.

    * :)

    (Good luck - you'll need MORE THAN THAT though... lol, more like a miracle!)

    In fact, DO I POST ANYTHING LIKE THAT here(where I literally extoll & eniumerate hosts files benefits to end users in added speed, security, reliability, & anonymity):

    http://start64.com/index.php?o...

    No - I do not. So fuck off, troll...

    APK

    P.S.=> More libel & lies from weak trolls that can't ever get the better of apk like Tom http://slashdot.org/comments.p... or Zontar http://slashdot.org/comments.p... (both libelers who use sockpuppets to mod themselves up, and their opponents who dust them like apk, down with).

    ... apk

  46. Sed quis custodiet ipsos custodes? by CmdrTamale · · Score: 1

    Crede quod habes, et habes.
    --
    I do not speak for the truth of foreigners.

  47. Re:The truth about APK by Anonymous Coward · · Score: 0

    I don't get it, is this a macfag confusing apk with JavaScript?