Angriffsszenarien

[MacMark]

Allgemeines Geschwafel.

 

[tjp]

Allgemeines Geschwafel.

Es gibt einen Text den alle hier im Thread gelesen haben, in diesem werden einige Punkte angesprochen. Wenn Du es für nötig hälst kannst Du dazu eine Kritik schreiben und auf die Punkte eingehen, die Dich stören. Aber diese "ist eh alles Scheiße" Haltung geht mir ziemlich auf die Nerven.

 

[MacMark]

Ich habe http://c9c3.blogspot.com/2007/04/apple-computers.html durchaus gelesen, falls Du das meinst. Er belegt seine wütenden Behauptungen aber nicht mit Details. Auf seine schwammigen Andeutungen habe ich gestern nachmittag hier in diesem Thread schon mit konkreten Details bezüglich Fragmentation Attack und Firewall geantwortet, die ein gegenteiliges Bild zeichnen.

Ich kann Leute nicht leiden, die nur FUD verbreiten und nicht mit nachprüfbaren Details um die Ecke kommen. Insofern ist sein Blogeintrag nutzlos.
Und Du konkretisierst Deine allgemein gehaltenen Behauptungen nicht.

 

[Tengu]

Ich bin da ebenfalls sehr skeptisch. Das ist Quatsch. Hardware allein liefert keine Angriffsoptionen. Hardware funktioniert standartisiert, z. B. auf IEEE Normen. Wie die Netzwerkkarte nun architekturtechnisch aufgebaut ist, hat nichts, aber auch gar nichts zu bedeuten.
Angriffsoptionen kommen durch extern zugängliche Services zu stande. Daraus resuktiert der Angriffsvektor auf ein System. Jetzt den Angriffsvektor um Systemgleichheit zu erweitern halte ich persönlich für nicht gerechtfertigt. Nicht so.

Weiterhin kommt es mir sehr spanisch vor, welche Antworten er gegeben hat. Die sind nun mal falsch. fork z. B.. Selber schuld.
Letztens noch: die Unix Firewall in MacOS ist echt super. Die filtert jene Ports, die Möchtegern Apple Programmierer Mister X in seinem Blogg, den er nicht mal mit seinem Namen versieht (warum wohl?), auf jeden Fall. Es sei denn man macht sich manuell die Arbeit das auszustellen. Der BSD Unterbau von MacOS, so sage ich mal freiweg, hat keine Sicherheitslücke, die bekannt ist.

Gruß,
Mark

 

[tjp]

Ich kann Leute nicht leiden, die nur FUD verbreiten und nicht mit nachprüfbaren Details um die Ecke kommen.

Er berichtet über über ein Gespräch mit Apple, das sich über Sicherheitphilosophien gedreht hat und spricht dabei einige Probleme an.

1. Googlen zum Thema "ipfw fragment" liefert schon einige Hinweise auf Probleme in FreeBSD. Und mit etwas googlen findet man dann auch das hier. Da hat nichts mit FUD zu tun.
2. Die Firewall von MacOS X ist nur ein Packet Filter. Packet Filter können diverse Angriffe nicht abwehren, das liegt in der Natur des Sache, da sie nur den Fluß der Pakete kontrollieren nicht aber deren Inhalt.

Ist das wirklich zu viel verlangt mal nach etwas selbst zu suchen?

Dann führt er Formatstringprobleme mit sicherheitsrelevanten APIs von Cocoa an. Formatstringangriffe sind ein allgemein bekanntes Problem genauso wie buffer under/over runs. Das braucht man nicht mehr näher zu erläutern.

 

[tjp]

Die filtert jene Ports, die Möchtegern Apple Programmierer Mister X in seinem Blogg, den er nicht mal mit seinem Namen versieht (warum wohl?), auf jeden Fall.

Ja, bist Du Dir ganz sicher? Ich habe das bei mir mal angeschaut: MacOS X 10.4.9 bis auf "stealth" ist alles an, und ich habe nicht von Hand , d.h. via ipfw Shell Programm, konfiguriert. Die italic Rules sind von mir über die GUI ergänzt.

