6 ms·

Tptacek, it is scary because of exactly that -- it is so simple. How could such a secure platform built by such a massively large cap tech company do something

Tptacek, it is scary because of exactly that -- it is so simple. How could such a secure platform built by such a massively large cap tech company do something so incredibly stupid in its most critical security stack. If this trivial bug can happen and pushed into production .. Good lord, anything can happen. The foundation of our mobile economy has just been proven to be on very very shaky legs.

thirsteh 13y ago
It would be nice if massive meant "more secure," but the real relationship is not between an organization's size and its security, rather it's about how much that organization tries to minimize, or displace, risk. Very large organizations tend to not specifically care that something is provably secure so much as they want contractor X to be liable if something bad happens because of it. Some organizations--and even though it's easy to mock Apple here, I do believe they're one of them--sufficiently appreciate that improving security minimizes risk, and so spend a decent amount of money on it. You could argue they failed here, but even Adam Langley who essentially "is SSL" at Google admits he's not sure they have a test that simulates an attack on a possible similar implementation error in their own code (though he does argue that such an error would have been caught in Google's code review process.) In any case, an attention to security is certainly not something that is borne out of an organization's revenue or number of employees.
- cbhl 13y ago
  I'm under the impression that Apple prides itself on having a smaller number of very dedicated employees that are perfectionists. I can totally see this being "innocent 2AM mis-judgement call by a single employee", judging from what my peers tell me of Apple's corporate culture. I do think that Adam Langley's suggestion that code review would help is plausible, but it merely just means that more than one person has to make the same mistake in a judgement call. (It reduces the probability of such an error happening; it doesn't theoretically eliminate it.)
  - Create 13y ago
    I can totally see this being "innocent 2AM mis-judgement call by a single employee", judging from what my peers tell me of Apple's corporate culture. https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT5780/Crypto_Officer_Role_Guide_for_FIPS%20140-2_Compliance_iOS_6.pdf https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT... We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites Sta tes government has led not only us but the world. This should not actually be a complicated inquiry. http://snowdenandthefuture.info/events.html http://snowdenandthefuture.info/events.html
    - cbhl 13y ago
      FIPS 140-2 certification isn't remotely an indication of correctness of code, for better or worse. Take, for example, the implementation Dual EC DRBG in the FIPS 140-2 certified OpenSSL module -- it was fatally flawed, and has never worked in practice. (It will be removed from the next version of the module in light of developments in the past year.) https://lwn.net/Articles/578375/ https://lwn.net/Articles/578375/
terminus 13y ago
> The foundation of our economy has just been proven to be on very very shaky legs. Exactly. That sums up my feelings about it better than I could. Something so critical, something trivially easy to catch in a code review was not caught. And, the only scenario in which a code review might not have caught it: no code review. That's no code review for libssl. If this is incompetence and not malice, it's incompetence of monumental proportions.
- zorked 13y ago
  No. No. No. Code reviews only mean your code is going through two sieves instead of one. Of course it helps. But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.
  - terminus 13y ago
    > But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place. Did you look at the bug? I'll quote it here: if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; Even somebody with basic programming skills can see that's wrong. And, remember this is libssl. Any checkins to that warrant thoroughness if not paranoia.
    - pixl97 13y ago
      Interesting, does this mean if you were using an updated SHA256 hash (as will be required soon for all EV certs) that the exploit would not have occurred?
    - stormbrew 13y ago
      In the CR tool I assume it may have looked more like this: if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; - if ((err = SSLHashSHA1.update(&hashCtx, &somethingElse)) != 0) goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; Which is a little harder to see. Obviously you should always look at it in a side-by-side view (god I wish github would implement this) or at the resulting code, but people are imperfect.
