4 ms·
It's sad that he didn't mention the obvious solution that would have caught this problem: running valgrind or Thread Sanitizer. (Yes, you will have to create a
by colin_mccabe 13y ago
It's sad that he didn't mention the obvious solution that would have caught this problem: running valgrind or Thread Sanitizer.
(Yes, you will have to create a build with OpenSSL's custom allocator disabled to get a full run. No, it isn't hard.)
- antirez 13y agoValgrind is covered in 2 of the 5 points of the blog post.
- gizmo686 13y agoValgrind alone wouldn't have caught this bug. You would also need to trigger the bug, which would involve either specifically testing for it, or sending randomly invalid requests hoping to hit bugs. Granted, security software should be tested against invalid requests.
- colin_mccabe 13y agoI think you are greatly exaggerating how hard it is to find invalid memory use in openssl. According to Ted Unangst, all you have to do is turn off the custom allocator in openssl to immediately hit a use-after-free bug. He writes: "This bug would have been utterly trivial to detect when introduced had the OpenSSL developers bothered testing with a normal malloc (not even a security focused malloc, just one that frees memory every now and again). Instead, it lay dormant for years until I went looking for a way to disable their Heartbleed accelerating custom allocator." http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse http://www.tedunangst.com/flak/post/analysis-of-openssl-free...
- gizmo686 13y agoThe bug he is referring to is not in heartbeat, but rather in OpenSSL's use of its own allocator. I am not claiming that it would be difficult to find invalid memory usage in OpenSSL, rather I am claiming that the particular invalid usage that led to heartbleed would be difficult to find, becuase it does not occur under normal circumstances.