*****:/Users/admin root# ipfw show
02000 2728 292840 allow ip from any to any via lo*
02010    0      0 deny ip from 127.0.0.0/8 to any in
02020    0      0 deny ip from any to 127.0.0.0/8 in
02030    0      0 deny ip from 224.0.0.0/3 to any in
02040    0      0 deny tcp from any to 224.0.0.0/3 in
02050  323  54144 allow tcp from any to any out
02060  368 231505 allow tcp from any to any established
02065    0      0 allow tcp from any to any frag
[I]02070    0      0 allow tcp from any to any dst-port 5432 in
02080    0      0 allow tcp from any to any dst-port 6000-6100 in[/i]
12190    8    424 deny log tcp from any to any
[b]20310    0      0 allow udp from any to any dst-port 53 in
20320    0      0 allow udp from any to any dst-port 68 in
20321    0      0 allow udp from any 67 to me in
20322    0      0 allow udp from any 5353 to me in[/b]
20340    0      0 allow udp from any to any dst-port 137 in
20350   24   1536 allow udp from any to any dst-port 427 in
20360    0      0 allow udp from any to any dst-port 631 in
20370    1    104 allow udp from any to any dst-port 5353 in
[i]22000    0      0 allow udp from any to any dst-port 5432 in[/i]
30510   29   1963 allow udp from me to any out keep-state
30520    0      0 allow udp from any to any in frag
35000    0      0 deny log udp from any to any in
65535  897 101741 allow ip from any to any

 

[MacMark]

…

Du erzählst mir nichts neues damit. In meinem obigen Posting von gestern habe ich einen Vergleich der Betriebssysteme verlinkt bezüglich Fragmentierungs-Attacken gegen ihre Firewalls. Die ipfw von OS X blieb unbeeindruckt, der Rechner ebenfalls. Anders sah es bei Windows aus

Und daß man mit falschen Offset-Angaben vorherige IP-Paketinhalte überschreiben kann, um solche Firewalls auszutricksen, liegt in der Natur der Sache. Das hat nichts mit OS X im Speziellen zu tun, sondern mit dem Netzwerkprotokoll.

Format-String-Angriffe sind auch nichts besonderes, sondern der übliche Angriffs-Alltag. Wenn es diesbezüglich Bugs gibt, dann lassen die sich allerdings super leicht fixen. Absolut kein Weltuntergang.

Keines dieser Dinge, die er in seinem Blogeintrag anspricht, hat etwas mit der "Sicherheitsphilosphie" von OS X zu tun, sondern mit Standardprotokollen und leicht behebbaren Bug-Arten.

 

[MacMark]

…
[b]20310    0      0 allow udp from any to any dst-port 53 in
20320    0      0 allow udp from any to any dst-port 68 in
20321    0      0 allow udp from any 67 to me in
20322    0      0 allow udp from any 5353 to me in[/b]
20340    0      0 allow udp from any to any dst-port 137 in
…

Bei mir kommt keiner von diesen in der Liste vor.

 

[tjp]

Keines dieser Dinge, die er in seinem Blogeintrag anspricht, hat etwas mit der "Sicherheitsphilosphie" von OS X zu tun, sondern mit Standardprotokollen und leicht behebbaren Bug-Arten.

Bei diesen Bemerkungen frage ich mich, mit was für Programmiersprachen Du meist programmierst. Es scheint mir, daß dies überwiegend Objective-C und/oder C ist.

Denn es gibt den von ihm angeführten Zusammenhang sehr wohl, den Du einfach nicht siehst oder sehen willst. Er kritisiert unter anderem einige APIs von Cocoa, weil sie für sicherheitsrelevanten Dinge überhaupt Formatstrings erlauben. Der Gedanke, daß man dies generell nicht tun sollte, kommt Dir gar nicht.

