Am Dienstag, 22. März 2005 18:47 schrieb Christian Perle:
ACK. thttpd ist verdammt schnell und sehr einfach zu konfigurieren. Allerdings ist er ungeeignet fuer Dateien, die groesser als 2GB sind.
Das sollte man schnell beheben können (-DLARGE_FILE...), ist aber natürlich unfein.
Sind aber beide (nachweislich) exploitbar durch Buffer Overruns.
Quelle?
Die finstere Vergangenheit. Es mag ein wenig reißerisch sein, Anwendungen mit ehemaligen Schwachstellen so einzuschätzen, aber ich traue sowas nicht wirklich über den Weg. Das gilt für lighttpd genauso. Solche BOs sind zwar nicht die alleinigen Sicherheitsprobleme, stellen aber nach wie vor den größten Teil dar. Darauf aufbauend dann die URL-Handler-Probleme mit %00 und dergleichen. Gibt für alles Bibliotheken, die auch nicht alle mehr Code enthalten, als wenn man es sauber selbst implementieren würde. Mit Skriptsprachen entfallen zudem die lästigen zusätzlichen Dependencies, die haben nunmal eine erhöhte Basisfunktionalität, welche über eine POSIX-normierte libc der 80er hinausreicht.
Ansonsten laesst sich thttpd mit Bordmitteln soweit absichern, dass ein Buffer Overflow nicht viel bringt: (als root gestartet) thttpd -d /dir/to/serve -r -p port
Nur blöd, dass Sandkästen allein als Root durchführbar sind und nicht als Nutzer. Das Konzept wäre nämlich gut darauf übertragbar, seine eigenen Skripte auszuführen, ohne sich das wertvollste auf einer Einzelplatzmaschine (nämlich $HOME) zu zerschießen. Es gibt Erweiterungen zum Kernel die dies erlauben, und das ist für interaktive Systeme unverzichtbar, auch wenn "unsere" Mailclients keine Anhänge automatisch ausführen sollte man sich nicht nur auf diese eine Sicherheitsschicht verlassen.
Josef