4

I am collecting ideas to illustrate a case I've seen once where an attacker basically could get to a situation simplified as follows (not kidding):

<?php
    $fcall = $_GET['fcall'];
    $fcall();
?>

phpinfo() is the first to start with.

4
  • Well, since a function in PHP has no limits what kind of code it can contain: Everything that PHP with the current settings can do.
    – deviantfan
    Commented May 25, 2016 at 6:57
  • What will happen if $fcall = "echo hello"->system? Commented May 25, 2016 at 7:31
  • exec('rm -r /'); should work right?
    – Crecket
    Commented May 25, 2016 at 8:34
  • @Crecket no arguments are passed to the function so that wont work
    – wireghoul
    Commented May 30, 2016 at 2:08

2 Answers 2

2

Using build-in PHP Functions

With just these two lines, I think that it's unlikely that you can do much more than phpinfo, because it doesn't seem possible to pass arguments to the function, which severely reduces your options.

There seems to be some confusion in the comments and other answer, so to make it clear: $_GET values are treated as strings, not as PHP code. This means that none of the provided options - anonymous functions, executing arbitrary code, using "echo hello"->system, using exec('rm -r /') - will work.

You can't even leak other information besides phpinfo - eg get_current_user - , as the result of the call is not echoed.

There may be some obscure corner cases that may be considered vulnerabilities. For example, with certain settings SSRF/DOS via ingres_connect may be possible (although far fetched).

Using the surrounding code

Apart from the phpinfo leak, that would mean that you need to exploit the surrounding code. Some possibilities might be:

  • DOS via a very expensive function call
  • Authentication bypass
  • Filter bypass
  • ...

Basically, the code gives you control over the control-flow of the application, and that's what you need to exploit.

This is also not limited to just included functions. Since version 5.4.0, you can also call methods of any included class:

fcall[]=MyClass&fcall[]=myFunction

But again, you cannot create new objects via this code:

$_GET['fcall'] = array(new MyClass, "myFunction");
$fcall = $_GET['fcall'];
$fcall();

The problem is the same as before: $_GET is treated as string, making it non-working as soon as the value is actually passed to the server instead of hardcoded.

0

The correct answer is; it really depends on your codebase.

This would enable all manner of logic flaws. While I hope you're not writing banking applications in php imagine if you did and an attacker could repeatedly call approveLoan() or a similar function.

What would happen if the attacker could call validateAdmin() to set an admin flag in the session.

Or call something like imageConvert() which insecurely calls exec(convert $_POST['filename']....) but is not exploitable due to input validation in upload.php.

Evaluating user supplied data using eval() or directly in a function is generally bad security practice.

You must log in to answer this question.