Nicht ohne Grund verwendet die C++ Standard Library keinerlei Formatstrings in ihrer API mehr. Dagegen wird in der C Standard Library reichlich davon Gebrauch gemacht. Man kann prinzipiell ohne Einschränkung der Funktionalität auf Formatstrings verzichten. Warum tut dies Apple bei den angeführten APIs nicht?

Womit wir direkt auf die (Sicherheits-)Philsophie von MacOS X und hier im speziellem Cocoa zu sprechen kommen.

 

[MacMark]

… … Er kritisiert unter anderem einige APIs von Cocoa, weil sie für sicherheitsrelevanten Dinge überhaupt Formatstrings erlauben. Der Gedanke, daß man dies generell nicht tun sollte, kommt Dir gar nicht. …

Davon generell abzuraten, ist nachweislich unnötig, denn Java beispielsweise hat auch FormatStrings und trotzdem keine Buffer Overruns.

Auch Cocoa ist nicht per se unsicher bezüglich Formatstrings, denn bei Cocoa gibt es durchaus Möglichkeiten gegen Buffer Overruns. Die OS X malloc() Libraries haben einige eingebaute Tools, die solche Probleme im Code finden können. Es gibt in Xcode die libgmalloc (Guard Malloc), was ein aggressives Debugging ermöglicht, um Memory Overrun Fehler zu entdecken im Code.
Ich gehe davon aus, daß Apple das für eigenen Code ebenfalls verwendet. Es ist also weit weniger dramatisch als der Blogger sich das wünscht.

Nachzulesen in:
Advanced Mac OS X Programming
Mark Dalrymple und Aaron Hillegass

 

[tjp]

Davon generell abzuraten, ist nachweislich unnötig, denn Java beispielsweise hat auch FormatStrings und trotzdem keine Buffer Overruns.

1. Es ging um sicherheitsrelevante APIs und nicht um irgend welche APIs.
2. Du wirfst zwei verschiedene Probleme durcheinander. Wenn man einen Angriff via Formatstring macht, wird keine Puffergrenze überschritten. Der Witz an der Geschichte in Zusammenhang mit Sicherheits APIs ist es ja, daß man den Schadcode im String versteckt. Und für diesen String wird vorher ausreichend Speicher alloziert. Präzisierung: man will das eine Formatstring API Code aus diesem String ausführt. Dazu muß man es hinbekommen, daß diese Funktion den String nimmt und irgend einen relevanten Teil des Programmcodes überschreibt, so daß man den Programm Counter auf den eingeschleusten Code umlenken kann.

Vor solchen Attacken kann man sich nur schützen in dem man:

• Bestimmte Speicherbereiche schützt und sie als nicht mehr beschreibbar markiert (Programmcode, Konstanten etc.) und andere Bereiche als nicht mehr ausführbar (Stack, Heap).
• Erst gar keine Formatstrings in Funktionen mehr erlaubt.
• Typsichere APIs für bestimmte Zwecke definiert.

 

[tjp]

Davon generell abzuraten, ist nachweislich unnötig, denn Java beispielsweise hat auch FormatStrings und trotzdem keine Buffer Overruns.

Ein Artikel der das Licht nicht nur auf die typischen C APIs wirft.

 

[MacMark]

… Wenn man einen Angriff via Formatstring macht, wird keine Puffergrenze überschritten. … Dazu muß man es hinbekommen, daß diese Funktion den String nimmt und irgend einen relevanten Teil des Programmcodes überschreibt, so daß man den Programm Counter auf den eingeschleusten Code umlenken kann. …

Das wird durch einen Buffer Overrun gemacht.

 

[skueper]

Hm, bisher ja eine ganz interessante Diskussion. Da ich selber schon zu lange aus dem Thema Programmierung / OS "ausgestiegen" bin, kann ich die Stichhaltigkeit der meisten Argumente leider nicht nachprüfen...

