On Thu, Jan 10, 2019 at 6:26 PM Thomas Bushnell, BSG <tbushn...@google.com> wrote:
> 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. > > Well, if there is no way to reuse a buffer in the language, then things will work out. More or less any functional language will do. > 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. > > I think the problem is a good research question. I don't think we have a good solution at the moment. But there is a lot of value in pushing the research forward in the area. So the answer to this question is: "I don't know, but I do have ideas where I would start". > * 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.) > > I did address this. If each request is bounds checked and memory isolated, then a failure is just an exception of some kind and we handle this as we would any other exception. You could also just fork the process for each incoming request and obtain the same semantics. -- 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.
