Marcel_75@work, Angelo scheint ja ein dicker Freund von dir zu sein, nimm's halt nicht persönlich

Und noch etwas: Deine "Hass-Predigten" in Richtung Angelo gehen doch an die falsche Adresse – immerhin ist er jemand, der auf Dinge aufmerksam macht, die manche User (u.a. leider auch Du) als gegeben hinnehmen...

Und weil Du immer wieder Wissenschaftlichkeit ansprichst: unwissenschaftlich ist Deine "Denke", da Mach Injection ein Feature und schon seit Ewigkeiten bekannt sei, biete es keine Lücken!

MacMark, findest Du das nicht langsam selbst etwas lächerlich?

Ob nun Trojaner oder Wurm – das ändert nichts an der Tatsache, dass es eine (wenn auch nur kleine und durch das Zutun des Anwenders aktivierbare) Lücke ist!

Überall (nicht nur hier) darauf herum zu reiten, dass es "ja eigentlich ein Trojaner und kein Wurm ist", bringt uns doch nicht wirklich weiter, oder?

Schon das Ende Deines ersten Kommentars in diesem Thread war nicht besonders produktiv, Zitat:
"Dann sollte ihm noch jemand den Unterschied zwischen become und get erklären bzw. ihm raten, lieber seine Muttersprache zu verwenden, wenn er nicht fit ist in Englisch "

Was hältst Du von folgendem Vorschlag: da Du ja so fit in englisch bist zeige Dich doch mal von Deiner Community-Seite und übersetze das Interview ins Englische, so dass auch auf der anderen Seite des Teiches Notiz davon genommen wird.

Aber ich gehe mal davon aus (da Du ja eh alles für Unfug hältst), dass Du Dich nicht dazu ermutigen lässt, nicht wahr?

Hartmut

Das ist alles ein alter Hut. Schon vor zwei Jahren wurde es hier veröffentlicht:
(Siehe mein Beitrag vom 31.12.04 um  23:26 Uhr in diesem Thread für mehr)

rentzsch.com/papers/overridingMacOSX

Das ist ein stinknormales Feature vom Mach Kernel. Außerdem kann man nur in seine eigenen Programm-Threads schreiben damit.

Warum er alte, dokumentierte Mach Features als Sicherheitslücke oder Bug verkauft, weiß ich nicht, das muß er mit seinem Gewissen vereinbaren. Für mich ist das pure Wichtigtuerei aus verletzter Eitelkeit, weil Apple auf seine Bugreports nicht reagiert hat. Ist ja auch klar, denn

1) er verkauft Trojaner als Würmer und
2) er verkauft Mach Features als Sicherheitslöcher

Warum sollte Apple jemanden ernst nehmen, der seine Hausaufgaben nicht gemacht hat, sprich nicht recherchiert hat, und so einen Unfug in die Welt bläst?

Auf dieses Zitat, wenn ich es richtig verstanden habe.

"MD: Kommen wir zu einem der mit Sicherheit heißesten Themen: "Mach Injection". Was hat es damit auf sich?

AL: Also erstmal vorweg: Der Umstand, dass Mach Injection möglich ist, war eine Designentscheidung bei der Entwicklung von Mac OS X. Da man sich für eine Mach-Microkernel-Architektur entschieden hatte, bekam man Mach Injection automatisch mitgeliefert.
Ich werde erstmal erklären, was klassisch auf allen Unix- und Windowssystemen möglich ist und dann, wodurch sich Mach Injection davon unterscheidet.
1) Klassisch: Man kann den dynamischen Linker dazu zwingen, vor dem Programmstart bestimmte shared libraries vorzuladen und auf diese Weise Code in vorhandene Programme injizieren. Diese Methode ist unter dem Namen der zuständigen Umgebungsvariablen, LD_PRELOAD unter Linux, DYLD_INSERT_LIBRARIES unter Mac OS X, bekannt. Auch hier ist es möglich, bestimmte C-Funktionen zu überschreiben. Das ist wirklich nichts Neues und auch schon seit Ewigkeiten bekannt.
2) Mach Injection: Mit Mach Injection kann ich alles machen, was klassisch geht, nur kann ich dies auch zur Laufzeit tun. Das heißt, ich kann auf den Speicherbereich eines beliebigen anderen Programms zugreifen und zur Laufzeit beliebigen Code hineinschreiben und sogar aus der Ferne einen neuen Thread erzeugen, der den hinzugefügten Code ausführt. Das muss man sich erst einmal auf der Zunge zergehen lassen! Dabei kann man gar nicht oft genug betonen, dass dies alles zur Laufzeit möglich ist, also wenn das Programm schon längst läuft und seinen Dienst verrichtet. Das Programm selbst (und erst recht der User) merkt davon nichts.
Des Weiteren ist noch zu bemerken, dass all dies von außen zwanghaft geschieht und das Programm keine Chance hat, sich dagegen zu wehren."

Hartmut Andryczuk
Auf was beziehst Du Dich hier?

Die Arbeit von Angelo Laub ist sicher sehr interessant und leider habe ich seinen Vortrag im CCC versäumt.

Die Nachricht von Intego vor ca. einem Jahr, einen ersten Trojaner für Mac OS X entdeckt zu haben, war hingegen eine durchschaubare Sache - etwas lächerlich und basierte auf die berühmte Panikmache.

Das ganze war ja auch nur ein "Proof of Concept" eines dänischen Programmierers (Anderson?), der beweisen wollte, daß man einen Virus in den ID3-Tags von mp3-Dateien inegrieren kann. Intego hat sich dann der Sache bemächtigt.

Das bei wachsendem Marktanteil von Apple die Attraktivität von Angriffen natürlich zunimmt, dürfte klar sein. Hoffen wir also weiter, daß wir eine Randgruppe bleiben.

Programmcodes auszuführen, ohne daß es ein Sudoer merkt, ist schon eine herbe Sache. Aber zum Glück sind beinahe alle nicht so begabt wie Angelo.

Wenn das alles stimmt (und ich gehe mal davon aus) kann man es ja mit der Angst zu tun bekommen.

Naja, das sollte man relativieren. Solange es keine Möglichkeiten gibt, durch Fehler im IP-Stack über offene Ports einzubrechen, gilt die Devise: Nicht auf alles klicken, das auf obskuren Wegen (Websites, Mail) auf den Rechner gelangt. Die Möglichkeit von Obj-C, zur Laufzeit Methoden zu tauschen, klingt virentechnisch interessant, allerdings muß man solche 'bad binaries' erst mal auf den Rechner lassen.

