> The moment this went out, some blackhat may have secretly analyzed the > diff between 1.0 and 1.0.1 and gone, "Oh lol!" Or maybe saw the new > support for TLS Heartbeat and gone, "Hey man, a new feature. I bet I > can break it!" Security researchers took until 1.0.1f to do this.
Even before heartbeat arrived, it would have crashed with the stupid openssl allocator turned off. Try it. Compile libssl with -DDOPENSSL_NO_BUF_FREELIST Start nginx, put it under some heavy service. Look at the logs. See how bad things start to happen? Had the non-freelist code path been tested in OpenBSD OR ANYWHERE ELSE, it would have alerted the entire world that there are use-after-free's in other code paths. And the use-after-free's would have been fixed. They would not be able to hide. OpenSSL would have had a robust internal memory allocator. In the context of security software, robust means fail-hard, fail-closed, when any unexpected condition is triggered. That bad feature was added in 2006 and fully entrenched by 2008. More recently, the heartbeat feature was added, and if a hard system allocator was available, the initial testing would probably have exposed the problem right during the development cycle. Then it would have been fixed before deployment. But I think it is clear you aren't a programmer, and this is over your head. Or you are simply making excuses for others. Did they pay you to write all that text?