...aber ich mache mir mal Gedanken aus der Sicht des normalen Users:
WENN Apples Mac OS X solche Lücken hat, und WENN diese Lücken sozusagen Standardlücken sind und WENN sie so einfach ausnutzen wären wie dargestellt: WARUM ist dann bis heute nichts Größeres bzgl. Durchbrechen der Systemsicherheit unter Mac OS X passiert? WARUM gibt es in freier Wildbahn (Edit: damit meine ich ein halbwegs massenhaftes Auftreten, nicht nur eine Infektion mit unteren 2stelligen Bereich) keine Viren, Trojaner, Spambots und Co. für Mac OS X, die unsere Äpfel unsicher machen? Mag sein, daß ich vielleicht so etwas verpasst habe, aber nach meiner Erinnerung hat es in dieser Hinsicht bei den Macs eigentlich nie großartig Probleme gegeben, zumindest seitdem ich mich ab und an drüber informiere.

An der Userbase allein kann es inzwischen doch wohl nicht mehr liegen. Seit der Einführung der IntelMacs verkauft Apple die Kisten wie blöde, da sollte es inzwischen mehr als genug lohnende Ziele geben. Und da viele Apple-User (die ich kenne) recht unbekümmert mit ihren Äpfel umgehen (getrue dem Motto "Ich benutz nen Mac und kein Windows, da bin ich von haus aus geschützt und muß mich selbst nicht drum kümmern") müsste es dort doch besonders einfach sein, oder?

Ich sehe das so, das durchaus Sicherheitslücken im Mac OS X (und auch div. Applikationen) vorhanden sind. Nur scheint es irgendwie ziemlich schwer zu sein, darauf aufbauend funktionierende Schadsoftware zu entwickeln... zumindest im Vergleich zu Windows.

 

[brandtaucher]

Zur "Virenschutz-Problematik" bei Mac OS X hier einmal ein ziemlich interessanter Link:
http://www.architektenwerk.de/mac_os_x_virenschutz.html

 

[MacMark]

Ein Artikel der das Licht nicht nur auf die typischen C APIs wirft.

Der ist leider ziemlich voll mit "könnte" und "würde den Rahmen des Artikels sprengen".

Die Stelle bezüglich Java ist ziemlich albern, weil man Exceptions fängt oder nicht. Dabei kann nichts schiefgehen in dem Sinne, daß ein Angriff Speicherbereiche überschreiben würde. Im schlimmsten Fall wird das Programm beendet. Aber Exception-Handling ist keine Problemstelle in Java.

Wenn Du etwas über Format-String-Angriffe (oder andere) wissen willst, empfehle ich das Buch
"Hack Proofing your Network" von Ryan Russel et aliud.
Deutsche Übersetzung gibt es auch unter dem Namen "Die mitp-Hacker-Bibel".

 

[daff]

Moin moin.

Interessante Diskussion hier.
Mich hat der Blog, um den es hier geht, erstmal beunruhigt. Aber da ich null Ahnung vom Innenleben meines Mac Systems habe, kann ich so garnicht beurteilen, inwiefern da was dran ist, oder nicht.
Dieser Link hier hat mich aber ein wenig beruhigt (ich hab den Artikel nicht ganz gelesen, weil ich eh nicht viel davon verstehe, aber die Zusammenfassung fand ich irgendwie einleuchtend):

Zur "Virenschutz-Problematik" bei Mac OS X hier einmal ein ziemlich interessanter Link:
http://www.architektenwerk.de/mac_os_x_virenschutz.html

Ich hatte noch nie ein Virenproblem mit meinen Macs, und das seit über zehn Jahren. Kann also nur hoffen, dass es so bleibt.

Wünsche allen nette (und vor allem virenfreie ) Ostertage!

Gruss daff

 

[tjp]

Das wird durch einen Buffer Overrun gemacht.

Auch wenn Du jetzt mit den Füßen aufstampfst, eine Formatstring-Attacke erfolgt nicht durch den 08/15 Buffer overrun, daher ist es auch nicht möglich durch simples Debuggen mittels libgmalloc den Bug in der Library zu finden. Dazu bedarf es noch einer malignen Eingabe, die diesen Fehler erst auftreten läßt. Dies passiert eben nicht während der Testphase, andernfalls gäbe es den Exploit später nicht.