deleted 13y ago
[deleted]
yeukhon 13y ago
> do something so incredibly stupid in its most critical security stack. I disagree. We are human. We are not divine. We do stupid things and we can write stupid infinite loop or off-by-1 and the bug will live for a decade. I am sure you have written a program which can be easily exploited and you know that it is such a trivial bug.
- blazespin 13y ago
  Yes, the programmer is only human. But the vp of engineering should have had a budget and process that would not let this slip through.
  - yeukhon 13y ago
    Are you saying they should have extra people doing code review - requires two instead of 1 (I don't know the number, but assume that's the norm). Or more rigorous testing technique? I am all for it. Is this something they can easily discover through automated testing?
    - DanBC 13y ago
      having extra people doing code review risks something that happens with physical products. You take the experienced people off the shop floor, and call them inspectors. So now the quality of product coming off the shop floor is worse. Ann is the first inspector in the chain. When she's busy (and remember, she will be because quality has dropped) she might be tempted to let a few things go because Bob, the second inspector in the chain, is bound to catch them. That's what he's there for. Bob is the second inspector in the chain. Sometimes Ann really churns the product through. Luckily during those busy times he knows she's already inspected the stuff, so he only needs to give a 10% inspection. So you have worse product with more errors and leaky inspection. Ideally you'd have a system with skilled workers and self inspection. That's okay for aerospace (which pays well) but not so great for lower cost product. Not quite sure how this transfers to coding.
      - 13y ago
tptacek 13y ago
This is a comment that seems to suggest that it's abnormal for dumb bugs to cause huge security problems. It is not. If the foundation of our economy is C software security, well, hate to break it to you, but...
- brudgers 13y ago
  What strikes me is that the bug looks like a typo but it implements a logic error and that logic error pretty much negates everything the library represents itself as doing and what the library represents itself as doing is providing a foundation upon which signals security relies. Suppose a contractor was hired by the NSA to write an exploit with equivalent function. How could it be crafted more cleverly?
- blazespin 13y ago
  It is absolutely abnormal for companies like Apple to release core security bugs this shallow that could have been easily discovered by straightforward unit tests and static analysis tools. This is why it's a big deal.
  - f_salmon 13y ago
    The other reason why this is no big deal (anymore) is that the Snowden leaks have shown that the NSA has total control over all iPhones. Why should we even bother talking about bugs like this anymore? Pure distraction.
    - oneeyedpigeon 13y ago
      Which is worse: the NSA having total control over all iPhones (citation? I obviously haven't been paying enough attention), or the NSA and all the (other) bad guys in the world having total control ...? Sure, they're both terrible, but I'd take the former over the latter.
    - kalleboo 13y ago
      > the Snowden leaks have shown that the NSA has total control over all iPhones You mean: had total control over all the original iPhones that they could get physical access to. (back when jailbreaking was extremely simple and common)
deleted 13y ago
[deleted]

thirsteh 13y ago

It would be nice if massive meant "more secure," but the real relationship is not between an organization's size and its security, rather it's about how much that organization tries to minimize, or displace, risk. Very large organizations tend to not specifically care that something is provably secure so much as they want contractor X to be liable if something bad happens because of it. Some organizations--and even though it's easy to mock Apple here, I do believe they're one of them--sufficiently appreciate that improving security minimizes risk, and so spend a decent amount of money on it. You could argue they failed here, but even Adam Langley who essentially "is SSL" at Google admits he's not sure they have a test that simulates an attack on a possible similar implementation error in their own code (though he does argue that such an error would have been caught in Google's code review process.) In any case, an attention to security is certainly not something that is borne out of an organization's revenue or number of employees.

cbhl 13y ago
I'm under the impression that Apple prides itself on having a smaller number of very dedicated employees that are perfectionists. I can totally see this being "innocent 2AM mis-judgement call by a single employee", judging from what my peers tell me of Apple's corporate culture. I do think that Adam Langley's suggestion that code review would help is plausible, but it merely just means that more than one person has to make the same mistake in a judgement call. (It reduces the probability of such an error happening; it doesn't theoretically eliminate it.)
- Create 13y ago
  I can totally see this being "innocent 2AM mis-judgement call by a single employee", judging from what my peers tell me of Apple's corporate culture. https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT5780/Crypto_Officer_Role_Guide_for_FIPS%20140-2_Compliance_iOS_6.pdf https://support.apple.com/library/APPLE/APPLECARE_ALLGEOS/HT... We begin therefore where they are determined not to end, with the question whether any form of democratic self-government, anywhere, is consistent with the kind of massive, pervasive, surveillance into which the Unites Sta tes government has led not only us but the world. This should not actually be a complicated inquiry. http://snowdenandthefuture.info/events.html http://snowdenandthefuture.info/events.html
  - cbhl 13y ago
    FIPS 140-2 certification isn't remotely an indication of correctness of code, for better or worse. Take, for example, the implementation Dual EC DRBG in the FIPS 140-2 certified OpenSSL module -- it was fatally flawed, and has never worked in practice. (It will be removed from the next version of the module in light of developments in the past year.) https://lwn.net/Articles/578375/ https://lwn.net/Articles/578375/

