Sicherheit Bei Osx

[dannycool]

@dannycool

zu deiner Sicherheitslücke....
das man sich unter HFS+ die named forks auflisten kann gehört zur grundfunktion von osx ... das ist sozusagen ein feature...gibt doch auch im finder...paketinhalt anzeigen...deswegen funktioniert das ja auch was du machst.

Gerade weil es eine Grundfunktion ist, ist es ein Problem. Sonst würde man es einfach ausbauen. Bisher ist es nichtmal abschaltbar. (Wobei, ein Admin mit Programmierkenntnissen könnte es für einzelne Programme ausschalten, aber das ist nicht sein Job.)

Das was der Finder bei Paketen macht ist etwas komplett anderes. Pakete und Anwendungen sind bei Mac OS X wirklich Ordner. Der Finder behandelt sie nur per default wie Files, damit der dumme User nicht drinnen rummurkst...

Das Sicherheitsloch bezog sich darauf das man das ganze mit Apples Apache und anderen Webservern damit Informationen ausgelesen werden können...das ganze wurde von Apple für Apache gefixt...die anderen Hersteller sollten sich selber darum kümmern...sind ja auch nur ein paar Zeilen die geändert werden müssen.

Dass es nicht am Apache liegt sieht man schon alleine daran, dass man auf seinem Mac auch UFS anstatt HFS+ verwenden kann, damit tritt die Problematik nicht auf. Nein, das kann's nicht sein, Apple will hier ein Unix verkaufen (auch wenn sie die Marke nicht lizensiert haben), da sollte es sich auch wie eins verhalten...

Für den Apache haben sie ausschließlich deshalb einen Workaround veröffentlicht, weil der mit dem Mac OS X mitverkauft wird.

und im übrigen ist das ganze schon seit 10.0.3 bekannt. Da will NetSec glaub ich auf die Kacke hauen und in die Schlagzeilen kommen.

Es ist üblich dass man solche Advisories erst rausgibt, wenn die Lücke behoben wurde. Wenn es seit 10.0.3 bekannt ist, finde ich es erstaunlich wie hier einige davon sprechen können, dass sich Apple schnell um Sicherheitsprobleme kümmert.

 

[pique]

btw: mein provider ist letztens von einer brasilianischen hackerbande namens simiens crew gehackt worden. alle index.html wurden systemweit auf dem server überschrieben.

durch ein sicherheitsloch in php. die server laufen auf debian.
sie sagen es gäbe noch keinen patch dafür, man könnte höchstens php abschalten.

 

[dannycool]

durch ein sicherheitsloch in php. die server laufen auf debian.
sie sagen es gäbe noch keinen patch dafür, man könnte höchstens php abschalten.

Das dürfte der unserialize-bug gewesen sein, der mit php 4.3.10 letztes Jahr gefixt wurde. Der ist übrigens nur exploitbar wenn unter php noch anfällige Software läuft, wie z.B. phpbb (mittlerweile natürlich auch behoben, da gab es einen lustigen Wurm der sich unter phpbb-Servern verbreitet hat.)

Welche PHP-Version hast Du?

 

[pique]

der provider hat php 5 irgendwas

 

[dannycool]

Für PHP 5 ist die gefixte Version 5.0.3. Normalerweise setzt ein Webhoster aber kein PHP 5 ein. Naja, wer Alpha-Qualität will...

 

[pique]

wie auch immer. keiner mault über debian. aber ein loch im apache auf osx ist ein loch in osx?

 

[pique]

Für PHP 5 ist die gefixte Version 5.0.3. Normalerweise setzt ein Webhoster aber kein PHP 5 ein. Naja, wer Alpha-Qualität will...

edit: sorry, es ist eine 4er version. mein fehler. welche weiss ich nicht genau.
kann von hier nicht nachschauen.

 

[ms510]

seit 10.0.3 http://www.osvdb.org/7039 .Sicherheitsmechanismen von Apache greifen nicht. Was ja auch die Kernausssage von NetSec ist. Inwieweit das mittlerweile gefixt ist weiß ich nicht.

Ich bin aber der Meinung das es ein Bug von Apache ist. Er läßt sich überlisten in dem ein Feature von HFS+ ausgenutzt wird. Das ist meiner Meinung nach kein Fehler von HFS+ da dies Bestandteil von HFS+ ist. HFS+ kann nicht wissen das ein Verzeichnis geschützt ist. Apache erlaubt die Einstellungen bezüglich der geschützen Dateien zu umgehen unter Ausnutzung eines Features von HFS+. Wer jetzt der schuldige ist darüber läßt sich sicher streiten.

Der Workaround für Apache ist ja nun nicht so umfangreich das es ein Problem wäre ihn bei irgendeinem anderen WebServer einzusetzen.