4 ms·

> And its discovery and resolution highlights one of the advantages of open-source software development. I wouldn't say that its discovery (two years later) sa

> And its discovery and resolution highlights one of the advantages of open-source software development. I wouldn't say that its discovery (two years later) says anything good about open source development.

deleted 12y ago
[deleted]
- tptacek 12y ago
  The same amount of time: it was apparently found with a fuzzer.
  - baddox 12y ago
    What about the relative ease and speed with which the bug was fixed? Fuzz testing could certainly find the bug in closed source software, but patching it is a different story, especially if the person or group that controls the source code is slow, uncooperative, or extinct.
    - tptacek 12y ago
      It was definitely easier to fix because it was open.
    - hackinthebochs 12y ago
      However, the software being open source aided those who may have rushed out to take advantage of still-vulnerable systems. It's a mixed bag both ways, lets not put blinders on for ideological reasons.
      - nitrogen 12y ago
        Ideology is the most important reason to choose open source and free software -- the ability to inspect and learn from the code is paramount, regardless of whether the software is superior or inferior to some other closed product.
  - rurban 12y ago
    I'm not so sure about the fuzzer. We have several good symbolic fuzzers around by ourselves, like fuzzgrind, but not so many open symbolic bug finders, like BAP, MAYHEM, EXE, forensic, cmbc. It could also be that they just added symbolic annotations like with Frama-C (as done with portalssl) and found bugs thereby. openssl nor gnutls is not in the shape to add something like this by themselves. It's much easier to come up with workable exploits in decent time with symbolic input and the stp or z3 solver than with simple fuzzing.
  - hf 12y ago
    I didn't know about fuzzers before this whole imbroglio -- not denoted as such, at least. If you know `crashme` you already know one fuzzer, which "intended to test the robustness of Unix and Unix-like operating systems by executing random machine instructions." See https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing As a good app-sec'er you seem to need to be deeply steeped in fuzzer lore. Matasano: "We'll have you write a fuzzer. Everyone here writes fuzzers." http://www.matasano.com/careers/ http://www.matasano.com/careers/ (I'm obviously not replying to tptacek, just highlighting a bit. ... And basking in the good glow, yes.)
TallGuyShort 12y ago
And I also wouldn't say that the existence of a bug was caused by the license that was used. It's not like me keeping all the code to myself would make me a better programmer.
- deleted 12y ago
  [deleted]
  - drcube 12y ago
    >> Well, if you were keeping all the code to yourself you presumably wouldn't be accepting poorly reviewed patches from random people. How does this follow? You can just as easily hire "random people" to make mistakes as you can accept mistakes from people you don't pay. The problem is poorly reviewed code either way. Not the license.
    - deleted 12y ago
      [deleted]
lafayette 12y ago
I might be completely wrong but I don't see much difference between open source and closed source in this case. If I were biased I might say that it might have taken substantially longer to discover such a bug in closed source software but that seems to be as much sensible as saying that open source has less security bugs because more people look at the same code. In the end software is written by people and people make mistakes. I'm pretty sure there are a lot of software be it open or closed source that had absolutely terrible security bugs. Judging open source as a whole by looking at a single project sounds a little bit like overgeneralization. Also, they are obviously in need of help though, I hear a lot of complaints from people about the OpenSSL code.

deleted 12y ago

[deleted]

tptacek 12y ago
The same amount of time: it was apparently found with a fuzzer.
- baddox 12y ago
  What about the relative ease and speed with which the bug was fixed? Fuzz testing could certainly find the bug in closed source software, but patching it is a different story, especially if the person or group that controls the source code is slow, uncooperative, or extinct.
  - tptacek 12y ago
    It was definitely easier to fix because it was open.
  - hackinthebochs 12y ago
    However, the software being open source aided those who may have rushed out to take advantage of still-vulnerable systems. It's a mixed bag both ways, lets not put blinders on for ideological reasons.
    - nitrogen 12y ago
      Ideology is the most important reason to choose open source and free software -- the ability to inspect and learn from the code is paramount, regardless of whether the software is superior or inferior to some other closed product.
- rurban 12y ago
  I'm not so sure about the fuzzer. We have several good symbolic fuzzers around by ourselves, like fuzzgrind, but not so many open symbolic bug finders, like BAP, MAYHEM, EXE, forensic, cmbc. It could also be that they just added symbolic annotations like with Frama-C (as done with portalssl) and found bugs thereby. openssl nor gnutls is not in the shape to add something like this by themselves. It's much easier to come up with workable exploits in decent time with symbolic input and the stp or z3 solver than with simple fuzzing.
- hf 12y ago
  I didn't know about fuzzers before this whole imbroglio -- not denoted as such, at least. If you know `crashme` you already know one fuzzer, which "intended to test the robustness of Unix and Unix-like operating systems by executing random machine instructions." See https://en.wikipedia.org/wiki/Fuzz_testing https://en.wikipedia.org/wiki/Fuzz_testing As a good app-sec'er you seem to need to be deeply steeped in fuzzer lore. Matasano: "We'll have you write a fuzzer. Everyone here writes fuzzers." http://www.matasano.com/careers/ http://www.matasano.com/careers/ (I'm obviously not replying to tptacek, just highlighting a bit. ... And basking in the good glow, yes.)

TallGuyShort 12y ago

And I also wouldn't say that the existence of a bug was caused by the license that was used. It's not like me keeping all the code to myself would make me a better programmer.

deleted 12y ago
[deleted]
- drcube 12y ago
  >> Well, if you were keeping all the code to yourself you presumably wouldn't be accepting poorly reviewed patches from random people. How does this follow? You can just as easily hire "random people" to make mistakes as you can accept mistakes from people you don't pay. The problem is poorly reviewed code either way. Not the license.
  - deleted 12y ago
    [deleted]

lafayette 12y ago

I might be completely wrong but I don't see much difference between open source and closed source in this case. If I were biased I might say that it might have taken substantially longer to discover such a bug in closed source software but that seems to be as much sensible as saying that open source has less security bugs because more people look at the same code. In the end software is written by people and people make mistakes. I'm pretty sure there are a lot of software be it open or closed source that had absolutely terrible security bugs. Judging open source as a whole by looking at a single project sounds a little bit like overgeneralization. Also, they are obviously in need of help though, I hear a lot of complaints from people about the OpenSSL code.