Mac OS X ist konzeptionell für Malware nicht weniger anfällig als andere Systeme, aber mit BSD als Unterbau und dem Fehlen eines allmächtigen - tief im Systemkontext verwurzelten - InternetExplorers ist man im Gegensatz zu Windows doch auf einer recht sicheren Seite.

Mit der weiteren Verbreitung von Mac OS X werden sicherlich auch einige Autoren von Malware auf den Geschmack kommen, aber ich bezweifle, dass eine ähnliche Situation entstehen könnte, wie sie heute auf Windows-Systemen (leider) Alltag ist.

Einige angesprochene Dinge scheinen mir normal zu sein für Unix wie zum Beispiel, daß alle Unix-Kommandos während des Systemstarts unter root (System) ausgeführt werden, wenn sie in entsprechenden Verzeichnis dafür liegen und korrekt eingerichtet sind.

Und disk quotas lassen sich wie bei jedem Unix auch bei OS X setzen. Nur ist das für Heimuser nicht so relevant.

Dann bringt er den schon zigmal durchgekauten und für praktisch irrelevant befundenen proof of concept "Wurm"…

Dann sollte ihm noch jemand den Unterschied zwischen become und get erklären bzw. ihm raten, lieber seine Muttersprache zu verwenden, wenn er nicht fit ist in Englisch

Also sehr aufregend ist die Folie nicht.

Nur weil es closed source ist, zu behaupten es sei unsicher. Naja. In meinen Augen erst mal Geschwätz.

Mit setuid ausgestatte Tools gibt's auf jedem Unix, ob's bei Apple zu viele sind kann ich nicht beurteilen.

Preferences lassen sich so einstellen, dass eben immer ein Password eingegeben werden muss bevor man etwas sicherheitsrelevantes ändert. Schreibt er ja selbst. Den Exploit den er dort hat, hat er wohl in Worten erklärt. Aus den Folien wird's nicht klar.

Und ich kann weitere Admin-User hinzufügen. Äh ja, na und?

Das mit den Executables und den falschen Icons hatten wir auch schon. Gähn. Wer alles anklickt was er irgendwo herbekommt ist so doof wie ein Windows Outlook-User.

Mit dem Rest hat er recht. Unschön, aber Apple wird's schon fixen. Bekannt sind die Sachen ja seit einer Weile. Das mit den dynamic bindings ist schon öfters diskutiert worden (Omnigroup).

my 2 cents:

Der erste echte MacOS X Wurm existiert!

