7 ms·

> "It's not "just a bug". Yes, everyone makes mistakes, we're all human. But it's completely unacceptable that those mistakes get unnoticed and into production

> "It's not "just a bug". Yes, everyone makes mistakes, we're all human. But it's completely unacceptable that those mistakes get unnoticed and into production code of such a critical component, and deployed to millions of users." This is not a reasonable argument. At Pwn2Own each year, how many browsers have vulnerabilities that allow remote code execution? All of them. How many of these vulnerabilities are zero-days? A significant number of those. This happens every single year. Even the advanced protections in e.g. Chrome don't stop new vulnerabilities from being found on a regular basis. And all of these products are deployed to millions of users. You could complain about Apple's response to this bug, and that might be a reasonable complaint to make. At least Google patches bugs quickly when they surface at Pwn2Own. But that's different from claiming the bugs shouldn't have existed (or should have been caught before making it into production). Bugs are fundamentally hard to find, and it's not really getting any easier.

ambrop7 13y ago
As I said: It's not just another security bug. It's an easy to spot bug, in the most critical part of the code, of a fundamental security library. THIS is what makes it unacceptable. It pretty much means the change has never gone through code review, or has been planted.
- res0nat0r 13y ago
  While working at AWS and seeing outages being posted here, and the wildly inaccurate summaries (guesses) of what the problems were, and the wildly simplistic fixes that are assumed to easily be put in place I can say: systems like this are more complicated than you think they are.
  - renaudg 13y ago
    A huge +1 to this, from someone who worked at Facebook.
  - nicholassmith 13y ago
    Agreed, everyone enjoys playing armchair critic and in the majority of the time have no idea how the internal systems are structured or managed.
- sbuk 13y ago
  > “It pretty much means that the change has never gone through code review, or has been planted.” Or Hanlon's Razor; “Never attribute to malice that which is adequately explained by stupidity.” Going straight to dumb-ass conspiracy theories it what is unacceptable.
  - ambrop7 13y ago
    Hence the "or". In this case, stupidity is equally unacceptable.
    - sbuk 13y ago
      No. To err is human. In the grand scheme of things, it's a PR fuck up; nothing more. I doubt it affects you directly enough as a Gentoo user to have such a strong reaction anyway, but if it make you feel superior, then all power to you. Lighten up and have a look at this and ask your self if you have honestly never done the same thing: http://xkcd.com/292/ http://xkcd.com/292/ if you think you haven't, I can gaur tee that you are deluding yourself...
      - sneak 13y ago
        The error is not that of the programmer's. The fault is not in code, it's in processes that were chosen by management. Indeed, to err is human. This is why you're a negligent jackass if you don't plan for errors and build multiple systems to prevent and detect them, at least until computers start programming themselves for us.
ambrop7 13y ago
I am interested to hear your opinion: at what point should a vulnerability be considered unacceptable?
- craigyk 13y ago
  part of growing up is learning to become the kind of hypocrite you can live with. if you think you operate and hold yourself to a much higher standard then go ahead and complain all you want. maybe you do... maybe
- bandushrew 13y ago
  I dont even know what that would mean, to make an existing vulnerability 'unacceptable'. Vulnerabilities of all kinds exist. We need to find them, learn from them and we need to fix them. Getting hung up on whether or not they are 'acceptable' is just kind of weird. Bad stuff happens, incompetence happens, mistakes happen. None of that is 'acceptable', but it happens just the same. Creating an environment where some kinds of mistakes are 'unacceptable' doesn't eliminate those kinds of mistakes, it just causes people to stop reporting them. Complaining about their release cycle makes some sense. complaining about the existence of an existing bug is basically just howling at the moon.
aethr 13y ago
While it's true that almost all software has bugs that can result in exploits, I think most of the exploits used in Pwn2Own are typically the result of complex interactions between subsystems that are hard to predict. As software gets more complex, the attack surface increases. The Apple bug isn't really in that class of exploit. It's a simple coding/merge error, and it's actually a regression from previously working code. One of the things that worries me is that this bug would have been caught so easily with basic unit tests. Test 1: Make connection to server with a valid SSL certificate [PASSED] Test 2: Make connection to a server with an invalid SSL certificate [FAILED] Are we meant to think that Apple's build process doesn't use unit testing? Seems unlikely. Or perhaps this component didn't warrant an extensive test suite? I hope not! Not really sure what the explanation is. I mean, I certainly can't claim that all my code is run through extensive tests before every deploy, but then I'm not working on the security tools that underpin an entire operating system.
- sneak 13y ago
  Two entire operating systems.
  - pritambaral 13y ago
    One single library.
