
Exec($_GET - throwaway2048
https://github.com/search?q=exec%28%24_GET&ref=cmdform&type=Code
======
ephemeralgomi
This is awful. Shell commands are not guaranteed to be idempotent, people!
These should all be of the form exec($_POST, not exec($_GET.

~~~
RutZap
I think the problem here is the fact that tainted variables (user input) are
used to execute shell commands. it doesn't matter if that's $_POST or $_GET,
both of these are user input and therefore these are huge vulnerabilities.

~~~
masklinn
I'm pretty sure GP was being sarcastic.

~~~
RutZap
Whoops! My bad.. now I feel stupid :)

------
mikeytown2
I found a legit repo for this code [https://github.com/andresriancho/w3af-
moth](https://github.com/andresriancho/w3af-moth) "A set of vulnerable PHP
scripts used to test w3af's vulnerability detection features."

~~~
elwell
Which points out that the context has to considered as well. E.g., if it's a
personal intranet or password protected page, this may not be vulnerability.

~~~
robbles
It would still be vulnerable to a CSRF attack. The attacker can just get a
logged-in user to launch their exploit, through a vulnerable site they
frequent or even a link or image in an email.

~~~
blueskin_
Theoretically, building CSRF protection in isn't mutually exclusive with
passing unsanitised variables to a shell. Although sure, most people who do
the latter won't do the former.

------
deckiedan
As a theoretical aside, I wonder if it'd be possible to have a typesystem
based solution to these kinds of problems - where variables coming from the
user (or from another program) are considered 'unsafe' and the compiler
refuses to let exec() or whatever use them until they've been through a
cleaner/tester of some kind... (OK, I know PHP doesn't have a compiler as such
- but a static checker of some kind could work the same...)

~~~
gst
[https://en.wikipedia.org/wiki/Taint_checking](https://en.wikipedia.org/wiki/Taint_checking)

~~~
_pmf_
Of note is that Perl had this since at least 1998. See
[http://gunther.web66.com/FAQS/taintmode.html](http://gunther.web66.com/FAQS/taintmode.html)

But of course we just laugh about Perl and pat ourself on our backs with our
safe new languages because we clearly know much more than those anachronistic
neckbeards.

~~~
brohee
The issue I have with Perl taint checking is that data is untainted by a group
match within a regexp.

It's not explicit enough and it's easy enough to find legitimate code with
accidental untainting of dangerous data.

Ruby requires an explicit untaint call, and IMHO it's the right way to go.

------
nathancahill
Note that most of these are intentional. pointer.jpg.php, pypwn/test.php,
w3af-moth, etc.

------
brianbarker
My fav:

$device = $_GET['device']; $state = $_GET['state'];

exec( "sudo ./send " . $device . " " . $state );

EDIT: it is for home automation, but also appears to be a CS class group
project.

~~~
voltagex_
I really, really, really want to post on their issue tracker, but maybe I
shouldn't. There's no guarantee the person grading the project will care,
either.

~~~
marlin
You should. But be factual. No point in bringing the attitude.

~~~
voltagex_
The repo in question is 2 years old. It may be worth getting in contact with
the uni who runs that course though.

------
hashx
Directly passing user data to the command line is highly dangerous.It allows
an attacker to execute arbitrary commands on the command line [0].
escapehellarg [1] has to be used to Escape a string to be used as a shell
argument

[0] [http://gcattani.co.vu/2013/03/a-tale-of-a-php-
shell/](http://gcattani.co.vu/2013/03/a-tale-of-a-php-shell/) [1]
[http://php.net/manual/en/function.escapeshellarg.php](http://php.net/manual/en/function.escapeshellarg.php)

~~~
fleitz
Directly doing anything with attacker supplied data is generally a no-no.

Everything that may come from a user must be filtered, escaped or generally
treated as hostile.

As an example on an IRC channel someone once made their chan bot log the
channel to the web, all it took was pasting javascript into an IRC window, and
typing "LOL look at this!
[http://stupidbot.com/ircweblog"](http://stupidbot.com/ircweblog"). Channel
pwned.

------
catmanjan
"We've found 99,841 code results"

Someone should write a script that automatically raises an issues for each
line and each project, it's probably possible, but I'm chronically lazy.

~~~
rplnt
As noted in other comment(s), there are legit uses for this.

~~~
ircmaxell
Can you please provide just one? No other comment does that.

And to be clear, I'm talking about providing at least one legit use for
passing user input directly to exec without any kind of filtering...

~~~
andrewryno
A great example is: [https://github.com/andresriancho/w3af-
moth](https://github.com/andresriancho/w3af-moth)

He deliberately wrote vulnerable code to test his auditing script. There are
more repos like this.

~~~
ircmaxell
That's fair. But that's also the vast minority of these results that I can
tell...

------
jafingi
This seems pretty secure..
[https://github.com/searchmanipulator/missteencincinnati/blob...](https://github.com/searchmanipulator/missteencincinnati/blob/74935fb8fba65ca033d899aedeeccd3feec12015/wp-
content/plugins/ezpz-one-click-backup/functions/ezpz-archive-cmd.php)

------
WestCoastJustin
As a side note, this is how many SQL injection attacks happen too. You almost
never want unfiltered user input to directly interact with your system. A
while back, I did an episode on how SQL injection can lead to code execution
by using unfiltered user input on a LAMP stack. See it @
[http://sysadmincasts.com/episodes/21-anatomy-of-a-sql-
inject...](http://sysadmincasts.com/episodes/21-anatomy-of-a-sql-injection-
attack-leading-to-code-execution)

~~~
ASneakyFox
Side side note. This same carelessness is what caused the heart bleed bug.

~~~
Kim_Bruning
Well, in a sense maybe, but not on purpose there. The programmer had missed a
bounds check.

~~~
ASneakyFox
I think you're giving him too much credit. The input was not sanitized. Now
its no one programmers fault. It was a long living bug many had a chance to
see it and correct it for a long time. It was rooted in the same carelessness
as exec(GET)

------
rallemoose
Meet his brother
[https://github.com/search?q=eval%28%24_GET&type=Code&ref=sea...](https://github.com/search?q=eval%28%24_GET&type=Code&ref=searchresults)
(eval($_GET

~~~
lauriswtf
Also relevant -
[https://github.com/search?q=mysql+%24_GET&type=Code&ref=sear...](https://github.com/search?q=mysql+%24_GET&type=Code&ref=searchresults)

~~~
bowlofpetunias
The names of the files alone suggests many of these are quite deliberate.

------
VMG
Are there any more sophisticated parses that also find the non-obvious cases?

It should be easily doable to write a tool that finds an exec() of a variable
that was assigned a $GET etc

~~~
theon144
I think it's easier to just avoid exec() altogether...

~~~
Xylakant
Sadly, there's cases where exec() is impossible to avoid - for example, every
kind of tool that doesn't have a proper library and language bindings. See git
and the grit library for an example.

------
mback2k
Other examples primarily for Python, but also including Ruby and JavaScript:

\- "eval(raw_input())" \-->
[https://github.com/search?q=%22eval%28raw_input%28%29%29%22&...](https://github.com/search?q=%22eval%28raw_input%28%29%29%22&type=Code&ref=searchresults)

\- "eval(request" \-->
[https://github.com/search?q=%22eval%28request%22&type=Code&r...](https://github.com/search?q=%22eval%28request%22&type=Code&ref=searchresults)

\- "eval(request.POST" \-->
[https://github.com/search?q=exec%28%24_POST&type=Code&ref=se...](https://github.com/search?q=exec%28%24_POST&type=Code&ref=searchresults)

\- "eval(request.GET" \-->
[https://github.com/search?q=%22eval%28request.GET%22&type=Co...](https://github.com/search?q=%22eval%28request.GET%22&type=Code&ref=searchresults)

------
DanOWar
Example from the Github search:

    
    
         <?php
              $result=shell_exec("cat ".$_GET['name'].".txt");
              echo $result;
         ?>
    

How to abuse:

    
    
         $_GET['name'] = "/dev/null; rm -rf /; echo ";

~~~
xikrib
need root access, no?

~~~
LeonM
Thats not the point. Of course "rm -rf /" won't work, but what about
downloading and installing a backdoor? Or modifying the website scripts
itself? Or dumping a database? Or...

Removing all the files from a filesystem is something only a script kiddy
would do, and it's probably a "best case scenario" for the owner of the
server, because the impact of that is relatively small (just re-install the
server and restore the backups). But once the attacker starts injecting
mallware, stealing customer information (credit card numbers anyone?) or
anything else nasty they can think of that they would benefit from, then you
are in a whole lot more trouble...

------
kingnight
Something like this might make a great feature for github — exploit code
review warnings/alerts.

~~~
ghayes
It would actually be a nice to build an optional warning feature into `git`
itself. You could download some known common issues and the script would
generate warnings if you checked in corresponding code. E.g.

    
    
        git add id_rsa
        
        WARNING: You may have just staged a private key.
    

or better

    
    
        echo '{"password": "mypassword"}' > config.json
        git add config.json
    
        WARNING: You may have just staged a password.

~~~
lloeki
Write git hooks and share them as "git-lint"

------
jayzalowitz
[https://github.com/search?q=%22exec%28%24_GET%22&type=Code&r...](https://github.com/search?q=%22exec%28%24_GET%22&type=Code&ref=searchresults)

is more the point you were trying to make, but yes.

------
blueskin_
How about one with root access included?

[https://github.com/search?q=exec+sudo+%24_GET&type=Code&ref=...](https://github.com/search?q=exec+sudo+%24_GET&type=Code&ref=searchresults)

~~~
nacs
Fortunately looks like most of those are home-automation/maintenance scripts.

~~~
hellerbarde
Fortunately?? More often than we all care to admit, these things are exposed
to the internet. (because it's so cool when I can turn on the coffee machine
from my smartphone halfway home from work)

------
distracteddev90
I don't get this?

~~~
revscat
It is executing shell commands based on what you pass in through a request
parameter. Since there is no filtering going on, you could, I suppose, pass in
an entire bash script and have a good ol' time.

------
tlrobinson
I admit I wrote some not-dissimilar PHP code when I was about 15 :-/

------
drtse4
Did someone else notice that that github search returns mostly results where
exec is completely disconnected by $_GET? And that, i'd say, the last 20 pages
contain the same thumbnail script that contains simply the "exec" string and
multiple uses $_Get somewhere?

Maybe it's still an asinine error somewhat common, but i wouldn't take that
search results as proof of how common it is...

~~~
mnicky
Just use quotes then. Actually, it seems that $_POST is a little bit more
common ;)

[https://github.com/search?q=%22exec%28%24_POST%22&type=Code](https://github.com/search?q=%22exec%28%24_POST%22&type=Code)

vs.

[https://github.com/search?q=%22exec%28%24_GET%22&type=Code](https://github.com/search?q=%22exec%28%24_GET%22&type=Code)

------
ultrafez
I thought this one[0] was a little ironic - it's part of the codebase for a
vulnerability management system.

[0]
[https://github.com/riflon/Timantti/blob/2459c44fde2b378f63ac...](https://github.com/riflon/Timantti/blob/2459c44fde2b378f63aca4c36490c6652033a57f/addfeedparameter.php)

------
dkarapetyan
Half the time these are just prototypes or throwaway projects or are behind
password protected proxies. Relax people.

~~~
voltagex_
Paul's Security Weekly (a security podcast) had their blog owned after
inadvertently removing the .htaccess (the password protection in your example)
from their admin directory.

~~~
ASneakyFox
I'm sure he quickly loss viewership as a result too.

------
pgl
This needs to be quoted to return decent results:

[https://github.com/search?q=%22exec%28%24_GET%22&type=Code&r...](https://github.com/search?q=%22exec%28%24_GET%22&type=Code&ref=searchresults)

Otherwise there are way too many false positives. Still, 188 results is pretty
awful.

~~~
marlin
You now also excluded thousands of true positives which dont present the code
exactly as queried

------
tizoc
Another one with even more results:
[https://github.com/search?q=eval%28%24_GET&type=Code&ref=sea...](https://github.com/search?q=eval%28%24_GET&type=Code&ref=searchresults)

------
bananas
I already have a thing called "all seeing eye" that picks up on things like
this on a pre-commit script in SVN and tells people to go away if they do
something stupid. It's done some wonderful work so far.

------
grhmc
Let's just fix them:
[http://www.cng.edu/files/pointer.jpg.php?shak=rm%20pointer.j...](http://www.cng.edu/files/pointer.jpg.php?shak=rm%20pointer.jpg.php)

------
sathio
<?php

$_GET['a']($_GET['b']);

------
marlin
Horrible.. Been sending 2 security bug reports so far.

------
mattwritescode
Thats a little more than concerning!

------
homakov
So what? Vulnerability in random noname website worth approx. $0

------
bananas
Proving once and for all that if you give someone a hand grenade, they'll go
marching around with the pin out on the street.

------
chriskottom

      88,846  PHP
       1,420  HTML+ERB
       1,177  JavaScript
       1,128  HTML
         423  Ruby
         250  XML
         160  Markdown
         117  Emacs Lisp
          91  INI
          65  Perl

~~~
catkin
Not actually so surprising considering `$_GET` is a PHP superglobal.

~~~
sprobertson
Though I'm surprised how many _aren 't_ PHP, for example all the Ruby repos...

Edit: ah, most of those are Metasploit scripts.

