3 ms·

This appears to be a rare + rare + exceptionally rare = vulnerability type thing. While I do agree that it should be fixed, and certainly because the patch is a

This appears to be a rare + rare + exceptionally rare = vulnerability type thing. While I do agree that it should be fixed, and certainly because the patch is a single easy fix that unit tests would catch any regressions. But the author kind of made it seem like a big deal, while realistically nobody would write code this way. Taking user input, running the domain with host flag through filter var and then system call it? Most libraries tend to implement validation themselves and not rely on filter_var. But even if this was fixed, most people should know taking user input and running it via system is a bad idea and needs more than a simple filter_var filter.

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 ago
    Fair 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 ago
      Understood! 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.

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 ago
  Fair 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 ago
    Understood! 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.