Limit would end up being when you send 1 byte of traffic to a box and that box amplifies it to whatever its own max outbound bandwidth rate is.
This seems like it would exceed that in many cases, since 1 byte in => 4.2 gigabytes out. Which is roughly 33.6 gbps. Not sure many of these vulnerable boxes actually have that amount of outbound bandwidth to utilize.
(Please feel free to correct my quick math if I messed it up)
This is a good point, but then you need more boxes to perform the DDOS as the reason they are effective is overwhelming the packets per second or bandwidth per second of the receiving networks. So it definitely does allow for a sustained attack by a single box with limited outbound bandwidth, but that blunts the usual reasoning for why the amplification is so dangerous.
Another interesting impact of this is that the higher the amplification, the more likely it is noticeable by the server that is being abused. I mean if you clog the outbound network for a company they will notice and try to resolve immediately. Versus some milder amplification where it can go under the radar, or at least the business impact urgency radar of a company much longer.
How so? If I find a vector that triggers the remote system to `cat /dev/random | netcat $target` then there's no limit for how much traffic my refelection generates, no?
I assume by limit OP means the remote system's bandwidth.
at 4 billion to 1, there's in practice very little difference between CVE-2022-26143 and what you describe. Both will be capped at the same number by the bandwidth available to the offending system.