terminus 13y ago

> The foundation of our economy has just been proven to be on very very shaky legs. Exactly. That sums up my feelings about it better than I could. Something so critical, something trivially easy to catch in a code review was not caught. And, the only scenario in which a code review might not have caught it: no code review. That's no code review for libssl. If this is incompetence and not malice, it's incompetence of monumental proportions.

zorked 13y ago
No. No. No. Code reviews only mean your code is going through two sieves instead of one. Of course it helps. But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place.
- terminus 13y ago
  > But there is no guarantee of anything unless the reviewer is incapable of making mistakes, in which case you could just ask him to write the code in the first place. Did you look at the bug? I'll quote it here: if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; Even somebody with basic programming skills can see that's wrong. And, remember this is libssl. Any checkins to that warrant thoroughness if not paranoia.
  - pixl97 13y ago
    Interesting, does this mean if you were using an updated SHA256 hash (as will be required soon for all EV certs) that the exploit would not have occurred?
  - stormbrew 13y ago
    In the CR tool I assume it may have looked more like this: if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; - if ((err = SSLHashSHA1.update(&hashCtx, &somethingElse)) != 0) goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail; Which is a little harder to see. Obviously you should always look at it in a side-by-side view (god I wish github would implement this) or at the resulting code, but people are imperfect.

deleted 13y ago

[deleted]

yeukhon 13y ago

> do something so incredibly stupid in its most critical security stack. I disagree. We are human. We are not divine. We do stupid things and we can write stupid infinite loop or off-by-1 and the bug will live for a decade. I am sure you have written a program which can be easily exploited and you know that it is such a trivial bug.

blazespin 13y ago
Yes, the programmer is only human. But the vp of engineering should have had a budget and process that would not let this slip through.
- yeukhon 13y ago
  Are you saying they should have extra people doing code review - requires two instead of 1 (I don't know the number, but assume that's the norm). Or more rigorous testing technique? I am all for it. Is this something they can easily discover through automated testing?
  - DanBC 13y ago
    having extra people doing code review risks something that happens with physical products. You take the experienced people off the shop floor, and call them inspectors. So now the quality of product coming off the shop floor is worse. Ann is the first inspector in the chain. When she's busy (and remember, she will be because quality has dropped) she might be tempted to let a few things go because Bob, the second inspector in the chain, is bound to catch them. That's what he's there for. Bob is the second inspector in the chain. Sometimes Ann really churns the product through. Luckily during those busy times he knows she's already inspected the stuff, so he only needs to give a 10% inspection. So you have worse product with more errors and leaky inspection. Ideally you'd have a system with skilled workers and self inspection. That's okay for aerospace (which pays well) but not so great for lower cost product. Not quite sure how this transfers to coding.
    - 13y ago

tptacek 13y ago

This is a comment that seems to suggest that it's abnormal for dumb bugs to cause huge security problems. It is not. If the foundation of our economy is C software security, well, hate to break it to you, but...

brudgers 13y ago
What strikes me is that the bug looks like a typo but it implements a logic error and that logic error pretty much negates everything the library represents itself as doing and what the library represents itself as doing is providing a foundation upon which signals security relies. Suppose a contractor was hired by the NSA to write an exploit with equivalent function. How could it be crafted more cleverly?
blazespin 13y ago
It is absolutely abnormal for companies like Apple to release core security bugs this shallow that could have been easily discovered by straightforward unit tests and static analysis tools. This is why it's a big deal.
- f_salmon 13y ago
  The other reason why this is no big deal (anymore) is that the Snowden leaks have shown that the NSA has total control over all iPhones. Why should we even bother talking about bugs like this anymore? Pure distraction.
  - oneeyedpigeon 13y ago
    Which is worse: the NSA having total control over all iPhones (citation? I obviously haven't been paying enough attention), or the NSA and all the (other) bad guys in the world having total control ...? Sure, they're both terrible, but I'd take the former over the latter.
  - kalleboo 13y ago
    > the Snowden leaks have shown that the NSA has total control over all iPhones You mean: had total control over all the original iPhones that they could get physical access to. (back when jailbreaking was extremely simple and common)

deleted 13y ago

[deleted]