Um Eure Nerven zu schonen gleich vorweg folgende Anmerkung: es ist nach wie vor eine (ansatzweise unüberlegte) Aktion des Nutzers nötig, um diesen Wurm zu aktivieren, ein direkter Zugriff "von außen" auf Euer geliebtes MacOS X ist (bei sicher konfigurierten Systemen) nach wie vor nicht möglich (oder noch nicht bekannt... .

Außerdem möchte ich im Voraus darauf hinweisen, dass es sich bei dem originalen Wurm bisher um ein "Proof-of-Concept" handelt, böswilliger Code wird von diesem also NICHT ausgeführt!

Aber weiter im Text:

Mit einiger Spannung besuchte ich gestern den Chaos Communication Congress (http://www.ccc.de/congress/2004/index.de.html) im Berliner Congress Center am Alexanderplatz (http://www.bcc-berlin.de).

Für 15 Uhr stand "Practical Mac OS X Insecurity: Security Concepts, Problems, and Exploits on Your Mac" auf dem Programm, vorgetragen von Angelo Laub.

Neugierig machte mich vor allem die Ankündigung "just one more thing" – und sie sollte ihre Wirkung nicht verfehlen...

Aber der Reihe nach: einleitend wurden einige Vorteile von MacOS X erwähnt (alle Netzwerkdienste sind standardmäßig deaktiviert, Benutzer sind nie als root angemeldet, viele Einstellungen können nur mit einem Administrator-Kennwort geändert werden usw.), schnell kam man aber auf die ersten Probleme zu sprechen: Sicherheitskomponenten mit geschlossenem Quellcode (wie z.B. Admin.framework), unsichere Voreinstellungen etc.

Die "wunden Punkte" wurden dann auch schnell konkretisiert: anhand eines kleinen AppleScripts wurde z.B. vorgeführt, wie ein Benutzer einen neuen Admin-Benutzer anlegen kann, ohne dafür ein Passwort eingeben zu müssen. Voraussetzung war dafür allerdings (wenn ich mich nicht irre) 1. dass der angemeldetet Benutzer Admin-Rechte hat und 2. dass der Punkt "Für das Freigeben jeder geschützten Systemeinstellung ein Kennwort verlangen" (zu finden über Systemeinstellungen/Sicherheit) nicht aktiviert ist.

In meinen Augen handelt es sich dabei allerdings nicht um eine wirkliche Sicherheitslücke sondern eher um eine "unglückliche Voreinstellung" des Systems: wäre der Punkt "Für das Freigeben jeder geschützten Systemeinstellung ein Kennwort verlangen" standardmäßig aktiv, würde das besagte AppleScript nicht zum Ziel kommen! Oder verstehe ich das falsch?

Die nächste angesprochene Sicherheitslücke betraf das fehlerhafte Setzen von Zugriffsrechten durch Installationsroutinen (siehe dazu

Dabei ist speziell das Setzen von falschen Zugriffsrechten für den Ordner /Library/StartupItems problematisch, da darin enthaltene Programme mit root-Rechten ausgeführt werden. Bekanntlich kann das Festplattendienstprogramm fehlerhafte Zugriffsrechte reparieren – das Problem ist nur, dass /Library/StartupItems dabei nicht mit inbegriffen ist!

Dies ist definitv ein schwerwiegender Fehler und bis heute nicht gefixt (obwohl schon seit März 2004 bekannt)!

Immerhin existiert ein Workaround:

Die beiden Zeilen:
chown -R root:wheel /Library/StartupItems
chmod -R og-w /Library/StartupItems
in /etc/rc oder /etc/daily gespeichert schaffen Abhilfe.

Dabei stellt sich mir allerdings folgende Frage: wenn man ein System-Update macht (beispielsweise von 10.3.7 auf das sicherlich noch kommende 10.3.8), werden dann nicht eventuell solche selbst manipulierten Dateien überschrieben, so dass sich diese Sicherheitslücke erneut öffnet? Oder ist es gar denkbar, dass andere Programme oder Installationsroutinen darauf zugreifen (Cocktail, Xupport u.ä.)?

Natürlich durfte bei diesem Vortrag auch nicht der schon mind. seit Juni 2004 (siehe dazu bekannte schlampige Umgang mit Passwörtern in MacOS X unerwähnt bleiben - dass Passwörter im Klartext in das Swap File ausgelagert werden ist schon ein ziemlich fetter Brocken und wirklich mehr als peinlich für Apple!

Für alle, die es bisher nicht mitbekommen haben: ein
sudo strings /var/vm/swapfile0 |grep -A 4 -i longname
im Terminal genügt um mit ziemlich hoher Wahrscheinlichkeit Eure Passwörter im Klartext zu finden
(Voraussetzung allerdings auch hier: der angemeldete Benutzer benötigt Admin-Rechte).

Bis heute existiert kein wirklicher Fix für Panther, die Lösung von Andreas Schwarz (http://andreas-s.net/osx-encrypted-swap.html) ist leider sehr instabil.

Mit der Einführung von MacOS X 10.4 Tiger wird es zwar die Möglichkeit geben, Swap-Files verschlüsseln zu lassen, 1. ist das aber sehr performancehungrig und 2. leider keine Lösung für alle Nutzer mit MacOS X 10.3 Panther (und älter).

Fakt ist, dass dies in anderen Unix-Umgebungen nicht so "lässig programmiert" ist – hier hat Apple eindeutig gepennt!

Eine weitere angesprochene Sicherheitslücke betraf die Möglichkeit eines Denial of Service Angriffs auf Apples Personal Filesharing.

Aktiviert man Personal Filesharing, wird automatisch ein Gastzugriff aktiviert, welchen man (zumindest über die Systemeinstellungen) nicht deaktivieren kann.

Dieser Gast-Zugang hat bekanntlich Zugriff auf eine Drop Box, wobei das Limit für dort hinein kopierte Daten einzig und allein die Festplatte ist, was widerum die Möglichkeit eröffnet, den Festplattenplatz mit beliebigen Datenmüll vollzuschreiben!
Was passiert, wenn sich der Festplattenspeicher dem Ende zuneigt, kann sich sicher jeder selbst ausmalen (nicht umsonst empfehle auch ich immer wieder, darauf zu achten, dass man mind. 1 GB (besser 4 bis 5 GB) freien Platz für die Swap Files auf der Systempartition hat)...

Ein nettes Programm namens "RendezPoo" führte dies dann auch erfolgreich vor!

Um sich vor solchen Szenarien zu schützen kann man den Gast-Zugriff per Hand in
/Library/Preferences/com.apple.AppleFileServer.plist
deaktivieren, indem man die Zeile
guestAccess
in
guestAccess
ändert.

Auch hier stellt sich mir die Frage, inwieweit solch eine eigenhändig manipulierte Voreinstellungsdatei durch ein Systemupdate oder ähnliches wieder auf ihre ursprünglichen (unsicheren) Werte "zurückgesetzt" wird?

Die nächste und wohl mit Abstand bedeutendste Sicherheitslücke betraf das Thema "Mach Injection".

Wenn ich es richtig verstanden habe geht es dabei um die Möglichkeit, in LAUFENDE!!! Programme Code einschleusen und diesen ausführen lassen zu können.

Als Konsequenz ist es laut Angelo möglich, auch Closed-Source-Komponenten wie z.B. den Finder oder Safari zu manipulieren! Man könnte also fast alles was man möchte mit jedem laufenden Programm anstellen...

Somit hätte man eine Art rootkit, obwohl man keine root-Privilegien hat – um nicht zu sagen: eine ziemlich gute Atmosphäre für jede Art von Viren, Würmern, Trojanern und Malware!!!

Die Auswirkungen für die Sicherheit des Systems dürften durch "Mach Injection" in jedem Fall katastrophal sein!

Eine weitere Sicherheitslücke betrifft die Möglichkeit, ein ausführbares Programm z.B. als MP3 tarnen zu können (eigentlich nahm ich an, dies wäre von Apple gefixt – offensichtlich ist dem nicht so).

Und dann gab es "one more thing"
der erste echte MacOS X Wurm ist ein Programm, dass sich als PDF-File tarnt (wobei sicherlich jede beliebige andere Dateiart denkbar wäre).
Wenn man diesen per Apple Mail empfängt und doppelklickt, wird Vorschau geöffnet und man sieht ein PDF.
Im Hintergrund allerdings wird ein Programm gestartet, was theoretisch alles mögliche anrichten könnte (besonders in Kombination mit den oben erwähnten Sicherheitslücken).

Angelo lies lediglich einen Text in der Konsole erscheinen der sagte, man sei "gerooted"...
Dazu gab es eine fiese Lache zu hören...

Wenn man sich den Paketinhalt dieses "PDFs" anzeigen lässt oder die Dateiinformation einblendet sieht man, dass es sich nicht um ein normales PDF handelt!

Workaround: PDFs nur mit Adobe Reader (aktuell Version 7) öffnen, statt Mail besser Thunderbird oder Entourage benutzen, allgemein keine über das Netz empfangenen Dateien per Doppelklick öffnen sondern erst "überprüfen".

Übrigens: nicht erwähnt wurden die seit diesem Jahr kursierenden (und sich stetig weiterentwickelnden!!!) rootkits für MacOS X (weaponX bzw. wx, osxrk, opener etc.) – 2005 könnte heißer werden, als wir MacUser es uns wünschen...

Eigentlich hatte ich vor, einen ausführlichen Artikel (eventuell inkl. Interview) zu diesem Thema zu schreiben, da Oliver Kurlvink aber schon auf den Vortrag des CCC verwies (das PDF siehe oben) und Angelo leider noch nicht auf meine Mail geantwortet hat (er ist wohl noch unterwegs nach Bonn oder ruht sich von den 3 Tagen CCC aus... empfand ich es als meine Pflicht, schon im Voraus etwas "aus dem Nähkästchen" zu plaudern...

Korrektur:

Um sich vor solchen Szenarien zu schützen kann man den Gast-Zugriff per Hand in
"/Library/Preferences/com.apple.AppleFileServer.plist"
deaktivieren, indem man die Zeile
"guestAccess "
in
"guestAccess "
ändert.

Hoffe jetzt wird es richtig angezeigt?

Sorry, weiß leider nicht wie ich das posten kann, eventuell muss es ein Moderator editieren.

Ich beschreibe es mal:

Im Ordner "Library" und dort im Ordner "Preferences" gibt es eine Datei namens com"PUNKT"apple"PUNKT"AppleFileServer"PUNKT"plist

Die Zeile wo etwas wie
"key guestAccess true"
steht muss dann in
"key guestAccess false"
geändert werden.

Jetzt hat's geklappt, hoffe ihr könnt das nachvollziehen.

Ach ja, was ich vergaß zu erwähnen:
das Programm, was bei Doppelklick auf das vermeintliche PDF gestartet wird, kann sich automatisch an alle im Adressbuch enthaltenen Kontakte versenden.

Laut Angelo ist im Moment also die Kombination Vorschau+Mail+Adressbuch der ideale Nährboden...

Will er uns belehren, oder was ?
Das sind doch keine Neuigkeiten mehr.

Gaspode
(...) Apple wir's schon fixen

Der Meinung bin ich auch !

Ich kann mir beim besten Willen nicht vorstellen, daß die Mac-Gemeinde ein adäquates Ziel für Malware(Entwickler) darstellt, auch künftig nicht.
Dafür ist der "Kreis einfach zu geschlossen" und der Informationsfluß unter den Macianern, sollten wirklich mal ernstzunehmende Sicherheitsbedrohungen auftreten, zu groß, so daß man im Zweifelsfall immer noch die Möglichkeit haben wird, entsprechende Maßnahmen zu ergreifen respektive mit einem Fixing von Apple, das die vorerwähnten "Lücken" stopft, rechnen zu können.

Angst vor Pseudowürmern ? Lächerlich !

Wer nicht auf alles klickt, was auf obskure Art und Weise auf seinen Rechner gelangt sein könnte, der befindet sich wohl auf der sicheren Seite.

Abschließend kann man, so glaube ich, trotz aller Panikmache, allen gratulieren, die auf das bislang sicherste System setzen.

Wehe dem (religiöser Dativ), der kein Obst mag...;-)

marcel
Müsstest Du glaube ich so schreiben:
< key >guestAccess< / key > < true / >
zu
< key >guestAccess< / key > < false / >

die Leerzeichen müssen natürlich dann wieder raus.

@Hot Mac und an alle anderen, die ständig nur abwimmeln wollen wenn es um die Sicherheit von MacOS X geht:

1. Der Chaos Communication Congress ist die bedeutendste europäische Hackerversammlung! Wer dort war wird bestätigen können, dass die Anzahl vorhandener iBooks/PowerBooks im Vergleich zu den Vorjahren expotentiell höher war. Was dies mit sich bringen könnte, kann jeder an drei Fingern abzählen – 2005 wird auf alle Fälle spannend für uns MacOS X Nutzer...
Solchen Nerds erzählen zu wollen, dass dies alles nur "Panikmache" sei ist schon mehr als nur arrogant – es ist in meinen Augen schlicht und ergreifend ignorant!!!

2. Informiert Euch etwas näher bezüglich des Themas "Mach Injection" und Euch wird das Lachen im Halse stecken bleiben (nicht falsch verstehen, ist nicht böse gemeint).

3. Um noch einmal auf "die üblichen Verdächtigen" (wie sie auch Onkel heise gern nennt... zurückzukommen: die Leute rund um den CCC haben schon ganz andere Dinge "geknackt" – ein Betriebssystem wie MacOS X hat definitiv auch seine Design-Schwächen, die früher oder später ausgenutzt werden könnten - wer weiß, vielleicht waren die letzten Monate/Jahre ja auch nur die sprichwörtliche "Ruhe vor dem Sturm" (nicht bezogen auf die Anzahl der Stürme sondern die Stärke eines Einzigen wohlgemerk!!!).

4. Angelo Laub geht es vor allem um die Tatsache, dass Apple sich in mancher Beziehung mehr Zeit als nötig lässt, um Dinge zu fixen.
Er mailte Schwachstellen an Apple, wurde vertröstet usw.
Kurz vor seinem Vortrag erhielt er eine Mail von Apple, in der er u.a. gebeten wurde, eine spezielle Schwachstelle nicht zu veröffentlichen, bis das nächste SecurityUpdate erscheint.
Allerdings konnte er sich ein Schmunzeln nicht verkneifen, da es in dem Moment schon zu spät war (immerhin hatte Apple einige Monate Zeit und wimmelte anfangs - wie auch hier im Forum - immer nur ab).
Der Quellcode wird demnächst veröffentlicht, erste wirklich gefährliche Exploits werden dann sicher nicht lange auf sich warten lassen - der Wettlauf zwischen Apple (mit dem Fix der Schwachstelle) und den Hackern wurde also sozusagen gestern abend offiziell eingeleutet...

5. Bei der "Tarnung" von ausführbaren Programmen als Dateien handelt es sich nicht um die Variante, die vor einigen Monaten entdeckt (und von Apple recht schnell gefixt) wurde – fragt bitte nicht mich was genau der Unterschied ist, es ist aber definitiv eine "neue Variante"!

MacMark

Jaja, "become" und "get" sind für den Deutschen schon schwierig
Ich durfte kürzlich einem Referat lauschen, in dem einer der Referenten wortwörtlich sagte "I become a passport"

And then he became a passport *pling*

Marcel_75@work

Ich wollte niemandem auf den Schlips treten und bezog mich auch nicht auf Deinen Beitrag !

Mein Posting ist unglücklicherweise erst nach dem Kilometer;-), den Du hier zum Thema verfaßt hast erschienen, so daß man, da hast Du wohl Recht, den Eindruck gewinnen kann, ich wollte hier irgend etwas "schön-reden" oder würde die Wichtigkeit des Themas auf die leichte Schulter nehmen.

Unterstelle mir bitte nicht, auch nicht unterschwellig, ich sei ignorant.

Wenn dem so wäre, dann würde es mir nicht im Traum einfallen, Deinem Vorwurf überhaupt noch die geringste Aufmerksamkeit zu schenken.

Ich hoffe, Deiner offensichtlichen Annahme, ich wollte Deinen Beitrag als lächerlich darstellen, konnte somit widersprochen werden.

Man kann alles sagen, allerdings nur im richtigen Ton...







;-)

@Hot Mac: wie Du selbst ja schon erahntest nahm ich an, Dein ursprüngliches Posting bezog sich auf meinen "Kilometer"-Beitrag (welcher ja wie erwähnt so lang wurde, da er eigentlich als "Artikel" gedacht war...

Nehme also alles zurück – somit bezieht sich mein Kommentar nunmehr nur noch auf die wahren "Ignoranten" unter uns MacOS X Usern!

Sorry noch mal!

Marcel_75@work

Schwamm drüber.
Danke für Deine Mühe

Was mir allerdings auffällt: bin etwas erstaunt, dass noch keine (zumindest keine mir bekannte) Mac-spezifische Quelle näher auf die gesamte Problematik eingeht – besonders bezüglich des Themas "Mach Injection" erhoffe ich mir demnächst etwas detailliertere Hintergrundinformationen...

Sobald ich dazu mehr sagen kann werde ich es veröffentlichen, es sei denn jemand aus dem Forum kann dies schon genauer erklären?

Eventuell bekomme ich ja heute im Laufe der nächsten Stunden noch eine Mail von Angelo höchstpersönlich... abwarten!

Zur "Mach-Injection":

Er schreibt, man könne Methoden von closed source apps wie Safari oder Finder zur Laufzeit überschreiben (override).

• Wie will er Methoden ersetzen, die er nicht kennt? (closed source) Er muß die Signatur (Methodenname und Parameter) kennen, um überschreiben zu können.
• Die Möglichkeit besteht nach seiner Aussage, wenn überhaupt, nur bei C/Objective C Programmen.
• Der Patchcode müßte erstmal auf meinem System ausgeführt werden. Wie kommt er dahin und wie wird er ausgeführt? Social Engineering, sprich: Man trickst mich aus, so daß ich es selbst tue? Auf die Weise kann man eh alles erreichen. Oder als Trojaner, sprich Programm tut etwas anderes, als ich erwarte. Damit ging und geht aber auch schon immer alles.

Apple hat sicher einen Grund, warum diese Möglichkeiten in der Mach-Kernel API und in der Objective C Runtime Library angeboten werden. Sie alleine reichen aber nicht aus, um ein fremdes System beschädigen zu können, weil deratiger Patchcode erst auf mein System gelangen und zudem ausgeführt werden muß.

@MacMark: wie gesagt habe ich vom Programmieren leider überhaupt keine Ahnung, aber Angelo erklärte es auf Nachfrage einiger Teilnehmer kurz (und später in persönlicherer Runde auch noch mal ausführlicher, wobei ich allerdings nur "Bahnhof" verstand).

Was ich 1:1 unterschreiben würde und jedem MacOS X Benutzer als "Richtlinie für sicheres Computing am Mac" zur Kenntnisnahme ans Herz legen möchte kann man übrigens hier finden:

Solange meine angführten drei Punkte (•) oben nicht schlüssig beantwortet sind, kann er mit der "Lücke Injection" nichts anstellen. Schick ihm mal einen Link auf dieses Forum Dann kann er ja selbst antworten.

Sein Vortrag sieht mir eh ziemlich nach Effekthascherei aus. Auch wundert mich, daß ein Bonner Student der Fächer Physik, Astronomie und Mathematik solche Vorträge hält…

Marcel_75@work hat mich freundlicherweise auf diese Diskussion aufmerksam gemacht und ich bin bereit, klaerend einzugreifen. Dazu moechte ich erstmal ein paar Punkte aufzaehlen, die in den einzelnen Beitraegen angesprochen wurden.

1. MacMark: Bei der /Library/StartupItems-Luecke ist das eigentliche Problem nicht, dass es diesen Ordner gibt, sondern dass er die flaschen permissions hat, was bedeutet, dass jeder(!) Programme als root ausfuehren kann, auch der nichtprivilegierte normaluser. Ein weiterer schlimmer Bug ist, dass das "Repair Permission" von Apple diese permissions nicht repariert.

2. MacMark: "To get root" ist eine im Englischen gebraeuchliche Redewendung. Man kriegt ja schliesslich auch was, nicht wahr? Also, erst nachdenken, dann posten, vor allem wenn man augenscheinlich keine Ahnung hat.

3. Gaspode: Dein Kommentar ist eigentlich zu niveaulos, um darauf zu antworten. Aber um es trotzdem klarzustellen: Das Problem bei OS X ist nicht, dass es setuid root Programme gibt. Das Problem ist, dass normale Programme, die im Kontext des Users ausgefuehrt werden, setuid helper applications benutzen. Das Sicheheitskonzept beruht dann darauf, dass nicht bekannt ist, wie sich das Programm gegenueber dem helper tool authentifiziert. Findet man das jedoch durch reverse engineering raus, kann man diese setuid tools jedoch nach belieben steuern. Auch kann ich in normale Programme z.B. per Mach Injection code einschleusen und ausfuehren, was dazu fuehrt, dass ich auch so das helper tool zu dingen zwingen kann fuer die es nicht vorgesehen ist. In einem open-source System gaebe es so eine Sicherheitsluecke erst gar nicht, weil man gezwungen ist, direkt ein sicheres Sicherheitskonzept zu entwickeln.

4. Gaspode: Was zaehlt, ist die default Einstellung. Es geht nicht, dass ich ein System ausliefere, wo man ohne zusaetzliche Authentifizierung durch Passwort beliebige befehle als superuser ausfuehren kann. Das Skript, das ich waehrend meines Vortrags vorgefuehrt habe, hat unter Ausnutzung der System Preferences eine root-shell aufgemacht. Die Folien sind natuerlich kein Ersatz vollstaendiger Ersatz fuer das Anschauen eines solchen Vortrag.

5. Hot Mac: Deine Meinnung, die Mac Plattform waere voellig uninteressant und eingeschworen, sodass sie niemals fuer Viren- und Wurmschreiber interessant sein wuerde, kann ich nicht teilen. Spaetestens wenn OS X einen bestimmten Marktanteil erreicht (und im Moment ist der Anteil deutlich am Steigen) wird die Plattform interessant, insbesondere, wenn es so vergleichsweise einfach ist, Wuermer dafuer zu schreiben.

6. MacMark: Mach Injection und das Ueberschreiben von vorhandenen Funktionen in einem laufenden Programm geht tatsaechlich meines Wissens nach nur mit Programmen, die in C oder Objective-C geschrieben sind. Aber das sind ja auch die meisten Programme auf dem Mac, nicht wahr? Im Falle von Objective-C ist es sogar trivial, die kompletten Header (also alle Klassen- und Methodendefinitionen mitsamt Signatur) aus dem Binary auszulesen. Dafuer gibt es eigens das Tool class-dump. Genau das macht das Patchen von closed-source Software auf dem Mac so einfach.

7. MacMark: Wie kommt der Code dahin? Ganz einfach, man verstecke ihn in einem Dokument beliebigen Dateityps, z.b. pdf, mp3, jpg. Viel social engineering ist dann nicht mehr noetig. Du kannst mir schliesslich nicht erzaehlen, dass du bei jedes pdf Dokument vor dem Oeffnen erst einer Analyse unterziehst. Der gewoehnliche User tut dies jedenfalls nicht.

8. Marcel_75@work: Danke fuer die klaerenden Worte und guten Beitraege. Ich habe uebrigens bereits auf deine Mails geantwortet. Da mein Mailsystem einwandfrei funktionieren zu scheint, neige ich dazu zu vermuten, dass dein web.de die emails einfach noch nicht zugestellt hat (kommt bei denen leider oefters vor). Ich wuerde mir mal ne "ordentliche" Emailadresse zulegen.

Mit Gruss,
Angelo Laub

@Angelo: danke für Deine ersten klärenden Auskünfte!!!

Deine Mails sind inzwischen auch angekommen, aber Du hast natürlich recht - eine "ordentliche" E-Mail-Adresse "tut mal Not" bei mir...

Moin.
Bin grade erst wieder vom CCC zurück. Ich war auch in besagtem Vortrag und fand ihn bestenfalls reißerisch. Der Angeführte Vergleich mit der Qualität von "Onkel (Trollforum) Heise" ist durchaus berechtig.
Auf dem Congress sind durchaus Top-Leute zugegen, dass heist aber nicht, das alle Teilnehmer das NonPlusUltra sind...
Auf der anderen Seite jemand nach seiner "Herkunft" zu berurteilen ist auch ein bisschen schwach...
Es ist bei der Ansammlung von internationalen Größen bestimmt nicht einfach vor 400 Nerds zu stehen...

Der Punkt mit dem Häckchen für Passwortabfrage als Voreinstellung ist zwar gerechtfertig, würde ich allerdings als "low Risk" einstufen. Weil es ohne größeren Aufwand behebbar ist. Selbst der "Demo-Rechner" seines Bekannten hatte das Häckelein gesetzt

Das mit den StarupItems ist schon ärgerlicher, und sollte zeitig gelöst werden. Das sehe ich aber momentan auh nicht so tragisch, weil ich mein Pb mermanent mit mir herumschleife und keine andere Person an die Tastatur oder sich einloggen darf...

Wegen dem gekrypteten Swap-Space. Wenn ich root bin (siehe das sudo) darf ich auf dem Rechner eh alles. Wenn ich unbedingt von jemand anderem (auf meinem Rechner) Passwörter brauche installiere ich einen Keysniffer...
Der Punkt bei dem Krypt-Swap ist allerings: Wenn mal der Strom (unfreiwillig) ausfällt, die Passwörter ungesichert auf der Platte stehen und der Grund für den Stromausflal die Platte mitnimmt ...
Wenn du so paranoid bist, dass du dir um Krypt-Swap Sorgen machst würde dir raten sofort auf OpenBSD zu wechseln (gibts auch für den Mac). Das sind die einzigen die derzeit Standardmäßig den Swap-Space krypten (und auch sonst extrem sichere Dinge)...
Das andere für Mac OS ist wohl eher ein Hack als ein Fix

Die FileSharing Option nutze ich nicht.

Ob Mach Injection eine Sicherheitslücke ist weis ich noch nicht. Es ist aber auf jeden Fall interessant. Erstmal kann man nur die eigenen User-Prozesse Injecten. Wie er dazu kommt, das als Rootkit zu bezeichnen weis ich nicht.
Zu MacMark: Scheinbar tragen die Objective-C Binaries standardmäßig ihre Header mit sich herum (ählich bei Java-Reflection). Auf die Weise kann man dann schon sehen was die Objekte tun (Parameter etc...). Die Bezeichungen sind recht sprechend. In Kombination mit dem "Wurm" ist wird das bestimmt auch noch interessant.

Sicherheit "for free" gibt es nicht. Das was OS-X so anbietet ist ordentlich und kann mit ein paar Klicks gerichtet werden. Vielleicht sind desswegen so viele Macs auf dem CCC gewesen

Ich werde daher abwarten und ein bisschen mit Injection spielen. Mal schauen ob ich dem NSString beibringen kann, alles automatisch in leet-speak zu übersetzen ...

Wer sich für Sicherheit interessiert kann außer den Üblichen Verdächtigen mal (NSA) lesen, insbesondere der Configuration Guide für OSX...

n8

Oliver KurlvinkNette Idee, es wird nur leider nicht funktionieren. Die Keychain kann auch ueberlistet werden, Passworter preiszugeben, obwohl sie eine derartige Abfrage hat. Die Keychain speichert sogar einen SHA1 Hash aller vertrauenswuerdigen Programme. Aendert sich dieser, so fragt sie nochmal nach. Wenn ich nun allerdings zu Laufzeit Code in eine vertrauenswuerdige Software injiziere, aendert sich dieser Hash nicht und man bekommt alle Passwoerter.

Angelo Laub

Ich freue mich sehr darüber, daß Du so reges Interesse zeigst.
Natürlich möchte ich mit meinen eher "rudimentären" Kenntnissen (die Eingeweide des Systems betreffend) keineswegs mit Dir in einen Disput geraten, doch kann ich mich des Eindrucks leider nicht erwähren, daß Du die Punkte, die MacMark bereits erwähnte, nicht aus der Welt schaffen respektive 100 prozentig beantworten konntest.
Natürlich verneigen wir alle unser Haupt vor Dir, dem weltbesten Hacker - wie mir scheint -, aber mit "Larifari-Postings" wird hier wohl keinem gedient sein.
Übrigens möchte ich Dich doch bitten, Dich nicht allzusehr im Ton zu vergreifen.
So etwas ist einfach unreif und ist der eigentlichen Sache nicht dienlich.

Bevor Du jetzt gleich auf die Palme hechtest..., cool down..., lies Dir die Postings doch nochmals durch und melde Dich einfach mit einem konstruktiven Beitrag, ohne unterschwellige Beleidigungen.

Vielleicht gibt es ja einfach nur ein Kommunikationsproblem, oder so...

Angelo Laub

Bezüglich get / become ist zu erwähnen:
"With Objective-C it gets interesting..." it becomes interesting
"It gets even cooler... " it becomes even cooler
und
"you can get root" you can become root (totz Deiner Ausrede)

Was glaubst Du, ist der Grund, warum man so patchen kann? Es hat doch sicher einen Sinn, warum in der API/Library so etwas angeboten wird.

"Code Injection" ist also genauso gefährlich wie jeder Trojaner oder jedes Social-Engineering, weil es nur so schaden kann. Wenn ich aber den User meinen Trojaner starten lasse, dann brauche ich "Code Injection" nicht, um mindestens genauso gefährlich zu sein.

/Library/StartupItems hat diese Rechte:
drwxrwxr-x 5 root admin 170 2 Dec 2003 StartupItems
Man sieht, daß nur root und die Gruppe der Admins schreiben dürfen, alle anderen dürfen hier nicht schreiben. Das ist vollkommen in Ordnung so. Und wenn root/admin dort etwas installiert, dann ist es von Unix so gewollt, daß es beim Booten unter root ausgeführt wird. Das ist so bei Unix. Beim besten Willen kann man hier keinen Fehler sehen.

Apropos "keine Ahnung". Du bist ja locker drauf. Weißt Du wer ich bin?

Angelo Laub
Denial Of Service: Man kann doch ganz einfach disk quotas zuteilen wie bei jedem Unix. Dann ist diese "Lücke" auch zu und kein Gast oder sonstwer macht die Platte voll.

Nur - bei einem Heimrechner hinter einem Router ist auch das wohl kaum notwendig.

MacMarksach doch maal .

Ties-Malte
Schau auf meine Homepage, dort steht mein fachlicher Hintergrund. Glaube nicht, daß der Astronomiestudent mithalten kann.

In folgendem Thread wird übrigens auf höherem Niveau über das Problem diskutiert (schade, dass das im mactechnews-Forum offensichtlich nicht möglich ist):

Marcel_75@work[/url]

Warum? Wer verbietet Angelo denn, in niveauvoller Art auf meine ungeklärten Einwände zwei bzw. drei Postings weiter oben zu antworten?

MacMark
Mit dieser Bemerkung gegenüber Angelo hast Du Dich endgültig disqualifiziert...

Wirklich arm so etwas!

Und tschüß...

Marcel Schön, daß Du das beurteilen kannst.

Hot MacSorry, aber das ist arroganter Quatsch!
Mail.app ist dafür da, Mails entgegen zu nehmen, und wenn ich von Freunden ein jpg, mp3 oder pdf bekomme, schaue ich´s selbstverständlich an. Oder prüfst und analysierst du wirklich jede Datei vorher von allen Seiten? Dann käme ich zumindest nicht mehr zum arbeiten...

Wenn du dir dann noch den OT-Teil bei macnews ansiehst, merkst du, dass (von Mac-usern!! ) auf alles geklickt wird, was nicht niet- und nagelfest ist, oder wie sonst wäre zu erklären, dass (beispielsweise) Schnappie lange durch war quer durch alle Agenturen, bevor es in den Hitlisten ganz oben auftauchte? Nee nee, da sind Mac-user nicht anders als alle anderen auch.

Ansonsten hätte ich mir von diesem Thread aber auch etwas mehr Substanz erwartet. Das ist doch so eigentlich nicht txpisch für dieses Forum... egal - ich gehe jetzt Kultur genießen @@

… zumindest habe ich mich bislang an nachprüfbare Fakten gehalten, sowohl was die sogenannten "Lücken" angeht, als auch alles, was "Angelo" angeht. Er hingegen nimmt sich heraus, mir "keine Ahnung" zu unterstellen und andere User "niveaulos" zu nennen und so weiter.

Wenn sich hier jemand ganz derbe im Ton vergreift, dann ist das "Angelo".

Ich frage mich, warum sich Angelo Laub zwar von Marcel_75@work hofieren läßt, aber auf die berechtigten Argumente von Donar- überhaupt nicht eingeht. Stattdessen disqualifiziert Marcel_75@work das ganze Forum hier gleich als (sinngemäß) niveaulos. Es duftet ein wenig nach Arroganz hier...

Kann man denn jetzt noch mit den gewünschten Antworten rechnen

an die "NIVEAUVOLLEN"

Wer über kein Niveau verfügt, der sollte es sich lieber nicht anmaßen, andere dahingehend unterrichten zu wollen, daß sie angeblich über kein Niveau verfügen.

Niveaulos ist es..., wenn man von jemandem höflichst aufgefordert wird, auf seine Fragen zu antworten, sich dann aber in Ermangelung jeglicher Kompetenz lieber aus der Affäre zieht.


Ich glaube, die offenen Fragen werden wir wohl selbst beantworten müssen.



Hat sich dieser Angelo, mit Ver"Laub" frage ich nach, jetzt endgültig aus diesem Thread ausgeklinkt, oder hat man da noch etwas zu erwarten

Wenn nicht, dann schnalle ich jetzt die Ski auf meinen Kombi und wünsche "EUCH ALLEN" einen guten Rutsch ins Neue Jahr und alles erdenklich Gute.

Oliver
Ob Du nun nur root oder auch die Gruppe admin zuläßt, ist schlußendlich gleichgültig, da jeder Amin für sudo berechtigt ist und somit jederzeit als root arbeiten kann.
Ein Installer kann nur dann dort etwas installieren, wenn der User Admin ist und sein Password eingibt, oder wenn er Normaluser ist und sowohl das Login als auch das Password eines Admins kennt oder wenn man als root unterwegs ist.
Ein Normaluser kann dort folglich nichts installieren, solange die anderen (Admin-)User ihre Passwords geheim halten.

Jedes andere Unix erlaubt auch seinen Sudoers (gewöhnlich sind das die Admins) als root zu agieren. Dafür gibt es die Liste mit den Sudo-Berechtigten "Sudoers" ja.

Ein Admin kann per sudo genau das gleiche, was root kann. Lediglich der Super-Duper-User (root im Single-User-Mode) kann noch mehr.

Da jeder Admin als root Aktionen (per sudo) ausführen kann, wäre es nutzlos, der Gruppe admin Schreibrechte auf das Verzeichnis zu entziehen. Defacto würde es die Admins nämlich nicht beschränken. Deswegen sind Formulierungen wie "broken by design" bei weitem zu reißerisch, da sie den Sachverhalt nur punktuell und unvollständig beleuchten.

Durch bewußtes Weglassen von Infos, die ich hier hingegen erwähnt habe, wird ein falscher Gesamteindruck erweckt. Manche tun halt alles, um eine Schlagzeile zu bekommen.

MacMark
Es gibt einen Unterschied: Als Erstinstallierer bin ich auf meinem System admin und nicht root DAS hat Apple geschickt gemacht, damit ich als admin nicht zwangsläufig als root Schaden anrichten kann.
Und nur weil ich ein OS X installiere und als *Einzeluser* darauf unterwegs bin, bin ich weder Unix noch terminal fachmann. Und ich muss als mac user der surfen, mailen, Briefe schreiben, Videos schneiden und Bilde rbearbeiten will auch gar nichts über root und sudo wissen.

Und als genau derjenige User komme ich im Leben nicht mit dem Terminal in Berührung, Geschweige denn in die Verlegenheit dort mal irgendwas mit *sudo* auszuführen zu müssen. Klar *könnte* ich das als admin.
Aber was soll ich dort als Homeuser ?
Und hier ist genau die Lücke - der startupitems bug macht genau das, von dem ich als normaler Homeuser gar nichts weiß und nichts verstehe. Es werden Sachen mit Root rechten ausgeführt die mir Apple eigentlich (aus gutem Grund) verwehrt. ich klicke mich durch die GUI ohne auch nur einmal root zu sein - und finde das gut weil ich gar nichts darüber weiß (und wissen muß) Es ist unerheblich ob ich auch als Admin via sudo Sachen mit Root rechten ausführen *könnte*.
Wer das macht hat einen grund und vor allem weiß er warscheinlich auch was er da tut. Aber dieser Bug macht das möglich auch für Leute die aus gutem Grund eigentlich nichts mit root zu tun haben sollten. Nämlich leute die ihren mac kaufen, installieren, sich EINEN account anlegen (admin) und dann mit iTunes, GarageBand und iMovie ihre Familie erfreuen.

was haben diese user mit dem terminal und sudo und root zu tun ? Nichts. Niemals.
Doch dieser Fehler umgeht das. Er führt Sachen als Root aus. auf einem system das ich nur als normaler, - und einzelplatz user benutze.
Und genau das ist das problem. Denn genau solche User soll es geben. Was sie theoretisch alles können steht auf einem anderen Blatt ...

Gegenbeispiele:

Wenn man den "Broadbandoptimizer" oder "Anacron" (siehe meine Seite) oder "LittleSnitch" installiert, dann landen von ihnen Dateien in /Library/StartupItems/, weil sie dort hingehören.

Die genannten drei Tools sind für Normaluser nützlich und per GUI installierbar.

Wenn man nun der Gruppe admin das Schreibrecht auf dieses Verzeichnis entzöge, dann könnte der normale Homeuser mit seinem Standardadmin-Account ohne Terminal und ohne sudo nichts von diesen drei Tools installieren. Für solche Sachen ist die von Apple gewählte Rechtevergabe schon sinnvoll. Deine Vorstellung wäre hingegen hier viel zu rigide.

Noch ein anderer Aspekt:
Deine Vorstellung von der Rechtevergabe ist auch für GUI-Installer umgehbar. Kein Adminuser muß Terminal oder sudo bemühen, denn der Installer bekommt sein Adminpassword und führt damit selbständig sudo durch. Folglich könntest Du mit "nur root darf schreiben auf diesem Vereichnis" wieder nichts erreichen. Jeder DAU-Admin kann per Installer, der dann sudo intern einsetzt, wie root installieren.

Na, was nun?

MacMarkUnd wenn man das beschränken würde? Ist es wirklich notwendig, einen Installer sudo durchführen zu lassen (echte Frage, weil ich´s nicht beurteilen kann) bzw. der Gruppe Admin diese Rechte einzuräumen?

Jeder User kann doch root einrichten, sich einloggen, ein tool installieren (alles bewusste Vorgänge), sich wieder ausloggen und als Admin oder Normal-User diese tools ganz normal benutzen. Ich hielte das (so es sich auf wenige tools beschränkt) für klüger, auch wenn sich dann mehr Leute root einrichten müssten, die das bis jetzt noch nicht getan haben.

Ties-Malte
Mit "sudo" kann ein User der Gruppe "admin" für den damit gekennzeichneten Befehl root sein. Direkt davor und danach ist er es nicht mehr. Beim ersten sudo muß der Admin sein Password eingeben. Alle weiteren sudo-Befehle der nächsten fünf Minuten verlangen kein Password mehr.

Dauerhaft root zu sein, ist zu gefährlich, weil man zu viel damit kaputt machen kann. Mit sudo für Admins ist gewährleistet, daß sie nur bei Bedarf und dann aber bei vollem Bewußtsein die heiklen Aufgaben durchführen, da den entsprechenden Befehlen sudo vorangestellt werden muß.

Wenn man root ist, dann wird ohne daß man auf gefährliche Aktionen hingewiesen wird, alles durchgeführt. Sudo für Admins ist ein Warnschild, das besagt "Du tust nun etwas außergewöhnliches".

Deine Vorstellung entspricht der Situation unter Windows. Dort wird nicht zwischen Admins und root unterschieden. Dort ist jeder Admin root. Den User root gibt es jedoch unter Windows nicht. Ein Windows-Admin entspricht dem OSX-root. Unter Windows arbeiten praktisch alle Leute als "root", also als Windows-Admin.

Wenn man für jede Installation root sein müßte, dann würde jeder dauerhaft als root arbeiten wollen, weil es einfacher ist. Admin mit sudo-Möglichkeit ist daher eine sehr gute praktische Lösung, die für Sicherheit sorgt.

Also ist es nötig, Admins sudo machen lassen zu können. Ob jeder Installer intern sudo nutzt, kann ich nicht sagen. Da der OS X Installer jedoch unter einem beliebigen Admin-Account nur läuft und auch dessen Password möchte, kann bei der Installer sudo nutzen. Er wird es jedoch nicht immer nötig haben.
Und ja, der Installer soll nach dem Admin-Password fragen. Damit ist sichergestellt, daß ein Admin genau diese Aktion durchführen möchte und nicht irgendwer den Admin "vertritt", weil der Admin gerade Kaffee holt und sich nicht ausgeloggt hat.
Der Installer nutzt sudo also bei Bedarf und er kann das, weil er die nötigen Infos dazu hat, und diese Infos muß er sowieso haben, weil sonst jemand am leeren Adminplatz rumspielen könnte.