Keine Admin-Rechte = sicherere PCs


Was schwer nach Binsenweisheit klingt, wurde nun durch eine Analyse belegt: Arbeiten Anwender unter Windows 7 ohne administrative Rechte, bleiben 90 Prozent aller Angriffe auf Windows-Sicherheitslücken wirkungslos. Im Fall von Microsoft Office sind es sogar 100 Prozent.


Laut einem Bericht des IT-Sicherheitsproduktherstellers Beyond Trust kann ein Großteil aller Sicherheitsprobleme in Microsoft-Produkten durch die Wegnahme von Admin-Rechten eingeschränkt werden. Beyond Trust untersuchte alle im Jahr 2009 von Microsoft veröffentlichten Security Bulletins für Windows, Office und dem Internet Explorer. Das Ergebnis fiel deutlich aus: 64 Prozent aller Sicherheitslücken könnten nicht missbraucht werden, wenn der gerade angemeldete Nutzer keine Admin-Befugnisse hat.


Unter Windows 7 werden so 90 Prozent aller als kritisch eingestuften Sicherheitslücken ausgekontert, im Fall von Office und dem Internet Explorer 8 sind es sogar 100 Prozent. Dass Windows 7 insgesamt besser abgesichert ist als beispielsweise Windows XP, geht ebenfalls aus dem Report hervor: Unter Windows XP lassen sich durch den Entzug der Administrator-Privilegien nur 62 Prozent der Angriffe auf Sicherheitslücken verhindern.


Interessant ist auch der hohe Wert von 87 Prozent in Bezug auf Remote Code Execution. Denn diese Königsklasse unter den Attacken – der Angreifer kann hierdurch beliebigen, eigenen Code auf dem PC des Opfers abarbeiten lassen – hätte nur in 13 Prozent aller Fälle Erfolg, würden die Admin-Rechte entzogen. Insgesamt bleiben mehr als vier von fünf (81 Prozent) aller in 2009 als kritisch eingestuften Schwachstellen ohne Wirkung, wenn der Anwender nur mit normalen Nutzerrechten arbeitet.


Auch wenn es nicht um Zero-Day-Exploits geht, gegen die ohnehin kaum ein Kraut gewachsen ist: Diese Zahlen machen deutlich, wie wichtig die korrekte Vergabe von Nutzerrechten ist. Denn in kaum einem Unternehmen werden die am Patch-Tag bereitgestellten Sicherheitsupdates sofort auf den Arbeitsstationen installiert. Nachdem Angreifer aber manchmal binnen Stunden nach Veröffentlichen der Updates durch Reverse-Engineering herausgefunden haben, wie die geschlossene Sicherheitslücke genau beschaffen und somit zu missbrauchen ist, kann nur durch umfassenden Schutz der PCs in der Zwischenzeit Schlimmeres verhindert werden. Andernfalls steigt das Risiko einer Infektion in der Zeit zwischen Veröffentlichung und Installation der Updates erheblich an. Zu den möglichen Schutzmaßnahmen gehört auch die Vergabe passender Rechte für die Anwender.


Quelle: Microsoft Sicherheits-Newsletter