Gesucht ist also eine Möglichkeit garantiert einen Exploit via Formatstring-Attacke zu verhindern. libgmalloc kann man dazu nicht verwenden, denn:

CAVEATS
libgmalloc doesn't come without some weaknesses. First, because each
allocation requires two pages of virtual memory, only about 500,000 mal-
loc allocations could conceivably exist before you run out of virtual
memory. The extravagant use of virtual memory will also cause much more
swapping, so the program will run much slower than usual -- usually two
orders of magnitude (100x).

Man kann zwar über den Geschwindigkeitsfaktor streiten, aber an dem grundsätzlichen Problem ändert es nichts. So, wir stehen wieder am Anfang. Der Produktionscode ist nicht sicher, weil jemand nicht einsehen will, daß er da ein grundsätzliches Problem hat und immer wieder behauptet er könne die Fehler ja finden. Ja, das kannst Du, aber erst nachdem das Kind in den Brunnen gefallen ist.

Das ist dieselbe alte Leier, die man immer wieder von C-Codern hört. Wenn alles so einfach wäre, warum gibt es immer wieder Buffer overruns, Zeiger Probleme etc. die alle so typisch für C Programme sind?

 

[Tengu]

Jo.

@MacMark... allgemein laufen Exploits für MacOS zuverlässiger wegen der im hiesigen Artikel angeprochenen Monokultur.
http://c9c3.blogspot.com/2007/04/apple-computers.html
Das ist aber auch einer der wenigen Punkte, wo er wirklich mal was Gescheites sagt.

Dahingehend muss man dem Autor recht geben, oder? Was die UDP Ports betrifft. Die, die er nennt, sind falsch, wenn ich keine Lesestörung hab.
Allerdings stimmt die Aussage nicht 100%ig, was ich hier schon ansprach. Der sogenannte Angriffsvektor weitet sich nicht. Lediglich die vorhandenen Möglichkeiten, sofern bekannt und vorhanden, laufen.

Alles andere bezüglich Unsicherheiten ist u. U. nicht hier besprechbar. Dazu gibts schließlich Mailinglists usw..

@tjp: Warum sind die ports da offen? bei mir sind sie zu... Kann an Snort liegen... muss ich mal nachschauen. edit: sind zu... von Haus aus.

Zudem:
Es gibt keine garantierten Exploits. Nirgendwo. Sonst wärs ja auch verdammt langweilig. Denn die Prüfung eingehenden Traffics kann auf sehr viele Arten stattfinden. Auf der anderen Seite wird auch nicht geschlafen. Fortmatstring Attacken sind nicht neu.
Ich kenne diverse IDS Algorithmen, die die angesprochene Sicherheitslücke realisieren und prüfen. Es ist nicht so, dass eine Sicherheitslücke allein ein Exploit macht. Eher macht das Exploit die Sicherheitslücke...

 

[Hobbes_]

Nur kurz und sehr allgemein

Alle Systeme bringen gewisse Lücken mit (siehe auch die ganze Diskussion dieses Threads - ich bewundere die tiefgreifende Sachkenntnis!). Je nach gewählter Systemstrategie neigt ein OS bereits grundsätzlich zu mehr oder weniger Risiken. Daneben entscheidet auch das Qualitätsbewusstsein der Firma, wie rasch oder eben wenig rasch Lücken geschlossen werden...

Einer der wichtigsten Risiken für die Sicherheit eines Systems sitzt jedoch vor dem Bildschirm...

Der menschliche Faktor ist als Admin oder gewöhnlicher Benutzer ein gewichtiger Risikofaktor, indem Risiken nicht wahrgenommen werden, das Wissen/Interesse fehlt (zB. ungesicherte WLANs), mit Passwörtern unsorgfältig umgegangen wird, Attachments unbedacht ausgeführt werden... Dies wird täglich ausgenutzt (social engineering) und ist m.E. oft der wichtigere Anteil als der rein technische Aspekt eines exploits.

Nur eine kleine Ergänzung - and just my 2 cents
psc