OT-Teil von: mysql table soll include einbinden

[onemorenerd]

Und dieser Angriff wurde nur entdeckt, weil auch der "pöse Hacker" seinen Quellcode vor dem Upload nicht auf Syntax-Fehler gecheckt hat.

Der Hacker hat vielleicht einfach eine Reihe bekannter Exploits durchprobiert bis er einen funktionierenden fand. Die Fehlermeldungen haben ihn dabei nicht gestört. Der Angriff wurde evtl. erst entdeckt, als das Kind schon im Brunnen lag und man des Kindes Tagebuch^WLogfiles las.
Es geht aber gar nicht ums gehackt werden. Das kann auch ohne eval passieren. Es geht vielmehr darum, dass man so einer eval-Fehlermeldung nichts hilfreiches abgewinnen kann. Ge-eval-ter Code lässt sich einfach schlecht debuggen.

Wenn ich mich recht erinnere (das ist schon ein Weilchen her), bin ich davon ausgegangen, dass der PHP-Quellcode von einem Menschen eingegeben wird, der dem Webmaster wohlgesonnen ist, also ein Kollege, Mitarbeiter oder der Site-Betreiber selbst.

In meiner Erinnerung waren es die Signaturen von Benutzern. Egal ... geht ja ums Prinzip. Und da ist das mit dem Vertrauen so eine Sache - weiß denn ein Site-Betreiber überhaupt, dass sein vB rum-eval-t?

[ragtek]

Weiß der "durchschnittliche" Seitenbetreiber überhaupt, wie seine Seite funktioniert?

Meiner Meinung nach, installieren viele fertige Pakete ala joomla, phpbb, konfigurieren diese und das war damit für sie.
Merkt man doch immer wieder in den Supportforen für die einzelnen Produkte

[onemorenerd]

Weiß der "durchschnittliche" Seitenbetreiber überhaupt, wie seine Seite funktioniert?

Weiß er nicht und kann/soll er auch nicht wissen.

Es ist doch egal ob man ein System durch Dateiänderungen laut Anweisung, eval oder require_once verändert.
Über jede von den genannten Möglichkeiten kann böser Code eingeschleust werden.

Dateiänderungen und require gehen Hand in Hand, wenn es um Code Injection geht. Der Unterschied zu eval ist, dass man sich vor unerlaubten Veränderungen der eigenen Dateien ziemlich einfach schützen kann. Man vernagelt den Dateisystemzugriff aus dem Netz und sichert alle Dateioperationen einer Applikation ab. Der Code, der durch eval gejagt wird, kommt nicht aus einer Datei. Der kommt aus einem nicht-dateibasierten Storage, z.B. einer DB oder live aus Benutzereingaben (run-once). In beiden Fällen muss man sicherstellen, dass der Code nicht schädlich ist. Das muss zwangsläufig direkt während der Ausführung geschehen, denn Code kann sich bei jeder Ausführung anders verhalten. Wirklich sicheres eval benötigt also eine Sandbox, sprich VM. Zu diesem Aufwand steht der Nutzen von eval in keinem gesunden Verhältnis.

[ragtek]

Ja, ich teile (fast komplett) deine Meinung, aber der Trend geht doch in eine andere Richtung (wo ich dagegeben bin, es gibt wie wir uns beide einig sind, zu viele Sicherheitsbedenken, aber der 0815 Benutzer will es meißt so).

Applikationen wie zB das Wordpress, das WBB3 erhalten automatische Updateprozesse und One Click Erweiterungsinstallation, die es ermöglichen, nur den Erweiterungennamen reinschreiben, und das Skript verbindet sich mit dem Server, lädt das Archiv runter, entpackt es und installiert alles unnötige.

Hier sind die Sicherheitsrisiken noch viel enormer.
Man stelle sich nur mal ein gehacktes Archiv vor....
Aber egal, ich glaube das es hier schon extrem in den Offtopicbereich ausartet...

[unset]

Ist doch egal, ist doch schon Offtopic.

Was das WP-Beispiel angeht: Ich persönlich nehme lieber ein Auto-Update-Konzept in Kauf, als das tausende ungepatchte WP-Versionen als Spamschleudern missbraucht werden. So gesehen kann man hier fragen, was passiert wenn die Debian-Repos Schadcode verteilen (was ja übrigens mindestens schon einmal passiert ist).

[ragtek]

Echt, das gab es schon mal? Garnicht mitgekriegt. Danke für den Hinweis.

Aber um auf dein Beispiel einzugehen.
Nun stell dir mal eine gehackte Version vor, die per Auto Update zu zig Tausenden Benutzern kommt=> noch größere Spamschleuder möglich

Da kämmen ja auch ganz andere Szenarien in Frage (mächtiges Botnet bis es nicht entdeckt wird)

Edit:
Aso, du meinst ein Debian Repo. Ich bezog mich auf WP...
Sorry

[unset]

Naja, das ist nun ein bisschen an den Haaren herbei gezogen. Ein solches würde jedem halbwegs fähigen Systembetreuer sofort auffallen. Im besagten Fall war es auch kein absichtlicher Schadcode, sondern - wenn ich mich recht erinnere - schlicht und ergreifend ein mangels Reviews eingeschlichener Bug, der allerdings dafür sorgte, dass Keys plötzlich sehr schwach wurden. Das wurde wohl auch ausgenutzt.

Edit: Und hier ist auch der Link: Debian -- Security Information -- DSA-1571-1 openssl

[onemorenerd]

So ein Auto-Update/Install-Prozess hat nichts mit eval zu tun. Da werden nur ein paar Files von irgendwoher gezogen, gespeichert und/oder in einer Plugintabelle registriert. Das funktioniert alles ohne eval und beweist einmal mehr, dass grenzenlose Flexibilität sehr gut ohne eval möglich ist.
PHP wird durch eval nicht mächtiger. Nur unsicherer.

Dass man Dateien von "irgendwoher" nicht trauen sollte, ist klar. Es gibt durchaus brauchbare Lösungen dafür - Identitätsprüfung, Zertifizierung, ... - aber letzenendes muss man immer irgend jemandem* vertrauen oder den Code vor der Installation selbst lesen.

*) Die Auto-Update-Mechanismen vieler Betriebssysteme funktionieren prinzipiell genau so. Der Updater connected sich zu einem unbekannten Server und lädt Dateien mit unbekanntem Inhalt. Millionen User vertrauen blind darauf, dass der ganze Prozess "sicher" ist. Überprüfen kann man das kaum.