5 ms·

Hmm I've been having similar concerns about the Windows rand_s function. Every Windows application including every modern browser relies on rand_s for secure ra

by dangero 13y ago

Hmm I've been having similar concerns about the Windows rand_s function. Every Windows application including every modern browser relies on rand_s for secure random number generation but obviously the function is completely closed source. Seems like a perfect target for the NSA.

stinos 13y ago
It sure is, but how would they do that practically? I'm not saying it's impossible, but I really wonder how they would approach this. Call Ballmer and tell him to slip in a new CRT with the next Windows update providing a targetted version seems like a long shot. And even it works they would only target a (possibly small) subset of all machines since there's enough of them that aren't updated and there's enough software out there that ships with it's own copy of msvcrxx.dll
tptacek 13y ago
Closed source isn't a significant obstacle to understanding code, and Microsoft's code is the most comprehensively reverse-engineered in the industry. It would be extremely stupid to hide a backdoor in binaries that Microsoft ships.
- nly 13y ago
  Unless the backdoor was so incredibly subtle and hard to spot that it could be hand-waved away as a bug should it turn up.
  - tptacek 13y ago
    It is actually easier to perpetrate that kind of subtlety in higher-level languages than in assembly.
    - caf 13y ago
      It can't be, because a valid way to detect such underhandedness in a higher-level language is to compile it to assembly and check that.
