4 ms·
I have a question that hopefully someone can clear up for me. If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to b
by AndyMcConachie 11y ago
I have a question that hopefully someone can clear up for me.
If I understand the Google sec article correctly, this requires a single packet > 2048 bytes to be received by a host using glibc.
> The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack.
Is my understanding correct?
If it is, then it's worth pointing out that many links on the public Internet have an MTU of 1500 bytes. This is an historical legacy of original Ethernet from the 80's. Path-MTU-Detection(PMTUD) doesn't really work on the Internet, so it's safest to assume that you only ever get 1500 bytes.
Given all that, this places a burden on anyone wanting to eploit this. Since they cannot assume a PMTU greater than 1500 bytes between endpoints, they're limited in how they can exploit the bug. Correct?
Please correct me if I'm wrong. I always feel these bug reports are missing that vital piece of information I need to operationalize the bug. And thanks.
- sveiss 11y agoDatagrams larger than the MTU can be sent, they'll just be fragmented. The point of PMTU is to avoid fragmentation where necessary, but it's still possible.
- AndyMcConachie 11y agoSometimes datagrams larger than 1500 bytes can be sent, sometimes they won't reach their destination. Fragmentation doesn't really work, and at the very least will almost always ensure out-of-order delivery. Either way you can't depend on it. PMTUD doesn't work at all on the modern Internet, not for IPv4, and not for IPv6. So again, I'm just wondering how dangerous this exploit really is. I'm not saying it isn't dangerous, I'm saying our understanding of it should be tempered somewhat due to many links not fragmenting properly that have MTUs of 1500 bytes.