> Maybe in your imaginary world where your malloc() library is a static code > correctness analysis tool instead of a behavioral anomaly detection tool. > > The fact remains that this was a boundary error triggered by incorrect user > input validation--that it would not crash under any circumstances where > 100% of all OpenSSL code besides this very small block of code was 100% > correct unless it was actively exploited. > > Normal heartbeats stay within correct bounds and function correctly: 100 > bytes are allocated, the payload says it's 100 bytes, 100 bytes are read, > no boundaries are exceeded. > > Apparently nobody did any testing or peer review that involved saying, "Oh, > shit. You actually send the length of a piece of user-supplied data WITH > user-supplied data? I hope you're checking for any kind of stupid shit the > user may do, like ask you to copy 5000 bytes of data into a 50 byte buffer > and inject code, or something." If they did, they would have seen that they > sent a 4 byte long heartbeat with a payload length of 10, and got back 10 > bytes, and wondered where the hell 10 bytes came from.
The range checking is happening inside dynamically allocated memory. I suspect Mr. Segglemann did run a simple test with all the sizes, but the daemon did not crash on him.... because the allocation scheme disables an increasingly common safetybelt for dynamically allocated memory. If he didn't do such a test, you would be the one calling him incompetent. This OpenBSD malloc safety belt is also included in many programming test tools. Surely someone ran those in the last two years. Unfortunately, the OpenSSL freelist foils them all, because inside the program full scope the objects remain "live". You seem to understand bugs from the top down. But you don't understand that we can resist them from the bottom up, essentially free. Unless people overly complicate their own software to make security assessment impossible.
