Perl/CGI Securityproblem, was kann ich tun?

[footh]

Hallo Gemeinde!

Wir testen schon seit längerem eine Multiuserumgebung mit Confixx2.16 auf einem Suse8.1-Server Root L.
Die Serversoft und Sachen wie php, mysql, alles nahezu auf dem neusten Stand. Apache 1.3.27, mod_php4.3.3, mysql 4.X., usw.

Jetzt ist es aber so, daß einer der Perl/CGI-Coder es geschafft hat, mit einem Dateimanagerscript aus einer Confixx-cgi-bin-Userumgebung auszubrechen und kann nun auf der Rootfestplatte, vom Internet aus, herumbrowsen. Zwar kann man keine Dateien löschen, aber in jedes xbeliebiges Verzeichnis der Festplatte reinklicken :-(.

CGI läuft mit suexec und läuft auch korrekt, denke ich:

Code: Select all

suexec -V
 -D DOC_ROOT="/home/www"
 -D GID_MID=96
 -D HTTPD_USER="wwwrun"
 -D LOG_EXEC="/var/log/httpd/suexec.log"
 -D SAFE_PATH="/bin:/usr/bin"
 -D UID_MID=96
 -D USERDIR_SUFFIX="public_html"

Erster Versuch des Coders, sein Script konnte nur innerhalb des /home Verzeichnisse lesen. Nun wurden noch schärfere Rechte gesetzt, schon war /home nicht mehr Sichtbar und er kam mit dem Script auch nicht weiter heraus. Ein /sbin/SuSEconfig setzt wieder die Rechte zurück, sodass das Script wieder /home auslesen kann. Ich habe nun die automatischen Permissions für /home auf 0551, so ist /home nicht mehr vom Script sichtbar und der Apache arbeitet noch einwandfrei. Anders bei 0550, so können dann keine Webseiten mehr aufgerufen werden.

Zweiter Versuch des Coders, ich habe die Rechte wieder auf 0551 für /home gesetzt. Das Script liest nicht mehr /home aus. Der Coder modifiziert, sprich entwickelt sein Script weiter, und boom, jetzt kann er sich mit seinem Script über jeglich gesetzte Rechte des root hinwegsetzen und nun die ganze Rootfestplatte von einem web1/html/cgi-bin-Verzeichnis vom Internet aus, auf der Festplatte auslesen und in jeglichen Ordnern herumbrowsen.

Mögliche Gegenmaßnahmen?
Meine Ideen:
Vergeblicher Versuch einer Möglichkeit:
http://www.rootforum.org/forum/viewtopic.php?t=18683
Entsprechende Rechte für /dev/hda3 setzen, auf der die ganzen Ordner sind, damit der Festplatteninhalt für User unsichtbar ist?
suexec mit einer höheren uid/gid neu kompilieren, zZt. beides auf 96, damit die Ausführung von CGI nicht soviel Rechte besitzt?
In der etc/sysconfig die systemweiten Permissions anders definieren, zZt auf easy local, wäre besser auf secure oder paranoid?
Apache chrooten? Wenn ja, gibt es da ein gutes Howto, damit Apache immernoch korrekt mit einer Confixxumgebung läuft?
Bringt mod_cgiwrap etwas?
Würde mod_security etwas bringen?

Was könnt ihr mir noch für mögliche Gegenmaßnahmen nennen?
Oder was könnte eurer Meinung nach nicht korrekt konfigurriert sein?
Von einigen anderen Stellen, habe ich gelesen, daß es völlig normal wäre, wenn CGIs die Festplatten mit der kompletten Struktur auslesen können. Ich aber möchte mich damit nicht abfinden und meine, daß es ein Security-Problem ist, was behoben werden muß.

Ich hoffe, daß ihr mir bei meinem Problem helfen könnt, denn ich suche seit Tagen krampfhaft nach einer brauchbaren Lösung des Rätsels.

Vielen Dank an euch im Voraus.

MFG
footh

[captaincrunch]

Ganz spontanes Stichwort : mod_security (wobei es erheblich sinniger wäre, dem Grundproblem auf den leib zu rücken)

[footh]

(wobei es erheblich sinniger wäre, dem Grundproblem auf den leib zu rücken)

Hallo!
Dem Grundproblem auf dem Leibe rücken, und das wäre für dich bitte?
Was ist hier bei der Sache für dich das Grundproblem? Für mich ist das hier nicht mehr ersichtlich, weil ich meine, schon alles versucht zu haben. :roll:

Ich bin für jeden noch so kleinen Tipp dankbar :!:

[mutombo]

Captain meint ganz einfach das es nix bringt um das problem rumzubasteln.
mit mod_security könntest du halt den apache im chroot laden und scripte limitieren, aber grundsätzlich sollte es meines wissen(bin leider auch nicht so der crack in perl/cgi) einen script nicht erlaubt sein soo tief ins system einzudringen. bei php regelt das z.b. der safemode.

[captaincrunch]

Mit "Grundproblem" meine ich, dass du dir zwar durch Verwendung von (z.B.) mod_security dieses "Problem" (vorläufig) vom Hals schaffen kannst, da aber kein System sicher ist, findet sich sicher auch irgendwann einmal jemand, der auch dort die Lücke findet, um daraus auszubrechen.

Was Perl/CGI und suexec angeht, bin ich aber eine abolute Nulpe, kann dir in dem Zusammenhang leider auch keine allzu brauchbare Hilfe liefern, da gibt's hier aber sicherlich andere, die das könnten (wie z.B. bestimmt der rootmaster ;) ).

Im allerschlimmsten Fall würde ich den Apachen dann halt wirklich z.B. per mod_security chrooten, damit verschaffst du dir wenigstens eine vorläufige Sicherheit.

[footh]

Hallo!

Erstmal vielen Dank für die Anteilnahme bei meinem Problem. :!:
......und was haltet ihr von cgiwrap?

MFG
footh

[captaincrunch]

Kleiner Nachtrag : http://apache-server.com/tutorials/LPsuexec.html

Gerade noch beim Googlen gefunden

[footh]

Hallo!

Generelles Sicherheits-Problem bei 1und1-Rootserver?
Ich habe nun einen zweiten frischgebackenen ROOTL bekommen und dort ist das gleiche Problem. Mit einem bestimmten Script kann man auch dort die komplette Festplatte "/" des Roots auslesen.

Bitte testet Eure Systeme hiermit:

Code: Select all

#!/usr/bin/perl -w 
print "Content-type: text/htmlnn"; 
use File::Spec::Functions; 

$dir = "/"; 

opendir(DIR, $dir) or die("Cannot open $dir"); 

foreach $dir (readdir DIR) { 
next if $dir eq updir(); 
next if $dir eq curdir(); 

print "gefunden: $dirn<br>"; 
} 


closedir(DIR);

Code als test_cgi.cgi oder .pl auf euren Server ins cgi-bin abspeichern und hochladen, auf 755 chmoden und ausführen. Wenn ihr nun etwas sehen könnt :roll:
Dieses Script hatte ich hier mal zum Test aus dem Forum.
Man hat dieses Script zusätzlich mit einer Art Browser ausgestattet und somit kann man seelenruhig auf der Platte des Admin herumsurfen, wer weiß was noch möglich ist, wenn man noch weiter daran herumschraubt.

MFG
footh

[Joe User]

Ich verstehe Dein Problem nicht ganz: Das Perl-Script, wie auch sein PHP-Bruder, funktioniert bei allen Hostern, auf deren Systeme ich Zugriff habe. Desweiteren stellt dieses und ähnliche Scripte kein Sicherheitsproblem dar...

[footh]

Desweiteren stellt dieses und ähnliche Scripte kein Sicherheitsproblem dar...

..bist du dir da ganz sicher?
Man kann sich vielleicht darüber streiten, ich habe bei uns gesehen, was man aus diesen kleinen Schnippel machen kann und ich finde nicht, daß man es so hinnehmen sollte, daß jedermann die Platte auslesen kann und gegebenfalls mit diversen Modifikationen, auch darauf herumbrowsen kann, so wie es bei uns der Fall ist.

Falls du Kunden hast, ob sie damit einverstanden sind, wenn man ihnen in die Karten schaut, wie vielleicht ihre Webprojekte aufgebaut sind?
Ich wäre damit nicht einverstanden und würde mich beim Provider beschweren. Ã?brigens, der Bruder des Scripts in php läuft seit suphp nicht mehr bei uns

MFG
footh

[[nix]pepe]

haste denn mal probiert ob du die daten der anderen kunden überhaupt öffnen kannst?
soweit ich weiß geht das nämlich nit...

[Joe User]

Dann wirst Du sämmtlichen Dirs/Files die Leseberechtigung für die entsprechenden User und Groups entziehen müssen -> Good Luck...

[footh]

haste denn mal probiert ob du die daten der anderen kunden überhaupt öffnen kannst?
soweit ich weiß geht das nämlich nit...

Das schrieb ich schon oben, nur lesen und mit Modifikation herumbrowsen und sämtliche Ordner der Festplatte öffnen. Jetzt fragt mich bitte nicht wie der PerlCoder das gemacht hat, denn ich weiß das nicht.

Es geht mir jetzt eigentlich nur darum, ob jemand eine Idee hat, was man für Gegenmaßnahmen hat oder woran das liegen könnte. Ich werde mal das ganze ausprobieren, was man mir oben schon mal vorgeschlagen hat.

Vielen Dank an Euch!!!

MFG
footh

[[nix]pepe]

mmmh, wie wär's wennde uns das script mal zur verfügung stellst?

[flo]

Genau aus dem bei SuSE üblichen Permission-Chaos gibt es für SuSE ja auch das Script "harden-suse", daß grundlegende Dinge auch und gerade an den Verzeichnispermissions ändert.

Nur: Wenn Du das nicht sauber vorbereitest, schießt Du Dir, je nachdem welche Optionen Du verwendest, wahlweise SSH oder Apachen oder beides ab.

Link: http://www.suse.de/~marc/SuSE.html

Die Permissions zu ändern hat natürlich dann keinen Sinn, wenn CGI als wwwrun läuft, dann war die Mühe diesbezüglich umsonst.

Grüße,

flo.

[footh]

Die Permissions zu ändern hat natürlich dann keinen Sinn, wenn CGI als wwwrun läuft, dann war die Mühe diesbezüglich umsonst.

Jepp, genau da liegt wohl der Knackpunkt. CGI läuft nämlich standardmässig als mod_cgi, also als Apachemodul. Gibt es einen Weg, genau wie bei php, cgi als nicht Apachemodul zu installieren?

@[NIX]Pepe
..leider habe ich nicht die Erlaubnis dieses Script weiterzugeben, aber das Script aus diesem Beitrag ist das gleiche und hat genau den gleichen Effekt, nur halt, daß man auf der Festplatte nicht herumsurfen kann. Wenn du also damit die Festplatte auslesen kannst, hat man, so meine ich, ein Sicherheitsproblem.

Jetzt aber mal zu meinen neuen Ergebnissen.
Das Script aus diesem Beitrag und die Weiterentwicklung auf diesen Script basierend, zeigen nun keinerlei Wirkungen mehr auf unseren Server. Das heißt, daß die Festplatte bis jetzt nun nicht mehr wieder ausgelesen werden konnte. Das soll aber nicht heißen, daß man jetzt sicher ist.

Die Lösung war eigentlich ganz simpel.
Setze von "/ " die Permission einfach auf 0551 und schon haben die oben erwähnten Scripte keine Chance die Festplatte auszulesen, andere, normale CGIs laufen aber weiterhin ohne Probleme. Das kann man nun als Notlösung ansehen.

Wie schon CaptainCrunch meinte, müsse man sich dem Grundproblem eher annehmen.


MFG
footh

[alexander newald]

Evtl. habe ich etwas falsch verstanden, aber:

CGIs mit suexec laufen unter der UserID/GroupID des Benutzers, der das CGI in seinem Homeverzeichnis hat.

Alle Homeverzeichnisse in /home haben die Rechte:

Code: Select all

drwx---r-x

und alle Benutzer sind in der gleichen Gruppe. Somit kann zwar ein CGI Skript lustig in der Gegend rumbrowsen, spätestens aber den Inhalt der Homeverzeichnisse kann das Skript nicht mehr lesen/darauf zugreifen. Sicherlich kann das Skript noch auf /etc /usr/local/bin oder sonstige Verzeichnisse zugreifen, aber zumindest in /etc sollte eh nichts interessantes sein, was man als nicht root lesen kann.

Eine Möglichkeit, einem Skript zu verbieten aus /home/benutzer wie bei PHP im Safe_Mode auszubrechen, kenne ich nicht.

[mutombo]

schade das es sowas wie den safe_mode nicht für perl gibt.
da bleibt als beste möglichkeit dann wohl ein chroot, das läßt sich ziemlich einfach mit modsecurity machen.
ansonsten sind natürlich saubere permissions grundlage (mit suid-bit aufpassen).
sicherste lösung wäre wohl ganz auf cgiscripte zu verzichten ;)