Comments (37)

  1. Anonymous says:

    @Stefan: Es geht nicht ganz klar aus dem Bericht hervor. Aber da von Unternehmensnetzwerken die Rede ist, gehe ich davon aus, dass ein Standardbenutzer-Konto gemeint ist. Wobei das von Dir zititierte "Problem" in meinen Augen differenziert betrachtet werden muss. Deine Schlußfolgerung,  dass man nur wirklich sicher und gleichzeitig komfortabel arbeitet, wenn man den UAC-Level auf den höchsten (wie bei Vista üblich) Wert einstellt, ist so nicht richtig. Der von Dir bezeichnete Angriff läuft dann zwar exakt so nicht mehr, er könnte aber modifiziert werden und andere Wege ausnutzen, um sich mehr Rechte zu verschaffen. Du interpretierst in UAC etwas hinein, was UAC nicht leisten kann.

    Den zweiten Teil mit der Empfehlung für surun kann man auch kritisch betrachten. Wenn schon Malware im Userkontext auf der Box läuft (wo sie eh problemlos jede Menge Schaden anrichten kann), kann diese dann nicht bei SuRun sich mehr Rechte durch eine Race Condition verschaffen? Immerhin bekommt der Account für eine gewisse Zeit administrative Rechte.

    @xyz: Stefan meint vermutlich ein Standardbenutzer vs. Administrator mit Split Token.

  2. Anonymous says:

    Es gibt einen Unterschied zwischen Security Feature und Security Boundary. Du scheinst die beiden in Bezug auf UAC zu verwechseln. Die Lösung, die Ubuntu und MacOS implementiert, ist meiner Meinung nach nicht besser. Ist bei beiden der Standardaccount nicht auch in der Root-Gruppe enthalten? Ich habe gerade keine aktuellen Installationen, um das zu verifizieren aber nach meinem Kenntnisstand sind das nicht einfache Benutzer. Die Nutzung von sudo dazu stellt eine eigene Gruppe von Sicherheitsproblemen dar, die wir bewußt bei Windows nicht implementiert haben.

    Dem Link auf die Seite macmark.de bin ich mal gefolgt. Der Artikel ist tendenziös und enthält fehlerhafte Informationen und Interpretationen. Die Sicherheitsarchitektur von Windows Vista und Windows 7 ist meines Erachtens der von Apple MacOS weit überlegen. Muss sie ja auch, weil Windows wesentlich häufiger angegriffen wird.

    Dazu ein Zitat von Dai Zovi: "Exploit writing on the Mac is fun.  Exploit writing on Windows Vista is hard work."

  3. Anonymous says:

    Es hat ein wenig gedauert. Der Blogumzug (Danke noch mal an die amerikanischen Kollegen, das auf einen deutschen Feiertag zu legen 😉 und ein Urlaub haben mich ein wenig davon abgehalten, die Kommentare aufzunehmen. Ich habe ja auch noch ein reales Leben
    und hänge nicht nur ständig vor der Kiste.

    @Stefan Kraft: Du beschwerst Dich, dass der Standardlevel in Windows 7 noch "lascher" (?) ist als unter Vista. Die ganze Diskussion ist nicht einfach, vor allem wenn Sicherheit wie ein Lichtschalter betrachtet wird. Sicherheit ist kein schwarz/weiß oder
    gut/schlecht – manche (auch hier im Thread) sehen es aber so.

    Ich stell mal die Gegefrage: Was hilft die höchste Sicherheitsstufe, wenn Anwender es als zu störend empfinden? Viele sogenannte Experten empfahlen bei der Installation von Windows Vista UAC auszuschalten, weil es nervig sei. Damit hast Du Vista sicherheitstechnisch
    fast auf ähnlichem Niveau wie Windows XP. Obwohl unsere Telemetriedaten zeigen, das durchschnitlich die meisten Nutzer sehr wenige UAC-Dialoge bei der Benutzung ihres Systems zu sehen bekommen.

    Viele Anwender stiegen gar nicht von XP um. Anwendungshersteller fixten nicht ihre Anwendungen, die zum Betrieb weiterhin administrative Rechte erforderten. Für Windows 7 haben wir einen besseren Kompromiss zwischen Security, Benutzbarkeit und Anwendungskompatibilität
    gesucht und meiner Meinung nach auch gefunden.

    Eine ultimative Empfehlung der einzig richtigen Einstellung kann man aber nicht ("klipp und klar") geben. Glaub mir, wir hätten sie sonst voreingestellt 😉 Es kommt immer auf die Umstände an. Was für ein Sicherheitsbedürfnis hast Du? Welche Komforteinbußen
    bist Du gewillt zu tragen? Du brauchst eine Risikobetrachtung für Dein Szenario.

    Schau Dir mal zum Beispiel die
    Allgemeine Empfehlungen des BSI zum sicheren Einsatz von Aktiven Inhalten in vertrauenswürdigen Web-Anwendungen
    und

    Remote-Controlled Browsers System (ReCoBS) Grundlagen und Anforderungen
    an. Wäre das eine sinnvolle Lösung für Max Mustermanns private PC-Nutzung? Ich glaube nicht. Es kommt wie schon gesagt immer darauf an.

    UAC ist ein Schritt auf einem langen Weg hin zu Umgebungen, in denen Anwender mit weniger Rechten als gestern arbeiten. Wir bleiben heute auch nicht stehen. Wir sind darauf angewiesen, dass das gesamte Ökosystem sich in die richtige Richtung mit bewegt.
    Wenn wir zu schnell und zu weit voraus fahren, kommt der Rest vielleicht nicht mit. Ich habe da mal einen schönen Satz gelesen, der das treffend zusammenfaßt: Security is not a destination, it’s a journey!

    @MacMark: Ich hatte schon geschrieben, dass ich an einem Flamewar Apple vs. PC nicht interessiert bin. Wenn ich mich an einer Stelle auf die Dokumentation des Herstellers verlassen habe und diese falsch ist, dann tut es mir leid. Das ändert aber nichts an
    meiner Einschätzung, dass Dein Artikel tendenziös ist und Fehler enthält. Ich habe auch genügend Gegenbeispiele genannt. Du hast es jedoch vermieden, auf die meisten wirklich näher einzugehen. Daher noch einmal von mir eine letzte Antwort auf Deine Kommentare.

    NT 4 wurde erst nachträglich 1998 mehrbenutzerfähig? Ein Mehrbenutzersystem oder Multiuser-System ist ein Betriebssystem, das die Fähigkeit hat, Arbeitsumgebungen für verschiedene Benutzer bereitstellen und voneinander abgrenzen zu können. Sagt jedenfalls

    Wikipedia
    . Windows NT wurde von Anfang an als mehrbenutzerfähig entwickelt. Du meinst vermutlich Multisession und nicht Multiuser. Die Terminalservices kamen in der Tat erst später.

    Deine generelle Kritik an ACL-basierenden Systemen kann ich nicht nachvollziehen. Windows ist schlechter, weil es etwas flexibleres als nur die traditionellen Unix-Berechtigungsstrukturen anbietet? Das Review von Mac OS X 10.4 Tiger auf

    arstechnica.com
    zeigte sehr anschaulich, warum ACLs von Vorteil sind und in Mac OS X sind sie ja auch eingebaut worden:

    "Traditional Unix file permissions are flexible, but it’s still not hard to construct scenarios in which they do not offer enough control. For example, imagine trying allow a single user, Bob, to read one of your files. With
    traditional Unix file permissions, the only way to do it is to make a new group (say, "friends") with just two people in it, you and Bob. Then you’d change the file’s group to be your new two-member group, and enable the group read permission.
    That was awkward, but now imagine that you want to let a third user, Ray, write to the file, but not read it. Now you’re stuck. If you put Ray into the "friends" group, he’ll be able to read the file. And if you grant write access to the "friends"
    group, then Bob can write to the file. Since a file can only have one owner and one group, there’s nothing you can do. The Unix permission system is not flexible enough to accommodate these needs.
    Worse, imagine that you want to grant the ability to delete a particular file to a group of users. In traditional Unix permissions, there is no "delete" permission for a single file. The ability to delete a file is controlled by the "write" permission
    of the parent directory. But you want to allow just this particular file to be deleted, not all files in the same directory. The Unix permission system is not fine-grained enough to accommodate these needs."

    Die Aktivierung des 64-Bit-Kernels war ein Beispiel von mir um zu zeigen, dass man auch bei Mac OS X manchmal für einfachste Konfigurationsaufgaben tief in das System von der Kommandozeile eingreifen muss. Ich kann auch andere nennen, die zeigen, dass Dein
    Argument nicht stichhaltig ist. So bin ich bei der Nutzung von Mac OS X darüber gestolpert, den Standard-Zoom-Level von Safari zu verändern. Das beste, was ich als Lösung gefunden habe, ist zum Beispiel auf

    macosxhints.com
    beschrieben. Wenn Du weißt, wo ein einfacherer Schalter in der UI dafür ist, bin ich froh über einen Tipp von Dir.

    Dann behauptest Du, NTFS wurde vor Vista wenig in der Praxis eingesetzt. "NTFS (New Technology File System) is the standard file system of Windows NT, including its later versions Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, Windows
    Vista, and Windows 7."
    Sagt zumindestens
    Wikipedia
    . Willst Du wirklich weiterhin Windows über FAT diskreditieren? Seit wann hat denn Mac OS ein modernes Dateisystem, dass zumindestens mit NTFS vergleichbar oder besser wäre?

    Auch Dein Herumreiten auf "keine durch ungeeignete System-Architektur bedingten Schwachstellen" kann ich nicht verstehen. Du hast hier Gegenbeispiele genannt bekommen. Jetzt tust Du sie als banale Buffer Overflows ab, die aber durch den Einsatz
    von z.B. DEP und ASLR wesentlich erschwert werden würde. Damit widersprichst Du Dir nur selbst. Und ich will gar nicht erst von Dingen wie z.B. die Verschlüselung beim iPhone OS anfangen.

    Auf den Rest Deiner Kommentare brauche ich nicht wirklich eingehen. Es gibt keinen Grund, persönlich zu werden, wenn man auf Fehler hingewiesen wird oder was willst Du mit Deiner Spekulation über mich erreichen? Ich sehe jedenfalls keinen Sinn darin, Vorteile
    eines Systems durch das Schlechtmachen der Konkurrenz zu begründen. Ich zeige lieber, wie Windows sich weiterentwickelt und welche sachlichen Hintergründe bestimmte Entscheidungen haben.

    Wir können gern die Diskussion an anderer Stelle weiterführen. Ich glaube aber nicht, dass Kommentare auf diesem Blog die richtige Kommunikationsplattform sind. Vielleicht trifft man sich ja mal bei einer Gelegenheit persönlich und wir führen das Gespräch
    dort fort.

    Viele Grüße,
    Daniel

  4. Anonymous says:

    @Qwertz: Noch einmal: "Es gibt einen Unterschied zwischen Security Feature und
    Security Boundary"
    . Wenn mir der Unterschied nicht klar wäre, würde ich keine Diskusionb um UAC anfangen. Du sagst selbst von Dir, dass Du Dich
    "nicht so gut mit dem ganzen Sicherheits-Dingens aus"kennst. Dementsprechend würde ich an Deiner Stelle erst die Unterschiede nachschlagen, bevor ich mir ein Urteil wie
    "dann ist es irgendwie in meinen Augen sinnlos" erlaube.

    Just my 0.02 €.

    Zum zweiten Punkt: Der Artikel, den Du zitiert hast, ist fehlerhaft. Du verlangst jetzt von mir, dass ich das mit Quellen belege. Darf ich Dich vorher etwas fragen: Mit welchem Recht wirfst Du mir einfach einen Artikel über den Zaun, den irgendjemand geschrieben
    hat und verlangst von mir, dass ich die Arbeit leiste, ihn Stück für Stück zu widerlegen? Warum beweist Du nicht erst einmal die Aussagen des Artikels? Es wird soviel Unsinn im Netz geschrieben, dass ich mich 24h am Tag damit beschäftigen könnte, sowas auseinanderzunehmen.
    Nur ist mir meine Zeit zu schade dafür.

    Aber da Du so nett gefragt hast und ich eh noch nicht schlafen wollte, schauen wir uns ein paar Sachen daraus an. Ich fang mal ganz oben an:
    http://macmark.de/osx_security.php

    6.0 Einleitung

    "Ich werde darlegen, warum das UNIX-Betriebssystem Mac OS X keine durch ungeeignete System-Architektur bedingten Schwachstellen bietet, die ein Angreifer wirkungsvoll ausnutzen könnte."

    Schau mal bei Secunia vorbei. Ich sehe da 137 Advisories für Mac OS X von 2003-2007 (wobei nicht eins pro Sicherheitslücke veröffentlicht wird, sondern manchmal viele Lücken mit einem Advisory gepatched werden).

    "Eine wirkungsvolle Schwachstelle ist eine, mit deren Hilfe ein Fremder ohne Zutun der Benutzer den Rechner in Standardkonfiguration per Netzwerk übernehmen könnte."

    72% der Advisories betreffen remote ausnutzbare Schwachstellen, 19% sofortigen Systemzugriff, 13% Rechteerhöhung, 13% Security bypass, etc. Schon hier könnte man aufhören zu argumentieren, weil die Grundannahme des Autors falsch und widerlegt ist.

    6.0.1.1 Scheinargument Marktanteil widerlegt

    "Wenn der Verbreitungsgrad eine Rolle spielen würde, dann müßte der Apache Webserver deutlich mehr Sicherheitsprobleme haben als der Microsoft Internet Information Server, denn während zwei von drei Internet-Seiten auf dem Apache Webserver liefen und
    nur jede fünfte Internetseite auf dem Microsoft Internet Information Server, hatte der Apache Webserver deutlich weniger unter Sicherheitsproblemen aller Art zu leiden als der Microsoft Internet Information Server. Damit ist das Scheinargument ‘Marktanteil’
    widerlegt."

    Schau Dir dazu mal
    Apache vs IIS Myths
    an. Der IIS6 ist ab Version 6 deutlich weniger anfällig als der Apache. Vergleiche einmal

    IIS6
    mit
    Apache 2.0.x
    und
    IIS7
    mit
    Apache 2.2.x
    . Auch diese Aussage ist also falsch.

    6.0.2.2 Geboren für Mehrbenutzer-Betrieb und Netzwerk

    "Andere Betriebssysteme, zu denen das marktbeherrschende gehört, wurden ursprünglich für Einzelplatznutzung ohne Netzwerk ausgelegt. Dort fehlte daher im Grundkonzept alles, was mit Sicherheit in Bezug auf Netzwerkbetrieb und mehrere gleichzeitige Benutzer
    zu tun hat."

    Diese Aussage kann man nur auf die Windows 9x-Schiene beziehen und nicht auf Windows ab NT aufwärts. Man sollte schon Mac OS X auch mit Windows ab NT vergleichen und nicht mit Windows 9x. Mit der Argumentation könnte man sonst auch sagen: Apples Betriebssystem
    wurde ursprünglich für die Nutzung durch nur ein einziges Programm ohne Netzwerk ausgelegt. So war das mit Mac OS am Anfang.

    6.0.2.3 Datei-Trennung

    "Generell sind UNIX-Betriebssysteme aufgrund ihrer typischen Beschränkung der Benutzerberechtigungen nicht so leicht von Viren zu befallen. Hier sind sowohl Prozesse als auch Dateien unterschiedlicher Nutzer sauber und sicher voneinander getrennt. So
    kann ein Virus, der unter einem normalen Benutzer oder Administrator läuft, nicht in andere Benutzer- oder System-Verzeichnisse schreiben."

    Das gilt bei Viren im Benutzerkontext nicht nur für Mac OS X, sondern auch für Windows. Wobei Rechteerhöhung, wie oben gesehen, ja bei Mac OS X auch recht einfach zu bewerkstelligen ist. Damit stimmt die Aussage dann nicht mehr. Und der letzte Halbsatz ist
    nicht wirklich ernst gemeint, oder? Was mit administrativen Rechten läuft, kann sehr wohl auf Benutzer- und Systemverzeichnisse schreiben. Es kann sich nämlich die Rechte nehmen. Mal ehrlich: Wie soll man jemanden ernst nehmen, der so einen "Unsinn" schreibt?

    "Dateisysteme von UNIX-Betriebssystemen verwenden schon seit ewigen Zeiten mindestens Zugriffsrechte auf Dateiebene."

    Das gilt nicht nur für Mac OS X, sondern auch für Windows. Falls hier wieder Windows 9x gemeint ist – Mac OS kannte auch keine Zugriffsrechte früher.

    "Unter Mac OS X ist ein Administrator nicht gleichmächtig mit dem System. Auf Systemverzeichnisse beispielsweise hat nur das System (root) Schreibrechte."

    Das gilt nicht nur für Mac OS X, sondern auch für Windows ("Trusted Installer", "System", etc. sind bekannt?)

    "Administratoren sind in der Gruppe admin und nicht in der System-Gruppe wheel, in der nur root Mitglied ist."

    Apples eigene
    Dokumentation
    sagt: "Administratoren in Mac OS X sind Mitglieder der Gruppen "admin" und "wheel", während der Superuser mit der Bezeichnung "root" ein Mitglied der Gruppen "admin" und "staff" ist."
    Also ist die Aussage falsch (oder Apples Dokumentation – ich habe gerade keinen Mac hier, um nachzusehen – "wheel" gab es wohl nur vor Mac OS X 10.2).  

    BTW: Die dort folgende Anleitung ist nett:

    Gehen Sie wie folgt vor, um den Papierkorb für den angemeldeten Benutzer zu löschen: 1. Öffnen Sie das Programm "Terminal". 2. Geben Sie "sudo rm -rf" ein.

    Wieviele Nutzer drücken jetzt Enter, bevor sie weiterlesen und laufen in ein Desaster?

    "Dafür muß man unter OS X so gut wie nie als root arbeiten und sich vor allem nie als root anmelden, wozu man jedoch auf anderen Unices und Windows (da heißt es anders) dann doch (gelegentlich) gezwungen ist."

    Lies mal
    Mac OS X : Password Does Not Work As Expected After a Change
    . Dort findest Du eine Tabelle, warum in Mac OS X ein Root-Account erzeugt wird und für welche Fälle man ihn braucht, weil diese *nicht* mit dem normalen Admin-Account gehen. Das "nie als root
    anmelden" ist damit auch widerlegt.

    Weiterhin muss man für einfachste Konfigurationsaufgaben manchmal auch tief in das System von der Kommandozeile eingreifen. Hast Du mal versucht, festzulegen, dass immer der 64-bit Kernel in Mac OS X geladen werden soll?

    Das geht
    so
    :

    "It’s ridiculous that Apple did not provide a system preference panel for this… Edit the file /Library/Preferences/SystemConfiguration/com.apple.Boot.plist (and) Insert arch=x86_64 into the Kernel Flags field." Oder: "Open a Terminal window and enter
    this command: sudo nvram boot-args=’arch=x86_64’"

    Und nur mal am Rand: Der Administrator-Account (gleichbedeutend mit Root) ist ab Windows Vista deaktiviert. Mit dem soll man sich nicht nur nicht, sondern kann sich standardmäßig auch nicht anmelden.

    "Kein normaler Benutzer und kein Administrator hat Zugriff auf die privaten Verzeichnisse der anderen Benutzer. So etwas ist unter Mac OS X und jedem anderem UNIX nur dem System (root) möglich."

    Unter Windows sind die privaten Verzeichnisse auch geschützt. Die Besitzübernahme ist bei Mac OS X aber nicht nur dem Root-User möglich, sondern allen Admin-Accounts:

    Mac OS X 10.2: How to Change Ownership & Permissions Using the Finder
    .

    "Eine Datei-Trennung unter Windows gab es anfangs überhaupt nicht und mit Vista immer noch nicht sauber, wodurch es Schadprogrammen erleichtet wird, sich zu verbreiten und Schaden zu verursachen."

    Hmm. Bei Mac OS gab es keine Datei-Trennung. Das kam meines Wissens erst mit HFS Plus. Das ist also eine Behauptung, die schlichtweg falsch ist.

    "Bei den Betriebssystemen von Microsoft war FAT seit 1976/77 über 20 Jahre (und wohl auch heute noch) das am meisten eingesetzte Dateisystem."

    NTFS gibt es jetzt wie lange schon? Und kann man Vista oder Windows 7 auf FAT installieren? (Die Antwort ist natürlich nein).

    "Ein Sicherheitsmodell, wie es von UNIX-Dateisystemen bekannt ist, bieten die Dateisysteme unter Windows nicht."

    Wie bitte? Das ist doch wohl ein Scherz.

    "Beim NTFS gibt es allerdings ebenfalls keine dem UNIX-Modell entsprechenden Datei-Besitzer oder Zugriffssteuerung"

    Falsch. Natürlich gibt es Besitzer und Berechtigungen.

    "aber mit Hilfe von ACLs konnte das trotzdem umgesetzt werden."

    Ach ja. Windows kennt ACLs. Und das schon ganz lange. Mac OS X erst seit seit Tiger (10.4), wobei das Apple Mac OS X Server version 10.4+ File Services Administration Manual
    "traditional Unix permissions if possible" empfiehlt.

    Das simple rwx-Modell gilt übrigens einem modernen ACL-System als unterlegen! Beispiel gefällig? Lies mal

    A deeper look at drop box permissions issues
    .

    "Die ACL-Umsetzung, die mit Windows NT eingeführt wurde, war allerdings unsicher: Um abwärtskompatibel zu bleiben, erlaubt das Betriebssystem, diese zu ignorieren."

    Was bitte schön wird damit gemeint?

    "In einigen Fällen jedoch hat der ‘TrustedInstaller’ mehr Rechte. Das kann aber ein Administrator ohne Probleme ändern, indem er den Besitz der Datei übernimmt und die Zugriffsrechte anpaßt und falls nötig auf ‘ok’ und ‘fortfahren’ klickt."

    Wie die Besitzübernahme unter Mac OS X geht, habe ich oben schon zitiert. Was daran unter Vista nun schlecht sein soll, ist mir ein Rätsel.

    "Wenn man unter Vista einen Benutzer anlegt, dann gibt es kein Eingabefeld für die Festlegung eines Paßwortes. Jeder Benutzer, auch die allmächtigen Vista-Administratoren, sind erst einmal ohne Paßwort."

    Hier hat jemand nicht verstanden, dass Konten ohne Kennwort sich nur lokal anmelden können. Dadurch sind sie sicherer als Konten mit einem schwachen Kennwort, die nämlich über das Netzwerk angreifbar sind. Natürlich kann man beim Anlegen von Benutzern ein
    Passwort angeben.

    6.0.2.4 Prozeß-Trennung

    "Beim zur Zeit marktbeherrschenden Betriebssystem ist das genau andersherum: Dort läuft jeder Prozess mit maximalen Berechtigungen (ein Windows-Administrator ist gleichmächtig wie System) und geringere Rechte sind die Ausnahme (und nicht die Regel)."

    Das ist schlicht falsch. Schau einfach mal selbst z.B. mit dem Process Explorer nach.

    "Und man macht sich nicht die Mühe, ein Programm in mehrere kleine Programme aufzuteilen, um sicherheitsrelevante Aktionen nur in einem kleinen Spezialprogramm zu verwenden. Daher läuft das gesamte Programm und, was es nochmals verschlimmert, alle von
    ihm verwendeten Programmbibliotheken, als hochprivilegierte Prozesse, wenn auch nur ein kleiner Anteil hohe Rechte benötigt."

    Das ist auch falsch. Einfaches Gegenbeispiel ist der Taskmanager, der sowohl im Benutzer-, als auch im administrativen Kontext laufen kann.

    "Was bei UNIX undenkbar ist, ist bei Windows Normalität: Alles arbeitet als Windows-Administrator, der einem UNIX-Root entspricht."

    Das ist ebenso falsch. Schau Dir einfach mal den Protected Mode im IE an. Oder die Berechtigungen der einzelnen Systemdienste, die unterschiedlichste Berechtigungsstufen haben können.

    "Ein Administrator von Mac OS X hingegen ist nicht Root. Und ein Administrator muß, wenn er systemrelevante Dinge tun will, sich nochmals authentifizieren mit Paßwort."

    Tja, diese Methode ist anfällig gegen Passwortsniffing. Eine Malware muss im Userkontext nur den Dialog grafisch nachmachen und einblenden. Gibt der Anwender dann das Passwort ein, hat sie das Kennwort und der Malware gehört das System.

    "Unter dem bei den Autoren von Schadprogrammen als Ziel sehr beliebtem anderen Betriebssystem hingegen hat solch ein Programm unter einem Benutzer alle nur denkbaren Möglichkeiten; es ist ein Paradies für Schadprogramme."

    Das ist schlicht falsch. Ein Malware-Programm, das im Benutzerkontext gestartet wird, hat keine administrativen Rechte.

    Und so weiter und so fort. Kannst Du jetzt verstehen, warum es müßig ist, dieses Dokument zu widerlegen? Es wäre vermutlich effektiver, wenn ich beschreibe, was an den Aussagen stimmt 😉

    @Stefan:

    "Der Standard-Level von Windows 7 allerdings erlaubt es ohne weiteres auch bösartigen Programmen, Admin-Aktionen auszuführen, ohne dass eine UAC-Abfrage erscheint. Theoretisch ist das auch im höchsten UAC-Level möglich, aber das scheint derartig schwierig
    zu sein, dass es bis jetzt in der Praxis nicht oder kaum aufgetaucht ist – und zeigt, dass MS in dieser Hinsicht durchaus gute Arbeit geleistet hat."

    Deine Schlußfolgerung ist falsch. Das geht nicht nur theoretisch und ist gar nicht so schwer. Malware hat sich bisher nur nicht die Mühe gemacht, als Non-Admin zu laufen, weil es bisher nicht notwendig war. Es gibt genug Boxen, wo der Benutzer Gott sein
    will, weil er sich sonst bevormundet fühlt 😉 Nicht weil es zu schwer wäre. Malware entwickelt sich aber weiter. So könnte Malware z.B. über eine Shell Extension sich im Userkontext einnisten und wird dann ausgeführt, wenn ein anderes Programm höhere Rechte
    per Elevation bekommt. Das würde z.B. auch SuRun aushebeln. Schau Dir dazu mal den Vortrag

    Windows Security Boundaries
     von Mark an. Er ist sehr lehrreich. Mark ist ein fantastischer Redner und erklärt die Thematik sehr genau.

    Damit wünsche ich allen Lesern eine Gute Nacht!
    Daniel

  5. Anonymous says:

    @Quertz:

    "Wurde nicht schon oft die Abschaffung der Registry gefordert? Ist die Registry nicht ein veralltetes Ding, welches oft auch öffentlich Kritisert wurde (beispielweise als Apple Snow Leoaprd veröffenltichte und gegen Windows
    7 geflamt hat)."

    Nicht jede Kritik ist auch berechtigte Kritik. Diejenigen, die die Abschaffung der Registry fordern, haben in der Regel nicht verstanden, wofür sie da ist.

    "Ich habe es noch nie getestet, aber stell dir vor, jemand will 26 Festplatten bzw. 26 Systempartitionen errichten. Was passiert dann? Oder ist Windows beschränkt auf 26 Festplatten/Systempartitionen?"

    Du kannst problemlos 26 Festplatten/Partitionen in Windows betreiben (oder meinetwegen auch 50) und nur einen einzigen Laufwerksbuchstaben benutzen. NTFS unterstützt das Einhängen von Partitionen direkt in die Ordnerstruktur. Die Vergabe von Laufwerksbuchstaben
    ist (bis auf die Startpartition) optional.

    "Das Verschlüsselte Dateisystem von Windows  (EFS) gibt es ausschliesslich in der Ultimate-Version. Ich rede lieber für die Allgemeinheit."

    EFS kann unter Windows 7 auch schon in der Professional-Version genutzt werden. Du verwechselst das sicher mit Bitlocker, welches ein Ultimate-/Enterprise-Feature ist. Das ändert aber nichts an der Tatsache, dass NTFS derartige Technologie unterstützt.

    @MacMark: Da Du ja nun Deinen Artikel über UAC fertiggestellt hast, könntest Du doch auch mal was über

    com.apple.systemloginitems.plist
    schreiben. Ist das eine durch ungeeignete System-Architektur bedingte Schwachstelle oder handelt es sich eher um ein Feature?

  6. Anonymous says:

    Da nach 60 Tagen die Kommentarfunktion eines Postings geschlossen wird und MacMark der Diskussion gern noch etwas anfügen möchte, bot ich ihm an, einen Link auf seine Seite einzubinden, wo die Diskussion dann fortgesetzt werden kann.

    Er merkte jedoch an, dass seine Seite komplett handgeschrieben ist und überhaupt keine Kommentarfunktion hat. Jede Form von Kommentar-Möglichkeit würde für ihn im Moment mehr Administration bedeuten, als er aufwenden kann.

    Alternative kann aber dieser Thread hier für die weitere Diskussion verwendet werden: http://www.macuser.de/…/systemloginitems-ungleich-startupitems-538544

    Have fun!
    Daniel

  7. Anonymous says:

    @Stefan: Meine zeit ist grad etwas knapp, daher antworte ich Dir Ende der Woche.

    @MacMark: Ich mißinterpretiere Dich nicht. Ich will mit Dir auch gar nicht groß diskutieren, denn Du bist an einer sachlichen Diskussion meines Erachtens eh nicht interressiert. Für einen Apple vs. Windows Flameware ist mir meine Zeit zu schade. Ich bin nur darauf eingegangen, weil hier jemand danach gefragt hat. Aussagenlogik hilft Dir übrigens auch nicht weiter, weil Dein Beispiel ja falsch ist: Der IIS ist seit Jahren nicht unsicherer als Apache.

    VG, Daniel

  8. Anonymous says:

    Hallo Qwertz,

    das ist schon seit Windows Vista anders geworden. Durch die Benutzerkontensteuerung arbeitet der Anwender standardmäßig nicht mit administrativen Rechten, sondern als Standardanwender, auch wenn er ein administratives Konto einsetzt.

    In der 7. Ausgabe der
    Microsoft-Analyse zur IT-Sicherheit
    (SIR) kann man die Auswirkungen dieser Änderung auch sehen: So liegt beim Vergleicht der RTM-Versionen die Infektionsrate von Windows Vista um
    85,3 Prozent niedriger als die von Windows XP und bei Vista SP1 um
    61,9 Prozent unter der von Windows XP SP3. Je höher die genutzte Service Pack-Version, umso niedriger ist auch die Infektionsrate. Wobei Benutzer, die Service Packs installieren, ihre Computer in der Regel besser
    warten als Benutzer, die keine Service Packs installieren und zudem oft vorsichtiger sind beim Surfen im Internet, beim Öffnen von Anhängen und bei anderen Aktivitäten, die Computer für Angriffe anfällig machen können. Und beim Surfen im Internet machen browserbasierte
    Angriffe auf Windows XP-basierte Rechner 56,4 Prozent aller Microsoft-Schwachstellen aus, während es auf Windows Vista-basierten Rechnern nur noch 15,5 Prozent sind.

    Ich denke, das alles belegt sehr gut, dass wir nicht auf Windows 8 warten müsen. Microsoft nimmt Sicherheit sehr ernst und entwickelt seine Produkte konsequent auch im Hinblick auf Sicherheit weiter.

    Viele Grüße,
    Daniel

  9. Anonymous says:

    Mein Argument mit dem 64-bit Kernel bezog sich (neben anderen) auf die von Dir verlinkte (und meiner Meinung nach nicht zutreffende) Meinungsäußerung, dass "man unter OS X … sich vor allem nie als root anmelden" muss.

    Du schreibst: "Ich persönlich würde allerdings diese Möglichkeit bei Windows auch lieber vorziehen. Ich habe keinen Mac um das jetzt zu kontrollieren und so, aber ich persönlich hätte lieber eine Kommandozeile um alles im System verändern zu können statt x-Tools zu benötigen wie in Windows derzeit."

    Verstehe ich Dich richtig, dass Du damit sagen willst, dass man bei Mac OS X *alles* per Kommandozeile einstellen kann, wärend man bei Windows viele verschiedene GUI-Tools braucht und Dir ein Kommandozeilenweg bei Windows lieber wäre? Ich kann zwar nicht für Mac OS X sprechen und bestätigen, dass man dort *alle* Einstellungen auch in einer Konfigurationsdatei direkt machen kann, ohne nur ein einziges Tool benutzen zu müssen, aber in Windows werden die meisten Einstellungen in der Registry hinterlegt.

    Du führst dann das Tool WinBubble auf. Was ich von dem Tool so auf den ersten Blick sehe, ist eine GUI, die vielfältige Einstellungsmöglichkeiten, die Windows über die Registry bietet, über eine GUI erreichbar macht. Also eigentlich das Gegenteil von dem, dass Du Dir wünschst, oder? Die gute Nachricht ist: Was das Programm in der Registry manipuliert, kannst Du auch per Kommandozeile direkt erreichen. Schau Dir einfach mal das Kommando REG.EXE oder die PowerShell an.

    Die Einstellungen, die das Tool WinBubble bequem von der GUI aus erreichbar macht, haben wir übrigens nicht einfach versäumt, in die Systemsteuerung zu integrieren. Wenn alles, was in Windows konfigurierbar ist, auch eine entsprechende grafische Konfigurationsoberfläche hätte, wären Anwender überfordert, weil die schiere Auswahl an zehntausenden Konfigurationsoptionen einen dann erschlägt. Schau Dir die Menge der möglichen Einstellungen zum Beispiel mal anhand des Group Policy Search Tools an.

    Zu DEP: Wenn bei Dir ein Spiel wie GT4 bei eingeschaltetem DEP abstürzt, ist das ein Zeichen, dass das Spiel einen Fehler enthält und dieser besser im Spiel behoben werden sollte. Ich denke nicht, dass man daraus schliessen sollte, DEP sei eine schlecht Sache. Oder mißverstehe ich Dich hier? 

    Was Deine enormen Bedenken Virenscannern gegenüber angeht: Ein Virenscanner arbeitet gerade mit höchsten Rechten, damit er jederzeit in der Lage ist, z.B. jeden Dateizugriff zu scannen und möglicherweise zu verhindern. Deshalb kann er auch systemrelevante Daten verschieben, löschen, ausschneiden, whatever. Welche Aktion er dann ausführt (Säubern, Löschen, Quarantäne, Rückfragen), ist aber in der Regel konfigurierbar. Deshalb schrieb ich zum Beispiel zu dem auch von Dir angeführten McAfee-Problem, dass das Ergebnis sehr davon abhängt, welche Konfiguration der Virenscanner-Admin vorgenommen hat.

    Was hier aber zum tragen kommt, ist ein ganz anderes Problem, nämlich der Umgang mit Fehltreffern ("False Positives"). Nehmen wir Dein Beispiel mit dem McAfee Virenscanner. Stell Dir vor, Du würdest vom Virenscanner gefragt werden, dass in Svchost.exe ein W32/Wecorl.a 0-day Angriff entdeckt wurde. Was würdest Du tun? Was würde ein durchschnittlicher Privatanwender tun? Was würde ein durchschnittlicher Anwender in einem Unternehmen tun? Würde Admins diesem überhaupt die Möglichkeit eingeräumen, die Entscheidung über einen 0-Day Angriff selbst zu treffen? Was ist, wenn der Angriff kein Fehltreffer war und der Mitarbeiter einfach auf "Ignorieren" klickt? Gar nicht so einfach, oder?

    Bei diesem Beispiel kommt hinzu, dass Virenscanner eigentlich eine Whitelist über den Hash von Systemdateien haben. Warum das in diesem Fall nicht geholfen hat und welche Hintergründe genau dieser McAfee-Vorfall hat, kannst Du in meinem Artikel, den ich oben verlinkt habe, nachlesen.

    Zu NTFS: Das ist ein modernes Dateisystem, dass sich vor anderen nicht zu verstecken braucht. Fragmentierung ist zum Beispiel kein Problem mehr, da Windows sich automatisch im Hintergrund um die laufende Optimierung der Festplatte kümmert. Fragmentierung ist meiner Meinung nach auch überschätzt. Die Angst, die Anwendern davor gemacht wird, nutzen viele Drittanbietern zum Verkauf von Deframentierungstools. Das ist ein kompletter Markt, auf dem einiges an Umsatz gemacht wird. Sind diese Tools besser als das eingebaute? Wenn man den Preis, den man für derartige Tools zu bezahlen hat, mit berücksichtigt, meiner Meinung nach nein. So waren lange Zeit Defragmentierungstools von Drittanbietern Schuld daran, dass unnötig Schattenkopien auf dem System entfernt wurden, was die eingebaute automatische Fragmentierung nicht tat.

    Und zum Schluß die Laufwerksbuchstaben. Was Du daran als "Schwäche" meinst, verstehe ich jedenfalls nicht. Der verlinkte Atikel von der CHIP suggeriert, dass jedes Laufwerk unter Windows einen Laufwerksbuchstaben *braucht*. NTFS unterstützt Junctions, Reparse Points, Hard Links, etc. Du kannst zum Beispiel eine Festplatte einfach in ein Verzeichnis einer anderen Festplatte einhängen.

    Darüber hinaus bietet es zum Beispiel transparente Komprimierung und Verschlüsselung auf Dateiebene und die Möglichkeit, systemübergreifende Transaktionen auch auf dem Dateisystem abzubilden. Veränderungen am Dateisystem werden nur dann ausgeführt, wenn die komplette Transaktion erfolgreich durchgeführt werden konnte. Eine Transaktion kann dabei eine Einzeloperation oder eine Abfolge von Operationen enthalten (beispielsweise das Erzeugen, Löschen oder Umbenennen einer oder mehrerer Dateien bzw. Verzeichnisse, Veränderungen in der Registry, atomare Operationen über Rechnergrenzen hinweg, etc.).

    BTW: Die CHIP schlägt vor, dass "Speicher in einem vom System verwalteten Speicherpool organisiert sein [sollte]. Der Anwender müsste nur wissen, wie viel Speicher noch zur Verfügung steht. Und dies völlig unabhängig von der Zahl eingebauter Datenträger … Wird der Speicher knapp, erweitert der Anwender den Rechner einfach um eine Festplatte … Den Rest erledigt das System." Das geht schon heute. Genauso arbeitet der Windows Home Server.

    Die CHIP schlägt weiterhin vor, dass Windows 8 die Festplatten-Struktur besser nutzen sollte. Eine "Clevere Anordnung von Daten kann die Leistung steigern." Auch das ist schon implementiert. Stichwort Automatische Boot Optimierung (seit Windows XP) und Superfetch (seit Windows Vista). Und der Trend geht in Richtung SSD, wo sowohl die Anordnung der Daten, wie auch Fragmentierung keine Rolle mehr spielen…

    Viele Grüße,
    Daniel

  10. Qwertz says:

    Das hat man schon immer so oft gehört, dass die Admin-Rechte die Sicherheit erhöhen. Microsoft selbst sollte es ja auch wissen.

    Jedoch finde ich es echt schade, dass jedes vorinstallierte Windows Admin-Rechte hat. Viele Anwender wissen ja nicht mal, wie man es umstellt, damit man keine Admin-Rechte hat. Man könnte fast sagen, dass Micorsoft dadurch die Verbreitung von Schadsoftware fördert. Leider.

    Hoffentlich wird es in Windows 8 besser 🙂

  11. Stefan Kraft says:

    Ich denke auch, dass es mit Vista um einiges besser geworden ist. Leider gab es in der Standardeinstellung unter 7 wieder einen Rückschritt: Der standardmässig eingestellte (zweithöchste) UAC-Level erlaubt es mit ein paar zusätzlichen Handgriffen, Admin-Aktionen per Code-Injection auszuführen, ohne das ein UAC-Prompt erscheint, wie unter http://pretentiousname.com/misc/win7_uac_whitelist2.html demonstriert wird. Stellt man den UAC-Level auf den höchsten (wie bei Vista üblich), laufen diese Attacken dagegen ins Leere, und man arbeitet wirklich sicher und gleichzeitig komfortabel.

    WinXP-Usern kann ich persönlich SuRun (http://kay-bruns.de/wp/software/surun/) empfehlen, das per UAC-ähnlichen Abfragen erlaubt, einzelne Prozesse wie bei Vista und 7 mit erhöhten Rechten zu starten. Auch unter Vista und Windows 7 (da aber erst ab der Beta-Version 1.2.0.9, zu finden im Forum) kann das Programm einen Mehrwert bieten. (Beispielsweise kann man die Systemsteuerung mit Admin-Rechten starten, um mehrere Einstellungen ohne UAC-Prompts vorzunehmen; unter 7 funktioniert das allerdings noch nicht.)

  12. Stefan Kraft says:

    P.s.: Ist eigentlich im Beyond Trust-Bericht das Arbeiten als UAC-Administrator gemeint (UAC-Abfragen ohne Passwort), oder das Arbeiten als wirklich eingeschränkter Standardbenutzer (UAC-Abfragen mit Passwort, d.h. so gennante Over-the-shoulder-elevation)?

  13. xyz says:

    Wo soll da der Unterschied sein? BTW: Was Du oben zitierst, stimmt nicht: Selbst mit der höchsten Einstellung (wie in Vista) ist es keine Sicherheitsbarriere. Genauso wie es in Vista keine war…

  14. Stefan Kraft says:

    @dmelanchthon und @xyz: Stimmt, UAC ist tatsächlich keine Sicherheitsbarriere, das hatte ich vergessen. Und natürlich hat dmelanchthon deswegen auch Recht, es gibt (zumindest theoretisch) verschiedene Möglichkeiten, UAC zu umgehen. Trotzdem erscheint mir der höchste UAC-Level um einiges sicherer zu sein als die Standardeinstellung unter Windows 7.

    SuRun habe ich empfohlen, weil es zumindest unter XP das Arbeiten erleichtert. Welche Wege es gibt, das Programm auszutricksen (z.B über Race conditions), kann ich nicht sagen. Die nähere Funktionsweise erläutert der Programmierer unter http://kay-bruns.de/wp/software/surun/surun-interna/ , zudem ist der Quellcode frei verfügbar. Wenn ich es richtig verstehe, wird der Benutzer allerdings zu keinem Zeitpunkt auch nur kurzfristig Administrator (im Gegensatz zu SuDown).  (Ich muss auch sagen, dass ich mich in System-Sicherheitsarchitektur nur rudimentär auskenne.)

    Ich meinte übrigens wirklich "Standardbenutzer" vs. "Administrator mit Split Token". Letzteren habe ich als "UAC-Admin" bezeichnet, ein selbst ausgedachter (und deswegen missverständlicher) Begriff. Übrigens scheint es nochmals etwas sicherer zu sein, als Standardbenutzer mit Over-the-shoulder zu arbeiten als als Split Token-Admin. Am sichersten ist natürlich, als Standardbenutzer ohne OTS zu arbeiten (siehe http://blogs.msdn.com/crispincowan/archive/2008/04/28/uac-desert-topping-or-floor-wax.aspx )

  15. Qwertz says:

    @dmelanchton

    Ist vielleicht ein bisschen spät, aber die UAC hilft nicht, dass trotzdem jeder Nutzer standardmässig Admin ist.

    Aber so weit ich weiss, betrachtet Microsoft selbst die UAC auch nicht als ein Sicherheitsfeature bezeichnet. Vergleiche dazu, den Bericht von Joanna Rutkowska, der sich wundert daß Microsoft selbst die neuen Sicherheitsfunktionen in Windows Vista gar nicht mehr als Sicherheitsfunktionen ansieht (Quelle: http://theinvisiblethings.blogspot.com/2007/02/vista-security-model-big-joke.html)

    Deshalb kann die UAC keine Lösung sein. Ich würde es ja begrüssen, dass jeder Anwender in Windows 8 standardmässig kein Admin mehr ist, so wie beispielsweise in Ubuntu.

  16. Qwertz says:

    @dmelanchton

    "Es gibt einen Unterschied zwischen Security Feature und Security Boundary. Du scheinst die beiden in Bezug auf UAC zu verwechseln." – Also ist die UAC gar kein Feature? Dann ist es irgendwie in meinen Augen sinnlos; kenn mich aber auch nicht so gut mit dem ganzen Sicherheits-Dingens aus 🙂 PS: Hier noch die meldung in deutsch: http://www.heise.de/security/meldung/Microsoft-relativiert-Vista-Sicherheitsfunktionen-146509.html

    "Der Artikel ist tendenziös und enthält fehlerhafte Informationen und Interpretationen." – Wieso ist er fehlerhaft? Die Aussagen die in diesem Blog geschrieben sind werden immer mit Quellen belegt?

    "Muss sie ja auch, weil Windows wesentlich häufiger angegriffen wird. " – Das ist doch kein Argument, wie die Vergangenheit oft genug gezeigt hat. Auch ist Linux doch erwiesenermassen das sicherere OS, obwohl es weniger angegriffen wird?

    Dazu ein Zitat von Dai Zovi: "Exploit writing on the Mac is fun.  Exploit writing on Windows Vista is hard work." – Das Macs unsicherer bei offline angriffen sind hat sich ja schon oft genug gezeigt 😉

  17. Stefan Kraft says:

    Das hier verspricht noch eine lustige Betriebssystemdiskussion, die wie in den anderen Fällen nicht sehr ergiebig sein wird… Mein Standpunkt ist, kurz zusammengefasst, folgender:

    UAC ist kein "security boundary", erlaubt es aber, einfacher als Admin zu arbeiten und ist im Vista-Level trotz allem ziemlich sicher bzw. alles andere als einfach zu umgehen. Oder, wie es Leo Davidson ausdrückt: "UAC in Vista provided a good security layer between admin and non-admin code and user interfaces.

    UAC was not a security boundary in the strict technical sense but it did do a good job of making it very difficult to cross from one side to the other without user consent. That is worth keeping." (http://pretentiousname.com/misc/win7_uac_whitelist2.html)

    Nicht umsonst hat Microsoft Integrity Levels, die UAC-Abfrage über einen sicheren Desktop etc. eingeführt. Meines Erachtens gehören mit dem Split Token-Admin z.B. Viren, die sich im Windows-Verzeichnis ohne weiteres installieren können, der Vergangenheit an. (Sicher, das war unter XP als Standardbenutzer auch nicht anders, aber unter XP hat man eben nicht von vornherein als Standardbenutzer gearbeitet.)

    Der Standard-Level von Windows 7 allerdings erlaubt es ohne weiteres auch bösartigen Programmen, Admin-Aktionen auszuführen, ohne dass eine UAC-Abfrage erscheint. Theoretisch ist das auch im höchsten UAC-Level möglich, aber das scheint derartig schwierig zu sein, dass es bis jetzt in der Praxis nicht oder kaum aufgetaucht ist – und zeigt, dass MS in dieser Hinsicht durchaus gute Arbeit geleistet hat. Trotzdem sollte man für Windows 8 auch hier noch weiter verbessern, z.B. Standardbenutzer wirklich zum Standard machen o.ä., denn "sicher ist sicher" (blöder Kalauer, zugegeben).

    Eine Diskussion zwischen Leo Davidson und Chris Corio, der an der UAC-Entwicklung beteiligt war, findet man in den Kommentaren unter http://www.withinwindows.com/2009/06/10/uac-uac-go-away-come-again-some-other-day/ .

    Persönlich bin ich übrigens im grossen und ganzen zufriedener 7-(Standard)Benutzer und sehe keinen echten Grund, das Betriebssystem zu wechseln – sonst würde ich auch nicht in diesem Blog vorbeischauen. Aber das ist nur meine persönliche Meinung. 😉

  18. Qwertz says:

    @dmelanchton

    Wow! Ich hätte jetzt echt nicht gedacht, dass Du einen so ausführlichen Widerleg bringst. Mir hätten eigentlich nur 2-3 Beispiele geriecht, die dort nicht stimmen, aber dass es so ausführlich von dir wird *thumbs up*

    "Es wird soviel Unsinn im Netz geschrieben.." – Das weiss ich auch, nur erschien mir der Artikel seriös und WOT meinte er sei "Vertrauenswürdig". Aber du hast das Gegenteil ja sehr ausführlich jetzt bewiesen 😉

    Vielen Dank, das Du dir die Zeit genommen hast!

  19. Stefan Kraft says:

    @dmelanchthon: Den Vortrag von Mark werde ich mir bei Gelegenheit gerne ansehen. 🙂 Seinen Process Explorer benutze ich ja auch, es ist irgendwie faszinierend, den Prozessen beim Arbeiten zuzusehen. 😉

    Wie gesagt, ich beschwere mich ja nicht in erster Linie, dass UAC kein Security boundary ist, sondern eher, dass der Standardlevel in Windows 7 noch "lascher" (?) ist als unter Vista. Ich kann es akzeptieren, wenn UAC irgendwie kreativ umgangen wird (das machen Hacker ja nun mal gerne 😉 ), aber mein Eindruck ist, dass man es den Hackern dann eher schwieriger und nicht noch einfacher machen sollte.

    Ansonsten Danke für Deine ausführlichen Antworten. 🙂 Und wie gesagt, Windows 7 benutze ich gerne. (Als Standardbenutzer 😉 )

  20. Stefan Kraft says:

    Doch noch ein P.s. von mir: Ich bin verwirrt.

    – Als echter Admin à la XP arbeiten -> natürlich unsicher

    – Split Token-Admin unter Standard-Level von Windows 7 -> schlecht, denn nachweislich kann sich ein Prozess ohne UAC-Abfrage selbst zum Admin befördern.

    – Split Token-Admin unter Vista oder höchster Level unter Windows 7 -> auch schlecht?

    Wozu dient dann eigentlich UAC? Um Programmierer zu erziehen, endlich mal gescheite Software zu programmieren? Aber warum dann der Aufwand mit sicherem Desktop, integrity leveln etc.?

    (Persönlich denke ich, dass der höchste UAC-Level doch einen Vorteil hat – ich muss auf jeden Fall eine UAC-Abfrage abnicken, bevor sich ein bösartiger Prozess über Hooks etc. zum Admin befördern kann. Und mit ein bisschen Glück mache ich das tagelang nicht, und bis dann hat mein Virenscanner oder ich selbst bemerkt, dass ein seltsamer Prozess im Benutzerkontext unterwegs ist. Beim Win7-Standardlevel dagegen kann sich der bösartige Prozess sofort ohne Rückfrage als Admin tief im System vergraben.)

    Und wie sieht es mit folgenden Situationen aus (SuRun etc. ist nicht installiert):

    – Standardbenutzer mit Over-the-shoulder-Elevation -> sicher nicht das Originalsicherheitskonzept von Dave Cutler, aber doch besser als normaler Split Token-Admin?

    – Standardbenutzer ohne Over-the-shoulder-Elevation -> sicher (oder?)

    Mein Problem ist folgendes: Wenn man als 0815-Benutzer ein System in Betrieb nimmt, überall die UAC-Schilder sieht und ein Bekannter sagt, das erhöhe die Sicherheit, denkt er sich nichts böses. Irgendwo tief in der Hilfe steht zwar, man solle zur Sicherheit nicht als Split Token-Admin, sondern als Standardbenutzer arbeiten, aber das wird der 0815-Benutzer nie lesen (weil es auch der Bekannte nicht tat). Wenn es dann doch rummst und sich irgendein fieses Virus einnistet, was der Virusscanner aber erst einen Monat später nach Signaturupdate festellt, dann wird der Benutzer Argumente à la "Trotz Schildsymbol ist UAC ja eigentlich gar nicht für Sicherheit da, man soll standardmässig als Standardbenutzer arbeiten, kann man bei MSDN nachlesen" sicherlich nicht zu schätzen wissen… Besonders, wenn ein anderer Bekannter ihm dann erklärt "UAC war schon unter Vista nicht sicher implementiert, aber statt das unter Win 7 besser zu machen, hat man es noch einfacher gemacht, UAC zu umgehen" (jetzt mal egal, ob das objektiv stimmt oder nicht, aber mir kommt es leider so vor).

    Um aber eines klarzustellen: Ich finde es gut, wie Du (Daniel, d.h. dmelanchthon) hier Rede und Antwort stehst und Dir viel Zeit nimmst. Mir ist auch klar, dass UAC etc. nicht Dein Aufgabenbereich bei MS sind und Du deshalb nur erklären, aber nicht direkt etwas ändern kannst, das hebt Deinen Einsatz nochmals hervor. Ich bin im Moment einfach durcheinander und möchte (klipp und klar 😉 ) wissen, wozu UAC gut ist und wie sicher denn nun die oben genannten Einstellungen sind.

  21. MacMark says:

    Bezüglich "# dmelanchthon said on April 26, 2010 5:42 PM:"

    Deine "Widerlegung" zeigt, daß Du nicht richtig liest.

    Beispiele:

    Ich schreibe: "keine durch ungeeignete System-Architektur bedingten Schwachstellen".

    Du liest aber: "keine Schwachstellen".

    Unterschied bemerkt?

    Ich habe die entscheidende Stelle sogar extra fett gedruckt. Aber manche verstehen es trotzdem nicht.

    Ich schreibe: "Eine wirkungsvolle Schwachstelle ist eine, mit deren Hilfe ein Fremder ohne Zutun der Benutzer den Rechner in Standardkonfiguration per Netzwerk übernehmen könnte."

    Du liest aber: "… ist eine, bei der der User etwas runterlädt und dann doppelklickt."

    Das ist, was bei Secunia unter "remote" gelistet wird.

    Ich rede jedoch davon, daß der User nichts (!) tun muß dabei.

    Dann ging es um die falsche Pauschalaussage "viel Marktanteil, darum viele Angriffe". Eine Pauschalaussage kann mit einem einzigen Gegenbeispiel widerlegt werden. Diese Aussagenlogik hast Du nicht begriffen.

    Beispiel: Pauschalaussage: "alle Autos sind rot". Widerlegung: "es gibt ein blaues Auto". Dann Du: "Hier sind noch zwei rote Autos, also sind doch alle Autos rot."

    Und so geht Deine "Widerlegung" munter weiter.

    Du liest nicht genau, was ich schreibe und mißinterpretierst es absichtlich oder aus Nichtverstehen.

    Grüße von

    MacMark

  22. MacMark says:

    Du hast auch meinen Kommentar nicht verstanden.

  23. Qwertz says:

    @macmark

    Die Aussage, dass Mac OS X keine durch System-Architektur bedingten Fehler hat, finde ich sehr waage, zumal irgendwie jedes System irgendwie Lücken hat.

    Aber auch sonst, wenn man sich beispielsweise das letzte Security-Update von Mac OS X anschaut, sind dort ja so Brüller wie "Man kann sich remote über ein altes Passwort einloggen, und Login-Restriktionen wirken auch nicht" dabei (Quelle: http://support.apple.com/kb/HT4077?viewlocale=de_DE).

    "Eine wirkungsvolle Schwachstelle ist eine, mit deren Hilfe ein Fremder ohne Zutun der Benutzer den Rechner in Standardkonfiguration per Netzwerk übernehmen könnte." – Und genau solche Schwachstellen, waren ja auch beim letzten Security-Update, oder etwa nicht? 😉

  24. xyz says:

    @Qwertz: Wage ist da noch untertrieben.

    @MacMark: Weitere Beispiele gefällig?

    "Ein Angreifer, der sich in physischer Nähe eines drahlosen Netzwerks befindet, kann einen Überlauf auslösen, indem er einen in böser Absicht hergestellten Frame in das Netzwerk einführt. Wenn AirPort eingeschaltet ist, könnte dies zur Ausführung willkürlichen Codes mit Systemprivilegien führen"

    "Ein Angreifer, der sich in physischer Nähe eines drahtlosen Netzwerks befindet, könnte den Überlauf auslösen, indem er einen in böser Absicht hergestellten Frame in das Netzwerk einführt. Dies könnte zu einem Systemabsturz, einer Privilegienerhöhung, oder zur Ausführung willkürlichen Codes mit Systemprivilegien führen."

    "Wenn ein Programm betroffen ist, könnte ein Angreifer, der sich in physischer Nähe des drahtlosen Netzwerks befindet, einen Überlauf auslösen, indem er einen in böser Absicht hergestellten Frame in das Netzwerk einführt. Dies kann Systemabstürze verursachen oder dazu führen, dass mit den Privilegien des Benutzers der Anwendung willkürlicher Code ausgeführt wird."

    http://support.apple.com/kb/HT2697?viewlocale=de_DE

    Alle drei Angriffsmöglichkeiten setzen lediglich einen Apple Laptop in Standardinstallation voraus. Das sind doch wohl wirkungsvolle Schwachstellen, mit deren Hilfe ein Fremder ohne Zutun der Benutzer den Rechner in Standardkonfiguration per Netzwerk übernehmen kann.

    Also hör auf, so einen Unsinn zu erzählen. Was Du da auf Deiner Seite schreibst, ist einfach nur falsch (woanders nennt man sowas FUD). OSX ist ein sicheres System  – aber unbezwingbar ist es auch nicht. Es wird überall nur mit Wasser gekocht.

  25. MacMark says:

    @Qwertz

    OS X Server hatte einen Bug im Kennwortserver, der bei der Replikation von Kennwörter eventuell ein neueres Kennwort nicht replizierte. Solange man sein Kennwort gut wählt und geheim hält, ist das per se kein Problem. Es ist nur ärgerlich, daß das neue Kennwort
    nicht übernommen wurde, wenn man sein altes in der Kneipe rumerzählt hatte. Ein Bug, der leicht gefixt werden konnte, kein Architekturfehler.

    Der Fehler betraf nur die Replikation in OS X Server. Wenn Du aber auf OS X Dein Paßwort änderst, wird es problemlos übernommen.

    @xzy

    Ebenfalls keine Architekturfehler, sondern banale, leicht zu fixende Buffer-Overflow-Bugs.

    Apple drückt sich in den Reports immer absichernd aus mit "kann möglicherweise". Aber nicht jeder Overflow kann tatsächlich exploitet werden.

    Im Gegensatz dazu: Ein typischer Architekturfehler, den man nicht mal eben so beheben kann ist beispielsweise dieser, den Microsoft 7 Jahre lang nicht fixen konnte:

    http://www.macmark.de/osx_security.php#design_fehler_schwer_behebbar

    Er erforderte einen jahrelangen Umbau von Windows. Das macht den Unterschied aus zwischen Bugs und Architekturfehlern.

  26. MacMark says:

    Ich war ja oben schon auf die ersten Punkte in der "Widerlegung" von dmelanchthon eingegangen, hatte dann aber nach den ersten enttäuschenden Punkten mir den Rest erstmal geschenkt. Ich ergänze jetzt noch die weiteren Punkte:

    Irgendwie hat er auch bei diesen Stellen meinen Artikel nicht vollständig gelesen, sonst wüßte er, daß Windows NT erst 1998 durch eine nachträgliche Erweiterung für NT 4 mehrbenutzerfähig wurde.

    "Administrative Rechte" auf OS X sind nicht wie auf Windows Systemrechte. OS X-Systemrechte hat root und die Gruppe wheel, nicht jedoch die Gruppe Admin.

    Die "Rechte nehmen" ist ein Windows-Vista-Ding. Bei OS  X kann ein Admin sich die Rechte nicht nehmen. Es findet ein Benutzerwechsel (!) auf root statt.

    Windows (jede Version) hat keine POSIX-Rechte oder vergleichbares. Windows-Dateirechte basieren ausschließlich (!) auf ACLs. Unix und OS X haben auch ACLs, aber zusätzlich zu POSIX. ACLs sind fehleranfällig in der Konfiguration.

    Windows-Admins sind gleichmächtig mit System, auch der "Protected Administrator" in Vista und 7 mit seiner gespaltenen Persönlichkeit, deren Prozesse mit unterschiedlichem Integrity Level in einer (!) Session leben. Bei Zweifeln daran, bitte Mark Russinovich (Microsoft) fragen oder auf einen meiner nächsten Artikel warten, in dem ich die Infos auf Deutsch bringe.

    Auf den Trusted Installer gehe ich in meinem Security-Artikel auch ein. Hat dmelanchthon auch das überlesen?

    Die deutsche Übersetzung der Doku bei Apple hat einen Fehler. Schau in das englische Original oder schau direkt in OS X nach. Admins sind in admin und staff, aber nicht in wheel. Da ist nur root drin.

    Du siehst, Du bewegst Dich fachlich auf sehr dünnem Eis, dmelanchthon. Das reicht leider vorne und hinten nicht als "Widerlegung".

    Dein Absatz über den 64-Bit-Kernel zeigt auch nur, daß Du nicht die Hintergründe kennst. Es geht darum, daß die Konsumer-Geräte erst mit 64-Bit-Kernel laufen sollen, wenn die relevanten Treiber dafür 64-bittig sind. Vorher ist das nur bei den anderen Geräten sinnvoll. Empfehle dazu den Blog-Eintrag von Amit Singh auf seiner OS X-Seite. Man sollte da nicht am System rumpfuschen.

    Dann kommt die Stelle an der dmelanchthon einen Workaround für OS X Server aus dem Jahr 2003 anspricht. Man muß und kann sich auf OS X standardmäßig nicht als root anmelden. Dein Stochern und Fehlinterpretieren von irgendwelchen uralten Workarounds zeigt nur, daß Du das Prinzip in OS X nicht kennst.

    Vista-Admins können praktisch das Gleiche tun wie der "eingebaute Administrator".  Sie haben die vollen administrativen Rechte und zeitgleich in der gleiche Session auch noch ein Token für Normaluser-Rechte. Das Problem ist die gemeinsame Session.

    Vista-Admins können in die private Verzeichnisse der anderen User gehen. Vielleicht probierst Du es einfach mal aus.

    Dann hat er nochmal eine Anleitung nicht verstanden. Wenn Dir ein Objekt nicht gehört, dann kann nur root den Besitzer dafür ändern, kein OS X-Admin.

    Ich schreibe über OS X (UNIX) und nicht über MacOS 9 und früher, welches überhaupt kein UNIX war.

    NTFS gibt es schon lange, es wurde aber vor Vista wenig in der Praxis eingesetzt.

    Die Dateirechte in Windows basieren ausschließlich auf ACLs und das auch erst ab NT. Windows hat keine POSIX-Rechte wie UNIX. (Mmh, das hatten wir doch schon oben.)

    Dir ist unbekannt, daß NT ermöglichte, ACLs zu ignorieren aus Kompatibilitätsgründen?

    Admins unter Vista können sich alles krallen im System. Admins in OS X nicht. Das erfordert root. Daß das für Dich ein Rätsel ist, wundert mich inzwischen schon nicht mehr, wenn man bis hierhin gelesen hat.

    Dann ein paar Ausreden über Windows-Admins ohne zwingendes Kennwort.

    Die Low-Integrity Prozesse eines Protected Admins können seine High-Integrity Prozesse beeinflussen und auch selbst Code mit hohem Level ausführen. Wenn Dir das technisch unklar ist, dann verweise ich nochmal an Mark Russinovich (Microsoft) für Nachhilfe. Der gemeine Mausschubser kennt diese Details nicht, das ist mir klar. Ich werde daher mal einen Artikel darüber schreiben, der die sich ganz auf Mark Russinovich (Microsoft) stützt. Die nachfolgenden Absätze zeigen auch wieder Deine technische Unkenntnis über die Vista- und 7-Internas der UAC. Du hast noch keine einzige Technote von Mark Russinovich (Microsoft) verstanden, oder?

    Zusammenfassend ist mein Eindruck von Dir folgender:

    Du liest nicht richtig, was ich schreibe. Du hast von OS X nicht die leiseste Ahnung und bist auch nicht in der Lage Artikel dazu richtig zu verstehen. Dir fallen nicht mal grundlegende Fehlinfos darin auf. Dir ist der Unterschied zwischen Windows-Admins und OS X-Admins nicht klar. Dir sind die Interna von UAC und dem "Protected Admin" in Vista und 7 nicht klar. Du kannst nicht mal POSIX-Rechte richtig einordnen. Dir ist auch nicht klar, daß die Berechtigungsstufen (Integrity Level) tatsächlich nichts mir Sicherheit zu tun haben. Das legt wiederum nahe, daß Du die UAC-Artikel von Mark Russinovich (Microsoft), falls Du sie denn gelesen hast, nicht verstanden hast. Du überfliegst technische Artikel nach Schlagworten und verstehst die tatsächlichen Aussagen darin irgendwie nicht. Mutmaßlich, weil Du kein Programmierer bist, sondern wie ich gerade unten sehe "Evangelist":

    Ich schicke Dir eine Email, wenn ich Marks Artikel auf Deutsch verarbeitet habe. Voraussichtlicher Titel: "Das UAC-Placebo".

    Bis dann!

    MacMark

  27. @dmelanchthon says:

    Hi,

    "Die Aktivierung des 64-Bit-Kernels war ein Beispiel von mir um zu zeigen, dass man auch bei Mac OS X manchmal für einfachste Konfigurationsaufgaben tief in das System von der Kommandozeile eingreifen muss. […] So bin ich bei

    der Nutzung von Mac OS X darüber gestolpert, den Standard-Zoom-Level von Safari zu verändern. Das beste, was ich als Lösung gefunden habe, ist zum Beispiel auf macosxhints.com  beschrieben."

    Ich persönlich würde aallerdings diese Möglichkeit bei Windows auch lieber vorziehen. Ich habe keinen Mac um das jetzt zu kontrollieren und so, aber ich persönlich hätte lieber eine Kommandozeile um alles im System verändern zu können statt x-Tools zu benötigen wie in Windows derzeit. Das Tool WinBubble beispielsweise ist doch ein Beispiel dafür, was Microsoft versäumt hat, in den Einstellungen einstellbar zu machen. Bei OS X könnte ich es wahrscheinlich alles über eine integrierte Kommandozeile machen, aber wie gesagt, kontrollieren kann ich es nicht.

    Das war eventuell ein bisschen OffTopic aber musste mal gesagt werden. Vielleicht ändert sich ja was in Windows 8 oder 9 oder so…

    "Jetzt tust Du sie als banale Buffer Overflows ab, die aber durch den Einsatz von z.B. DEP und ASLR wesentlich erschwert werden würde."

    Vielleicht sind es Schutzmechanismen, ich finde sie sind aber ein wenig schlecht durchdacht. DEP hat nämlich bei mir schon oft für Abstürze in GTA 4 gesorgt 🙁

    Und zum Thema allgemeine Sicherheit: Was bei mir enorme Bedenken auslöst ist, dass ein Virenscanner ohne weiteres Systemrelevante Daten verschieben, löschen, ausschneiden, whatever darf ohne eine Bestätigung vom Administrator zu verlangen. Jedenfalls hört man ja mal öfters in News, dass Antivirensoftware xyz bei Windows einen Bluescreen erzeugte. Letzthin war es glaub ich McAfee der in den Schlagzeilen stand, oder so.

    "Seit wann hat denn Mac OS ein modernes Dateisystem, dass zumindestens mit NTFS vergleichbar oder besser wäre?"

    Mhh… bei NTFS hat viele Schwächen die Mac soweit ich weiss nicht hat (Fragmentierung, Laufwerksbuchstaben, und so) Ich würde mal hier schauen: http://www.chip.de/…/Windows-8-So-koennte-die-Zukunft-aussehen-4_41944347.html

    So, dass war mein Senf dazu. 🙂 Hoffe er schmeckt.

    MfG

    Qwertz

  28. @dmelanchthon says:

    Hi 🙂

    "Die Einstellungen, die das Tool WinBubble bequem von der GUI aus erreichbar macht, haben wir übrigens nicht einfach versäumt, in die Systemsteuerung zu integrieren. Wenn alles, was in Windows konfigurierbar ist, auch eine entsprechende grafische Konfigurationsoberfläche hätte, wären Anwender überfordert, weil die schiere Auswahl an zehntausenden Konfigurationsoptionen einen dann erschlägt. "

    Ich hätte es allerdings trotzdem lieber, wenn ich alles an Windows schon vom Start an Einstellen könnte. Wie man es integrieren kann, so dass er einfache Anwender sich nicht erschlagen fühlt, hab ich mir mal ein paar Situationen vorgestellt: 1. Man könnte ein Auswahlkäschen Namens "Erweiterte Einstellungen einblenden" bei den Systemeinstellungen integrieren. 2. Gewisse Einstellungen sind nur Sichtbar, wenn man als Administrator angemeldet ist. So merken normale User gar nichts von den vielen Einstellungen. 3. Gewisse Einstellungen sind beispielsweise nur sichtbar bei der Eingabe einer gewissen Tastenkombination (die man sich in der Windows-Hilfe nachlesen kann). So sind Durchschnittsuser auch nicht erschlagen. Desweiteren würde ich es nicht begrüssen, wenn es Microsoft so wie Apple macht. Man hat bei Apple über die GUI fast keine Möglichkeiten sein System anzupassen. Da ist Windows schon viel weiter.

    Apropos zu deinem Kommentar, dass sich alles über die Regystry regeln lässt: Wurde nicht schon oft die Abschaffung der Registry gefordert? Ist die Registry nicht ein veralltetes Ding, welches oft auch öffentlich Kritisert wurde (beispielweise als Apple Snow Leoaprd veröffenltichte und gegen Windows 7 geflamt hat). Allgemein befürworte ich den CHIP-Artikel sehr und würde es sehr schätzen, dass diese Dinge (nicht nur das NTFS-Gedöns) auch in Windows 8 Einzug erhalten.

    "Zu DEP: Wenn bei Dir ein Spiel wie GT4 bei eingeschaltetem DEP abstürzt, ist das ein Zeichen, dass das Spiel einen Fehler enthält und dieser besser im Spiel behoben werden sollte."

    Natürlich, klar, das Spiel ist Schuld und nicht Windows. Windows bringt mir zwar so eine nette Sprechblase bei der Tray, dass das Spiel durch DEP blockiert wurde, aber die Sprechblase sollte mich auch fragen, ob ich zukünftig eine Ausnahme für dieses Programm hinzufügen möchte. Das wäre meiner Meinung nach perfekt. Vielleicht ist es in Windows 7 schon so, in Vista jedenfalls nicht.

    "Was Deine enormen Bedenken Virenscannern gegenüber angeht: Ein Virenscanner arbeitet gerade mit höchsten Rechten, damit er jederzeit in der Lage ist, z.B. jeden Dateizugriff zu scannen und möglicherweise zu verhindern. Deshalb kann er auch systemrelevante Daten verschieben, löschen, ausschneiden, whatever. "

    Mir geht's allgemein darum, dass ein x-Beliebiges Programm (welches isch auch als Virenscanner tarnen könnte) sich im Hintergrund einfach so still die Rechte erhöht. Ich glaube diese Problematik hat auch Macmark angesprochen. Ich finde das bedenklich, denn dann müsste sich eine Schadsoftware, die zwar erst durch den Klick des Administrators installiert werden kann, nur dem System als Virenscanner ausgeben und hat sofort die höchsten Rechte. Das geht nicht.

    "Und zum Schluß die Laufwerksbuchstaben. Was Du daran als "Schwäche" meinst, verstehe ich jedenfalls nicht. "

    Ich habe es noch nie getestet, aber stell dir vor, jemand will 26 Festplatten bzw. 26 Systempartitionen errichten. Was passiert dann? Oder ist Windows beschränkt auf 26 Festplatten/Systempartitionen?

    "Darüber hinaus bietet es zum Beispiel transparente […] Verschlüsselung auf Dateiebene und die Möglichkeit, systemübergreifende Transaktionen auch auf dem Dateisystem abzubilden. "

    Das Verschlüsselte Dateisystem von Windows  (EFS) gibt es ausschliesslich in der Ultimate-Version. Ich rede lieber für die Allgemeinheit.

    PS: Microsoft hatte mal einen Prjekt Namens "Gazelle". Werden die Ergebnisse dieses Projekts in den IE9 einfliessen?

  29. MacMark says:

    Ich hatte weiter oben eine deutsche Verarbeitung verschiedener MS-Artikel (Mark Russinovich und andere) bezüglich UAC  angekündigt. Die erste Version ist fertig:

    http://www.macmark.de/windows_uac_security_placebo.php

  30. Anonym says:

    …und in China fällt ein Sack Reis um. Nichts was Du auf Deiner Fanboy-Seite in dem UAC-Artikel schreibst, ist neu oder interessant. Wie wäre es, wenn Du stattdessen Deine Energie mal in die Korrektur der anderen Artikel steckst? Aber darauf wird man wohl ewig warten können – Du erlaubst ja nicht mal Kommentare auf Deiner Seite. Wie war das noch mit dem ARDAgent (http://www.heise.de/…/Root-Exploit-fuer-Mac-OS-X-215351.html)? Der erlaubte noch viel einfacher, Dinge mit Admin-Rechten auszuführen: osascript -e 'tell app "ARDAgent" to do shell script "whoami"';

    Naja, vielleicht kannst Du ja mal was zu jedem Eintrag von http://www.macexploit.com/ schreiben, da bist Du ja erstmal etwas beschäftigt.

  31. MacMark says:

    Hi Daniel,

    zu "com.apple.systemloginitems.plist":

    Der "Hacker" schreibt, es funktioniere auf 10.6. Tztztztz. Da hat er seine Hausaufgaben aber nicht gemacht, denn der Mechanismus ist seit 10.5 deprecated und seit 10.6 meines Wissens nicht mehr vorhanden.

    So oder so, sein "Hack" funktioniert auf 10.6 Snow Leopard nicht. Zu sehen beispielsweise daran, daß das versprochene /Users/Shared/.SLIHack nicht erzeugt wird. Vielleicht probierst Du Deine nächste Behauptung erstmal selbst aus, bevor Du Dich wieder blamierst.

    Solche alten System-Start-Mechnismen sind im Laufe der Zeit von launchd abgelöst worden. Man sollte die "Hacker" mal darüber informieren 😉

    Analoges gilt für die Seite http://www.macexploit.com/ von "Anonym". Probier die Sachen selbst aus und wenn etwas funktioniert, dann diskutieren wir die möglichen Auswirkungn.

    Beste Grüße von

    MacMark

  32. andreas says:

    Hi MacMark,

    selbst wenn das in Snow Leopard nicht mehr klappt ist es ein Skandal, dass das jahrelang in OSX enthalten war. Das solltest du in Deinem Artikel ruhig berücksichtigen, der sehr einseitig ist. Sorry, aber so wirst Du nur als Fanboi wahrgenommen.

    Du unterschlägst auch, dass Apple monate- und teilweise jahrelang bekannte Lücken nicht schließt. Eine IBM-Studie hält Mac-OS X übrigens für unsicher:

    In der Tat sieht die Prozentquote zwischen gemeldeten Sicherheitsrisiken und Apples Updates finster aus. Die absoluten Zahlen sprechen andere Bände. Mac-OS X gilt als das angreifbarste Betriebssystem, berichtet IBMs Entwicklungsteam für Forschung und Sicherheit in seinem Jahresbericht. Das Team X-Force Research zählt die der Fehlerbehebungen der Hersteller in Relation zu der Gesamtanzahl von offiziell gemeldeten Sicherheitslücken. Im Fall von Mac-OS X und OS X Server bleiben demnach 14,3 Prozent der Probleme offen.

    http://www.macnn.com/…/mac.os.vulnerabilities

  33. MacMark says:

    Hi Andreas,

    SystemLoginItems waren kein "Skandal", sondern ein Vorgänger von LaunchAgents. Admins dürfen solche installieren. SystemLoginItems sind nicht mehr nötig, funktionieren daher mit 10.6 nicht mehr. Die Kern-Aussage auf der SLIPOC-Seite "processes running on
    admin account can in fact perform tasks as root without being required to authenticate" ist schlicht falsch. Da ist kein Admin-Prozeß, der etwas als root ausführt.

    Daß er für SystemLoginItems einen Proof Of Concept meint bringen zu müssen, ist peinlich, denn an seiner Stelle hätte ich einfach auf eine alte Version von Timbuktu verwiesen. Zeigt halt, daß er sich nicht wirklich auskennt. Ist aber nichts neues bei den
    meisten "Hackern".

    Ich unterschlage gar keine Bugs, denn ich habe eine stets aktuelle neutrale Bug- und Fix-Statistik schon immer hier verlinkt:

    http://www.macmark.de/osx_security.php

    IBM ist als Konkurrent ganz sicher keine neutrale Quelle dafür. Zudem ist "Angreifbarkeit" gemessen in absoluter Anzahl von Bugs Unfug, weil es nicht auf die Quantität, sondern auf die Qualität der Bugs ankommt: So wiegt der Bug, der den Windows Conficker-Wurm
    ermöglichte, oder der Windows SMB-Bug, der sieben Jahre nicht behoben werden konnte (!) und Remote-System-Übernahme erlaubte, schwerer als alle Bugs für OS X, die es je gab, zusammen.

    Der gravierende Unterschied, auf den es mir ankommt, ist aber viel heftiger: Unter Windows ist nicht mal ein Bug nötig, um das System kompromittieren zu können. Ein Beispiel ist die UAC:

    http://www.macmark.de/windows_uac_security_placebo.php

    Und so ein vergeigtes System kann man leider nicht mal eben fixen, weil das Problem kein Bug ist, sondern diverse Architekturfehler.

    Grüße von

    MacMark

  34. andreas says:

    Schade, dass Du Dich nur darauf verlegst, andere "Hacker" als unfähig darzustellen. Ich persönlich finde die Darstellung auf der Seite
    rixstep.com/…/20080702,00.shtml für glaubwürdiger als Deine Einlassungen. Ich habe mal im Internet ein wenig gesucht. Ich fand Bestätigungen für die Angaben aus dem Link oben,
    aber keine für Deine Meinung. Z.B. hier:
    radsoft.net/…/20080702,00.shtml
    oder hier. Lies mal die Mail, die Dave Schroeder an product-security@apple.com geschickt hat:

    /Library/StartupItems does not exist by default on a standard installation of Mac OS X. Its permissions are set by the first user/installer to create it; if none are explicitly specified, it is created with the permissions of the parent /Library directory,
    which is root:admin 775. At first glance, this does not appear to violate the standard permissions and administrative user model for Mac OS X. Every task that can allow an installer or other process to actually become ‘root’ prompts for a password either via
    sudo or AuthServices, notifying the user that something is requesting elevated privileges. However, this is not true of /Library/StartupItems. Because its permissions usually end up being root:admin 775, items may be placed within it without the users knowledge,
    and may become root upon the next boot. This represents a serious discrepancy in the model of always prompting for credentials for elevated privileges. While it might indeed be a trojan that would do something like this, prompting for administrative privileges
    is an important delineation: in the prompt scenario, the user must explicitly grant the installer or process root-equivalent privileges. But with the current /Library/StartupItems situation, an installer, or even an application without an installer, can place
    items in /Library/StartupItems, creating it first if necessary, without any prompts or knowledge of the user, and can subsequently become root.

    Deiner Meinung nach ist das alles nur gelogen? Und was ist mit den anderen Punkten, den ewig offenen bekannten SIcherheitslücken, der ARDagent, etc. Die IBM-Studie wies ja auch nach, dass Apple bekannte Sicherheitslücken über längere Zeit offen lies. Du
    machst es Dir mit dem Verleugnen der Probleme zu leicht und bist daher unglaubwürdig. Schade, ich hatte gedacht, dass Du selbstkritischer wärst.

  35. andreas says:

    Hab noch den Link zu dem Schreiben vergessen: macintouch.com/opener.html

  36. andreas says:

    Und noch ein Nachtrag. Startup Items sind gemäß der Dokumentation von Apple weiterhin enthalten:

    developer.apple.com/…/BootProcess.html

    Weiterhin laufen sie im Root-Kontext: "Startup Item Permissions – Because startup items run with root authority, you must make sure your startup item directory permissions are set correctly.

    developer.apple.com/…/StartupItems.html

    Je mehr ich darüber nachlese, um so mehr finde ich Belege, die Deinen Behauptungen widersprechen.