- pnathan 13y ago
  Calling attention to this: disassembly is a thing. It is entirely possible to reconstruct a program's design and logic from the disassembled code. This is what software crackers and antivirus writers do on a regular basis. For an enlightening write-up, see the Symantec paper(s) on Stuxnet.
  - ars_technician 13y ago
    Right, but it's harder to detect subtle manipulation. It only takes a one bit error to reduce the key space by half.
    - tptacek 13y ago
      It is hard to detect subtle manipulation period. But assembly language is an extremely concrete representation of a program; it is not an especially great way to write underhanded code. It's possible to write obfuscated assembly, of course, but it sticks out as obfuscated. To further get your head around the lack of cover compiled code would give a backdoor, it's worth knowing that Hopper will give you serviceable C-ish code from x86_64 for... let me check here... fifty nine bucks. (It's possible that my only message with that last graf is "Hopper is great").
      - pg_is_a_butt 13y ago
        assembly language is not an extremely concrete representation of a program if the hardware is engineered with backdoors which is exactly what this article suggests is happening. if some specific set of registers is set a certain way followed by a very specific series of commands, there is no practical way to prove that the hardware is doing what it should.
        tptacek 13y ago
        You are talking about a wildly different threat model than this little section of the thread is talking about. Meanwhile: if you can't trust the hardware, you can't trust C code either.
- dangero 13y ago
  I'm aware that programs can be disassembled and I have written x86 assembly myself. If closed source is not a significant barrier to completely understanding s_rand then I ask for one reference to someone who has completely audited the Windows 7/Windows 8 version of s_rand, and CryptGenRandom that s_rand calls. If you look on the related Wikipedia page what you find that there was an audit done of the Windows 2000 version of CryptGenRandom (which s_rand uses), and it was discovered to be flawed in a number of ways. The follow up is that Microsoft said that the issues were fixed in Vista. It's more than a theory that s_rand vulnerabilities will be called "bugs". It already happened once. http://en.wikipedia.org/wiki/CryptGenRandom http://en.wikipedia.org/wiki/CryptGenRandom
salient 13y ago
Microsoft shares all vulnerabilities with NSA as soon as they find out about them, and long before they fix them, anyway, which is like giving them access to a lot of backdoors into Windows. Adding one more from rand_s doesn't change the situation that much. Then there's TPM and all that other fun stuff. Until Microsoft overhauls their Windows security policies, you can never really trust Windows to keep you safe, even with the latest updates.
drzaiusapelord 13y ago
MS shares information with intelligence agencies and usually before MS has even delivered a patch. On top of it, when we analyze government malware, we don't see some weird calls to rand_s. We just see a few zero-days, exploits for known issues, or just plain-jane trojans. Why compromise rand_s, which could help our enemies and cause a public outcry, when you're sitting on a mountain of zero days? Also, windows is not closed source. MS shares source with governments, universities, etc. I think functions like rand_s are well understood and there has never been an MS backdoor for the government.

by dangero 13y ago

stinos 13y ago

It sure is, but how would they do that practically? I'm not saying it's impossible, but I really wonder how they would approach this. Call Ballmer and tell him to slip in a new CRT with the next Windows update providing a targetted version seems like a long shot. And even it works they would only target a (possibly small) subset of all machines since there's enough of them that aren't updated and there's enough software out there that ships with it's own copy of msvcrxx.dll

tptacek 13y ago

Closed source isn't a significant obstacle to understanding code, and Microsoft's code is the most comprehensively reverse-engineered in the industry. It would be extremely stupid to hide a backdoor in binaries that Microsoft ships.

nly 13y ago
Unless the backdoor was so incredibly subtle and hard to spot that it could be hand-waved away as a bug should it turn up.
- tptacek 13y ago
  It is actually easier to perpetrate that kind of subtlety in higher-level languages than in assembly.
  - caf 13y ago
    It can't be, because a valid way to detect such underhandedness in a higher-level language is to compile it to assembly and check that.
pnathan 13y ago
Calling attention to this: disassembly is a thing. It is entirely possible to reconstruct a program's design and logic from the disassembled code. This is what software crackers and antivirus writers do on a regular basis. For an enlightening write-up, see the Symantec paper(s) on Stuxnet.
- ars_technician 13y ago
  Right, but it's harder to detect subtle manipulation. It only takes a one bit error to reduce the key space by half.
  - tptacek 13y ago
    It is hard to detect subtle manipulation period. But assembly language is an extremely concrete representation of a program; it is not an especially great way to write underhanded code. It's possible to write obfuscated assembly, of course, but it sticks out as obfuscated. To further get your head around the lack of cover compiled code would give a backdoor, it's worth knowing that Hopper will give you serviceable C-ish code from x86_64 for... let me check here... fifty nine bucks. (It's possible that my only message with that last graf is "Hopper is great").
    - pg_is_a_butt 13y ago
      assembly language is not an extremely concrete representation of a program if the hardware is engineered with backdoors which is exactly what this article suggests is happening. if some specific set of registers is set a certain way followed by a very specific series of commands, there is no practical way to prove that the hardware is doing what it should.
      - tptacek 13y ago
        You are talking about a wildly different threat model than this little section of the thread is talking about. Meanwhile: if you can't trust the hardware, you can't trust C code either.
dangero 13y ago
I'm aware that programs can be disassembled and I have written x86 assembly myself. If closed source is not a significant barrier to completely understanding s_rand then I ask for one reference to someone who has completely audited the Windows 7/Windows 8 version of s_rand, and CryptGenRandom that s_rand calls. If you look on the related Wikipedia page what you find that there was an audit done of the Windows 2000 version of CryptGenRandom (which s_rand uses), and it was discovered to be flawed in a number of ways. The follow up is that Microsoft said that the issues were fixed in Vista. It's more than a theory that s_rand vulnerabilities will be called "bugs". It already happened once. http://en.wikipedia.org/wiki/CryptGenRandom http://en.wikipedia.org/wiki/CryptGenRandom

salient 13y ago

Microsoft shares all vulnerabilities with NSA as soon as they find out about them, and long before they fix them, anyway, which is like giving them access to a lot of backdoors into Windows. Adding one more from rand_s doesn't change the situation that much. Then there's TPM and all that other fun stuff. Until Microsoft overhauls their Windows security policies, you can never really trust Windows to keep you safe, even with the latest updates.

drzaiusapelord 13y ago

MS shares information with intelligence agencies and usually before MS has even delivered a patch. On top of it, when we analyze government malware, we don't see some weird calls to rand_s. We just see a few zero-days, exploits for known issues, or just plain-jane trojans. Why compromise rand_s, which could help our enemies and cause a public outcry, when you're sitting on a mountain of zero days? Also, windows is not closed source. MS shares source with governments, universities, etc. I think functions like rand_s are well understood and there has never been an MS backdoor for the government.