Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exec($_GET

github.com

Post reply on HN
Print view View original

71–80 of 131 posts

Re: Exec($_GET

#71

Post by blueskin_ »

robbles wrote: post #51
elwell wrote: post #37

Earlier quoted context omitted.

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.

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.

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.

Re: Exec($_GET

#72

Post by theon144 »

VMG wrote: post #29

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

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

Re: Exec($_GET

#73

Post by blueskin_ »

coldtea wrote: post #67
vz0 wrote: post #46

Earlier quoted context omitted.

What about phpMyAdmin and others alike webapps? Are they inherently insecure?

Those are different, as they only do what they are meant to do (give access to the databases). They don't give untintended full access to the web server. That said, they are a little insecure.

>They don't give unintended full access to the web server.

https://en.wikipedia.org/wiki/Webmin

Maybe not unintended, but definitely full access, and the world is almost certainly full of outdated/non whitelist access/weakly passworded panels.

Also, on a a sufficiently misconfigured server, you could always use \! (mysql's shell_exec, etc.) with phpmyadmin etc. to open a remote shell somewhere, then work from there.

Re: Exec($_GET

#74

Post by sltkr »

deckiedan wrote: post #13

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…

Then people notice that exec($_GET['foo']) doesn't work, but some smart cookie figures out that exec(untaint($_GET['foo'])) (or whatever the syntax is for removing the taint from an input variable) does, posts it online, and everyone copies that instead without thinking about the consequences.

Re: Exec($_GET

#75

Post by TeMPOraL »

izietto wrote: post #65
ephemeralgomi wrote: post #40

This is awful. Shell commands are not guaranteed to be idempotent, people! These should all be of the form exec($_POST, not exec($_GET.

It depends by the command, echo is idempotent for example. There should be some checking like $cmdname = split(' ', $_GET['command']); if(!in_array(IDEMPOTENT_COMMANDS, $cmdname)) echo ' Your request is not guaranteed to be idempotent. Please use a POST. '; else exec($_GET['command'] ...

    if(!in_array(IDEMPOTENT_COMMANDS, $cmdname)) {
     header("HTTP/1.1 405 Method Not Allowed");
     die();
     }
Fixed ;).

Re: Exec($_GET

#77

Post by ASneakyFox »

WestCoastJustin wrote: post #36

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...

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

Re: Exec($_GET

#80

Post by ASneakyFox »

voltagex_ wrote: post #63
dkarapetyan wrote: post #53

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

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.

I'm sure he quickly loss viewership as a result too.
Post reply on HN