6 ms·

> 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 th

> 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.

tyingq 5y ago
You also need to find a 32 bit server to attack, and would then be, by definition, using all of its memory.
- r1ch 5y ago
  int is still 32 bit on 64 bit platforms, architecture makes no difference here.
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
  - tyingq 5y ago
    Ah, I see...there's a size_t, but it takes the value of the passed int.
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.
- 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/
kevans91 5y ago
I'd be concerned about the non-zero number of PHP CLI apps that exist in the wild, though.
- zaarn 5y ago
  Even the CLI apps will run into the memory limit
blenderdt 5y ago
And the memory and timeout limits will stop the program in most cases, even the CLI.
rndgermandude 5y ago
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.

tyingq 5y ago

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

r1ch 5y ago
int is still 32 bit on 64 bit platforms, architecture makes no difference here.
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]
- tyingq 5y ago
  Ah, I see...there's a size_t, but it takes the value of the passed int.

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.

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/

kevans91 5y ago

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

zaarn 5y ago
Even the CLI apps will run into the memory limit

blenderdt 5y ago

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

rndgermandude 5y ago

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.