News for hackers. Stuff that matters.
Re:The AWS S3 Denial of Wallet Amplification Attack by fabian2k on Wednesday May 01, 2024 @05:19PM (#40229608)
The part where I think there is some flexibility is about the difference between "bytes attempted to transfer" and "bytes actually transferred". I think it is pretty fair to bill for the former, as long as you abort requests in a reasonable way. So I don't expect it to be billed exactly by the transferred byte, but I do expect it to not go above that higher than whatever the chunk size for transferring is.
Re:The AWS S3 Denial of Wallet Amplification Attack by klabb3 on Wednesday May 01, 2024 @06:25PM (#40230362)
That’s an orthogonal issue. There’s no interpretation of “egress” that means “stuff we do internally before leaving aws data centers”. If the tcp conn is reset only a few MB would leave aws frontend servers. Instead, it appears they’ve been basing the number off the range in the request and/or whatever internal caching/loading they’re doing within S3, which again has nothing to do with egress.

I mean, we already know egress is short for egregious. It’s an incredibly bad look to be overestimating the “fuck you” part of the bill.

Re:The AWS S3 Denial of Wallet Amplification Attack by paulddraper on Wednesday May 01, 2024 @06:17PM (#40230283)
Sure. In this case specifically AWS is attempting to transfer 70Gbps through a 1Gbps pipe. Not a rounding error.