[olaf.dietsche]

Ich kenne den safe_mode nicht, aber unter

Code: Select all

man perlsec

wird der taint mode beschrieben. Das sieht so aus, als ob man damit in einem "safe_mode" operiert.

[arty]

Hi,

man sollte aber sagen, dass der Safe Mode von PHP keine wirkliche Sicherheit gibt, steht so auch in der PHP Dokumentation.

bye
arty

[footh]

@Alexander Newald

Somit kann zwar ein CGI Skript lustig in der Gegend rumbrowsen, spätestens aber den Inhalt der Homeverzeichnisse kann das Skript nicht mehr lesen/darauf zugreifen. Sicherlich kann das Skript noch auf /etc /usr/local/bin oder sonstige Verzeichnisse zugreifen, aber zumindest in /etc sollte eh nichts interessantes sein, was man als nicht root lesen kann.

Ja, du hast recht und das wissen wir auch, daher der Beitrag.
Aber trotzdem ist es nicht gerade ein schöne Sache, wenn man auf der Festplatte des Servers herumstöbern darf. Naja, zum Glück haben wir das ja jetzt provisorisch gelöst.

@all
Einige meinten, daß mod_security vielleicht ein Lösung wäre und dieses leicht in den Apachen einzubinden wäre. Hat das schon jemand installiert und könnte der jenige mir vielleicht einen kurzen Installweg beschreiben?
Den Rest bieg ich mir selbst hin..., vielen Dank schon mal im Voraus!!!

MFG
footh

[Joe User]

Lies Dir die Dokumentationen (Apache/mod_security) durch, mehr können wir Dir auch nicht schreiben.