- phlo 13y ago
  In this case, the very test you're describing would not have worked. For a better writeup, see agl's post[1] on the matter. The basic gist of it: On affected systems, the server may use any combination of private key and certificate. Most SSL libraries used on the server side will make sure the moduli of cert and private key match (and abort if this isn't the case). Unit testing would thus require a server with some modifications to its SSL library (OpenSSL, in most cases). What would have caught the bug: automatic code indentation or any sort of compile-time warnings about dead code. [1] https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html
  - 13y ago
cbsmith 13y ago
This is so different from Pwn2Own I don't even know where to start. This failure case shows up in the most basic test case of what the library is supposed to do. The whole point of having certificate validation is that you identify invalid certificates. Try to come up with a reason why there are no regression tests with the library and why there wasn't a regression test that verified that for the default case, an invalid certificate was reported as such.

ambrop7 13y ago

As I said: It's not just another security bug. It's an easy to spot bug, in the most critical part of the code, of a fundamental security library. THIS is what makes it unacceptable. It pretty much means the change has never gone through code review, or has been planted.

res0nat0r 13y ago
While working at AWS and seeing outages being posted here, and the wildly inaccurate summaries (guesses) of what the problems were, and the wildly simplistic fixes that are assumed to easily be put in place I can say: systems like this are more complicated than you think they are.
- renaudg 13y ago
  A huge +1 to this, from someone who worked at Facebook.
- nicholassmith 13y ago
  Agreed, everyone enjoys playing armchair critic and in the majority of the time have no idea how the internal systems are structured or managed.
sbuk 13y ago
> “It pretty much means that the change has never gone through code review, or has been planted.” Or Hanlon's Razor; “Never attribute to malice that which is adequately explained by stupidity.” Going straight to dumb-ass conspiracy theories it what is unacceptable.
- ambrop7 13y ago
  Hence the "or". In this case, stupidity is equally unacceptable.
  - sbuk 13y ago
    No. To err is human. In the grand scheme of things, it's a PR fuck up; nothing more. I doubt it affects you directly enough as a Gentoo user to have such a strong reaction anyway, but if it make you feel superior, then all power to you. Lighten up and have a look at this and ask your self if you have honestly never done the same thing: http://xkcd.com/292/ http://xkcd.com/292/ if you think you haven't, I can gaur tee that you are deluding yourself...
    - sneak 13y ago
      The error is not that of the programmer's. The fault is not in code, it's in processes that were chosen by management. Indeed, to err is human. This is why you're a negligent jackass if you don't plan for errors and build multiple systems to prevent and detect them, at least until computers start programming themselves for us.

ambrop7 13y ago

I am interested to hear your opinion: at what point should a vulnerability be considered unacceptable?

craigyk 13y ago
part of growing up is learning to become the kind of hypocrite you can live with. if you think you operate and hold yourself to a much higher standard then go ahead and complain all you want. maybe you do... maybe
bandushrew 13y ago
I dont even know what that would mean, to make an existing vulnerability 'unacceptable'. Vulnerabilities of all kinds exist. We need to find them, learn from them and we need to fix them. Getting hung up on whether or not they are 'acceptable' is just kind of weird. Bad stuff happens, incompetence happens, mistakes happen. None of that is 'acceptable', but it happens just the same. Creating an environment where some kinds of mistakes are 'unacceptable' doesn't eliminate those kinds of mistakes, it just causes people to stop reporting them. Complaining about their release cycle makes some sense. complaining about the existence of an existing bug is basically just howling at the moon.

aethr 13y ago

While it's true that almost all software has bugs that can result in exploits, I think most of the exploits used in Pwn2Own are typically the result of complex interactions between subsystems that are hard to predict. As software gets more complex, the attack surface increases. The Apple bug isn't really in that class of exploit. It's a simple coding/merge error, and it's actually a regression from previously working code. One of the things that worries me is that this bug would have been caught so easily with basic unit tests. Test 1: Make connection to server with a valid SSL certificate [PASSED] Test 2: Make connection to a server with an invalid SSL certificate [FAILED] Are we meant to think that Apple's build process doesn't use unit testing? Seems unlikely. Or perhaps this component didn't warrant an extensive test suite? I hope not! Not really sure what the explanation is. I mean, I certainly can't claim that all my code is run through extensive tests before every deploy, but then I'm not working on the security tools that underpin an entire operating system.

sneak 13y ago
Two entire operating systems.
- pritambaral 13y ago
  One single library.
phlo 13y ago
In this case, the very test you're describing would not have worked. For a better writeup, see agl's post[1] on the matter. The basic gist of it: On affected systems, the server may use any combination of private key and certificate. Most SSL libraries used on the server side will make sure the moduli of cert and private key match (and abort if this isn't the case). Unit testing would thus require a server with some modifications to its SSL library (OpenSSL, in most cases). What would have caught the bug: automatic code indentation or any sort of compile-time warnings about dead code. [1] https://www.imperialviolet.org/2014/02/22/applebug.html https://www.imperialviolet.org/2014/02/22/applebug.html
- 13y ago

cbsmith 13y ago

This is so different from Pwn2Own I don't even know where to start. This failure case shows up in the most basic test case of what the library is supposed to do. The whole point of having certificate validation is that you identify invalid certificates. Try to come up with a reason why there are no regression tests with the library and why there wasn't a regression test that verified that for the default case, an invalid certificate was reported as such.