5 ms·

I wonder if this is actually exploitable in the wild or not? A 4GB request is a very large amount of data indeed.

by Lazare 5y ago

jamesfinlayson 5y ago
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.
- speedgoose 5y ago
  For sure. A recent smartphone can.
- apocalyptic0n3 5y ago
  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.
viraptor 5y ago
However if the input comes from the request body, 4GB of "aaaaa...." compresses exceptionally well. Http3 can compress headers too.
- Dylan16807 5y ago
  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.
  - viraptor 5y ago
    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.
    - Dylan16807 5y ago
      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.
bawolff 5y ago
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.
- spacemanmatt 5y ago
  From vague experience, the CLI limits you to a few kilobytes.
- tyingq 5y ago
  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/ https://mina86.com/2021/the-real-arg-max-part-1/

I wonder if this is actually exploitable in the wild or not? A 4GB request is a very large amount of data indeed.

by Lazare 5y ago

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.

speedgoose 5y ago
For sure. A recent smartphone can.
apocalyptic0n3 5y ago
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.

viraptor 5y ago

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

Dylan16807 5y ago
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.
- viraptor 5y ago
  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.
  - Dylan16807 5y ago
    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.

bawolff 5y ago

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.

spacemanmatt 5y ago
From vague experience, the CLI limits you to a few kilobytes.
tyingq 5y ago
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/ https://mina86.com/2021/the-real-arg-max-part-1/