In message <[email protected]>, Alfred Hegemeier <[email protected]> wrote: >What a load of nonsense here: no, I don't think we should further extend th= >e boundaries of mathematical logic in order to avoid such bugs, and I don't= > think we should now change our programming habits and use the magic power = >of Haskell - I actually think, somebody should read the code that others pr= >ogram..especially if it is security related code, shouldn't anybody=A0 ?! = Having looked a little bit at the code in question, let me just say that I, for one, am not at all persuated that any traditional sort of human- based code review would have caught Heartbleed. The place where the buffer (which was much later on over-read) was allocated miles and miles away from the place where its contents... plus some other stuff... were being written back, verbatim, to the attacker. And as I pointed out (someplace, I forget where now) if *all* such buffers had been allocated to the maximum possible size in the first place... i.e. either 2^16 bytes or else only 2^14 if it was done properly, according to the spec... then there would never have been any problem. But at the place in the code where the response packet was being sent back, there were _two_ possible indicators of how much should be sent back, i.e. (1) the 16-bit _alleged_ original query packet payload size and (2) the actual original query packet payload size. And by that point in the code there was no clear reason at all to have any suspicion that the two wouldn't always be exactly equal, let alone that the former might actually be (fradulently) bigger than the latter. >This is a bug which children get taught to avoid when programming and how t= >o avoid, namely check the input, don't rely on the user entering a number b= >etween 1 and 10 even if you tell them, but check it, I don't think that the whole thing was really quite that simple. I think that the place where input packets were being received was built to be ``general purpose'' and that only these quirky keep-alive packets had an extra/additional 16-bit payload size field in them. The general purpose routine that read incoming packets couldn't have checked that 16-bit field for reasonablness because most of the input packets it would be reading wouldn't even have that field. I could be wrong about all this, but that was my impression, after skimming just some of the relevant code. (It certainly wasn't terribly easy to follow the code, but then I could say that about >90% of all code I've ever seen in my life... except my own, of course. :-) Regards, rfg _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"