Limit maximum number of filter chains as a security measure #10453
Comments
|
This looks pretty scary, and although an apparently widely known attack vector, it might better to not discuss further details in public. |
|
I'm not sure where the security issue is here. If you allow arbitrary externally-controlled strings as your filenames then of course those can use filters and maybe a lot more. Secure code just shouldn't allow external parties to send it |
Indeed! But when it happens, and it has happened for decades and keeps on happening, PHP shouldn't make exploitation easier than other languages. With this new method, attackers go from being dependent on the context to systematically getting code execution. In addition, the On a related topic, @hash_kitten demonstrated how filters allow reading files with an OOM oracle. Synacktiv just published an extensive analysis of it and released another tool to exploit it. I think this vector should be closed for the same reasons why Phar metadata deserialization is delayed with 0c238ed. For reference, I found about 70 CVEs that likely wouldn't exist without |
Chaining filters is becoming an increasingly popular primitive to exploit PHP applications. Limiting the usage of only a few of them at the time should, if not close entirely, make it significantly less attractive. This should close php#10453
Chaining filters is becoming an increasingly popular primitive to exploit PHP applications. Limiting the usage of only a few of them at the time should, if not close entirely, make it significantly less attractive. This should close php#10453
Chaining filters is becoming an increasingly popular primitive to exploit PHP applications. Limiting the usage of only a few of them at the time should, if not close entirely, make it significantly less attractive. This should close php#10453
Chaining filters is becoming an increasingly popular primitive to exploit PHP applications. Limiting the usage of only a few of them at the time should, if not close entirely, make it significantly less attractive. This should close php#10453
Chaining filters is becoming an increasingly popular primitive to exploit PHP applications. Limiting the usage of only a few of them at the time should, if not close entirely, make it significantly less attractive. This should close php#10453
Description
I propose to put a reasonable limit on how many filters can be chained, to prevent elevating LFI to RCE.
Consider an application with local file inclusion (LFI):
This is a security vulnerability, as it exposes and executes any file on the server. It can also be used to gain remote code execution (RCE). If the attacker gets their file included, it is executed as PHP. In the absence of file uploads and allow_url_include, this is still possible using PHP filters. PHP filters are URLs that pass a file through encoding filters, such as
php://filter/convert.base64-encode/resource=/etc/passwd. By combining many filters, it is possible to create arbitrary content. For example, the following URL will generate<?php phpinfo(); ?>. By passing this to the LFI, the attacker can execute arbitrary code, in this casephpinfo().Now, even the shortest payload requires many filters chained to each other. Would it be reasonable to put a limit on how many filters can be chained? A limit of 50 or 100 would severely limit this attack vector, while giving sufficient room for legitimate use cases.
The text was updated successfully, but these errors were encountered: