On Thu, Jan 10, 2019 at 8:50 AM Jesper Louis Andersen < jesper.louis.ander...@gmail.com> wrote:
> On Wed, Jan 9, 2019 at 7:55 PM 'Thomas Bushnell, BSG' via golang-nuts < > golang-nuts@googlegroups.com> wrote: > >> >> I'm curious about why transpilation would have significantly mitigated >> the Heartbleed bug. >> >> > Heartbleed is a bug which relies on two things: > > - Failure to do proper bounds checking > - Allocation of a buffer which is not initialized to some zero-value, and > which straddles memory it shouldn't. > > Many programming languages are constructed such that they address both of > the above problems at the semantics level, and thus they avoid the really > dangerous part of the bug, which is the leak of information, downgrading > the bug to a denial of service attack, or even also mitigating that part of > the bug. Array access is checked against the arrays bounds, and buffer > allocated memory is properly 0-initialized before use. > I'm not sure the second one here is right. Heartbleed does not depend on unitialized memory as far as I can tell. It works to copy whatever lies after the incoming request buffer back to the attacker. It happens that in the actual openssl code the thing it's copying is a reused buffer that might have stuff in it (IIRC), but that's not essential to the operation of the bug. If it were an exactly sized buffer the same shape of problem would occur. I don't think you responded to my email very successfully. You left unaddressed: * How would this magical translation going to occur, given the actual code of openssl? The obvious *human *translation is to allocate a request buffer, and then use the encoding/binary package to pull values. The attempt to read indexes greater than the size of the buffer would fault. But I don't see a way to take code like openssl and automatically make it use encoding/binary. The only clear way I can see to do it *automatically *is to use unsafe.Pointer, which simply turns off all the bounds checking you wanted. * Even if we did this, the bug only turns into a packet of death. A packet of death on this scale is of almost the same level of annoyance and chaos. (Witness this week's firestorm about an email packet of death on some Cisco something or other.) Thomas -- memegen delenda est -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
