Hacker News Reader

Comment by jamesfinlayson | Hacker News Reader

> There are some limitations to this exploit, for example, the user input must be 4GB in size (which is a large amount of data and may not be possible due to the configuration of some webservers and load balancers).

I'm thinking PHP's built in request size limit config items (e.g. post_max_size) will prevent this from being an issue too. Might not stop this bug if the URL is in a header though.

View on HN

IIRC (and I haven't done any php in quite a while) upload_max_size is dependent on post_max_size, so I'd think there might be a ton of php deployments out there configured for large file uploads where this exploit precondition is met after all.

I wonder if this is actually exploitable in the wild or not?

A 4GB request is a very large amount of data indeed.

As a sibling comment pointed out, PHP has max_execution_time which I think defaults to 30 seconds, but I'd guess plenty of people have set it to unlimited to work around some problem or other.

A beefy server should be able to process 4GB of data within 30 seconds though I suppose.

For sure. A recent smartphone can.

max_execution_time starts when the entire request has been received (or, more accurately, once PHP script execution has begun). Upload times don't trigger it to start.

If I recall correctly, max_input_time includes time taken to copy the file to the tmp directory and to parse the file for metadata, but not the upload time either (it does start prior to max_execution_time though). This value is set to -1 by default meaning it uses the value from max_execution_time instead.

You're more likely to run into Apache, Nginx, or PHP FPM timeouts. I can't remember exactly which timeout, but I remember there is one in Apache or FPM that is affected by upload time.

However if the input comes from the request body, 4GB of "aaaaa...." compresses exceptionally well. Http3 can compress headers too.

I don't think I would say "exceptionally well" as a rule. Compression algorithms often leave a lot on the table for very long repetitions. For example, gzip can only encode repetitions up to 258 bytes, and the absolute best case for encoding that costs 2 output bits. And then a 4GB file of the same character over and over compresses to a 4MB file primarily made of... the same character over and over.

I think that classifies as exceptionally well. You get 1000x compression and when trying to send a compressed payload, the issue of "the server may time out the connection" pretty much goes away. 4MB is trivial to send from almost anywhere - to hit the 30s timeout, you'd need to go slower than 137KB/s.

It could trivially enable millions or billions to 1 compression, though. It just needs the option of a longer length field. With even a single megabyte of repeated data, it has to split it into four thousand chunks. That's not exceptional in my book.

I'll call it exceptional when it can encode any real-drive-size repeated-character file into the size of a tweet.

I also sort of wonder what happens if you try and put > 4gb on the commandline. Surely there is a limit for max size of commandline arguments.

From vague experience, the CLI limits you to a few kilobytes.

For Linux, it's ARG_MAX, so

  $ getconf ARG_MAX
  2097152

It's driven by some formula related to max stack size (ulimit -Ss), but capped at 6 MiB.

https://mina86.com/2021/the-real-arg-max-part-1/

You also need to find a 32 bit server to attack, and would then be, by definition, using all of its memory.

int is still 32 bit on 64 bit platforms, architecture makes no difference here.

Ah, I see...there's a size_t, but it takes the value of the passed int.

I'd be concerned about the non-zero number of PHP CLI apps that exist in the wild, though.

Even the CLI apps will run into the memory limit

And the memory and timeout limits will stop the program in most cases, even the CLI.

Reply on news.ycombinator.com