3 ms·
Even if someone wrote code like that, they'd have to have configured their web server to accept 4GB of input somewhere, which gets passed to that function. That
by chockchocschoir 5y ago
Even if someone wrote code like that, they'd have to have configured their web server to accept 4GB of input somewhere, which gets passed to that function. That adds another "rare +" instance, as most web servers ship with way lower defaults than that.
- spacemanmatt 5y ago<security hat> Sounds like you are arguing in favor of keeping this bug. An attacker could use it to move laterally once behind whatever proxy/WAF limited the content body size. </security hat>
- chockchocschoir 5y agoFair presumption but no, I agree it should be fixed. I just don't agree with the authors idea of how important it is to fix it, as it's highly unlikely to be exploitable in the wild. Even without any proxies/WAF, PHP is always run (except in development environments with `php -S localhost:4124`) behind a web server, usually apache or nginx. Not sure about apache, but nginx defaults to a limit of 1MB for the request size (via `client_max_body_size` https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size https://nginx.org/en/docs/http/ngx_http_core_module.html#cli...) and I can imagine apache have a similar default as well. Even if you allow requests to carry 1GB of data, this is still not exploitable, and if you have that large requests anyways, you usually find another way of doing the transfer than using plain HTTP requests.
- spacemanmatt 5y agoUnderstood! The config conditions for this exploit are a little bit reassuring but from a historical perspective, there is likely to be a related exploit found with different conditions.