Google Chrome: Sandbox-Mechanismus von OS X rockt [Archiv]

Gast

2010-04-06, 18:56:37

Building a secure browser is a top priority for the Chromium team; it's why we spend a lot of time and effort keeping our code secure. But as you can imagine, code perfection is something almost impossible to achieve for a project of this size and complexity. To make things worse, a browser spends most of its time handling and executing untrusted and potentially malicious input data. In the event that something goes wrong, the team has developed a sandbox to help thwart any exploit in two of the most popular vectors of attack against browsers: HTML Rendering and JavaScript execution.
http://blog.chromium.org/2008/10/new-approach-to-browser-security-google.html

Es ist eine ziemlich komplizierte Angelegenheit, um auf Windows einen Prozeß (laufendes Programm) auf eine für uns brauchbare Art in eine Sandbox zu sperren. Der relevante Quellcode dazu besteht aus über 100 Dateien.

Für unsere Google Chrome-Portierung auf Linux-basierte Systeme und auf OS X war Sandboxing eine völlig andere Geschichte:

Für Linux-basierte Systeme gibt es einige verschiedene Sandbox-Mechanismen. Unterschiedliche Linux-Distributionen werden mit unterschiedlichen (oder gar keinen) Sandbox-APIs ausgeliefert. Und einen Mechanismus zu finden, der garantiert auf den Endbenutzer-Maschinen auch funktioniert, ist eine Herausforderung.

Zum Glück sind auf OS X die APIs, um einen Prozeß zu sandboxen, leicht zu benutzen und unkompliziert.
http://www.macmark.de/blog/osx_blog_2010-04.php#chrome_shows_good_sandbox_bad_sandbox

(del)

2010-04-06, 18:57:25

OSX hat das mit steigender Beliebtheit auch bitternötig.

Gast

2010-04-06, 19:06:09

OSX hat das mit steigender Beliebtheit auch bitternötig.
Bis auf das nicht ganz Ast reine implementierte ASLR ist OSX eigentlich einem Windows 7 bzgl. Sicherheit überlegen.
Bitte nicht Sicherheitslücken, die man patchen kann, mit Systemdesign verwechseln.

Ob die Systemarchitektur Schwachstellen hat. Manche Betriebssysteme bieten durch Architektur-Schwachstellen (broken by design) bestimmte Angriffsmöglichkeiten allein durch ihre gewollten, offiziellen Eigenschaften auch ohne Programmierfehler. Dies ist zu unterscheiden von Angriffsmöglichkeiten, die durch Programmierfehler entstehen, denn Programmierfehler kann man beheben, Architektur-Fehler nicht.
http://www.macmark.de/osx_security.php#einleitung

OSX 10.7 wird wohl ASLR vollständig haben (davon gehe ich aus) und dann wohl ohne wenn und aber das sicherste Desktop-System sein (aus Sicht des Systemdesigns -> Systemdesign != Sicherheitslücken).

Gast

2010-04-06, 19:22:51

Bitte nicht Sicherheitslücken, die man patchen kann, mit Systemdesign verwechseln.Gegebenheiten sind Gegebenheiten.

OSX ist das schöne ruhige Landleben auf der Ranch - mit einer Flinte, im Kornfeld - im Haus mit nur Fliegengitterrahmen auf Scharnieren als Türen und wo das nächste Haus und der nächste Mensch kilometerweit entfernt ist.

Windows ist das Nachtleben in LosAngeles.

Ich empfehle den Wohnsitz der beiden nicht wegen bisschen Sand in der Box zu unterschätzen. Und freue mich trotzdem auf die Vergleiche, sobald der Bauer in der Stadt angekommen ist.

Coda

2010-04-06, 20:18:35

Könnt ihr bitte aufhören diese Seite als "Quelle" zu verlinken? Was genau soll dabei besser an OS X sein außer dass man einfacher eine Sandbox etablieren kann?

Und weil OS X so sicher ist patcht Apple auch mal kurz 88 Sicherheitslücken: http://support.apple.com/kb/HT4077
Gööönau.

Apple wird noch böse auf die Fresse fallen wenn sie mit ihrer Sicherheitspolitik so weiter machen und ihre Marktanteile steigen.

(del)

2010-04-06, 20:25:22

Du darfst das halt nicht mit dem Systemdesign verwechseln :up:

Coda

2010-04-06, 20:26:49

Was genau soll denn am OS-X-Systemdesign noch viel sicherer sein als von Vista und 7 mit UAC?

Gast

2010-04-06, 20:45:40

Du darfst das halt nicht mit dem Systemdesign verwechseln :up:
Eben!

Und weil OS X so sicher ist patcht Apple auch mal kurz 88 Sicherheitslücken: http://support.apple.com/kb/HT4077
Gööönau.
Das sind Sicherheitslücken. Ja, da schlampt Apple.
Aber Sicherheitslücken kannst du patchen.

Die grundlegenden Designschwächen von Windows kann man nicht so ohne weiteres patchen. OK, da hat MS einiges getan. Einen Zaum drum gezogen - sie sind aber zum Tiel immer noch da. Die schleppt MS mit bzw. baut die im Laufe der Zeit ab.

Könnt ihr bitte aufhören diese Seite als "Quelle" zu verlinken? Was genau soll dabei besser an OS X sein außer dass man einfacher eine Sandbox etablieren kann?
Die Seite ist einseitig geschrieben. Dennoch stimmt dort VIELES (nicht alles - manches ist wirklich zweifelfhaft oder Stuss).
Aber das was stimmt, wirst du nicht widerlegen können.

Könnt ihr bitte aufhören diese Seite als "Quelle" zu verlinken? Was genau soll dabei besser an OS X sein außer dass man einfacher eine Sandbox etablieren kann?
Steht doch da, wie z.B.:

6.0.2.5.1.1 Remote Procedure Calls überall
6.0.2.5.1.2 Monolithische Architektur
6.0.2.5.1.3 Unkontrollierte Anwendungs-Nachrichten
6.0.2.5.1.4 Arbeitsverzeichnis im Suchpfad
6.0.2.5.2 Installations-Risiken
usw.

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

Oder eine solche Prozeßtrennung kennt Windows AFAIK nicht: http://www.macmark.de/osx_security.php#process_separation

_DrillSarge]I[

2010-04-06, 20:48:08

Die grundlegenden Designschwächen von Windows kann man nicht so ohne weiteres patchen. OK, da hat MS einiges getan. Einen Zaum drum gezogen - sie sind aber zum Tiel immer noch da. Die schleppt MS mit bzw. baut die im Laufe der Zeit ab.
bitte konkrete beispiele :)
(nicht die "beispiele" von der macseite da)

Gast

2010-04-06, 20:59:16

I[;7954208']bitte konkrete beispiele :)
Oben sind einige geschrieben worden.

(nicht die "beispiele" von der macseite da)
:ugly:
Wieso nicht? Weil dir die Argumente ausgehen? Ansonsten kannst du die ja widerlegen bzw den Autor anschreiben.
Der Autor hat dort zum Teil auch Quellen verlinkt (kannst die ja lesen), wie z.B.
http://www.heise.de/security/meldung/Microsoft-relativiert-Vista-Sicherheitsfunktionen-146509.html
oder die weiße Liste: http://www.macmark.de/blog/osx_blog_2009-03.php#windows_7_whitelist_for_silent_elevation_bypassing_uac
(es ist bekannt, dass UAC auf der nicht höchsten Stufe ziemlich unterwandert werden kann, was auch indirekt einige andere Argumente zum Teil beweist).

Tja, er schreibt alles sehr einseitig, was unklug ist. So kommt es als pures Bashen rüber, auch wenn manches stimmt.

Coda

2010-04-06, 21:00:02

6.0.2.5.1.1 Remote Procedure Calls überall
Das Web ist auch vollständig auf RPC aufgebaut. Auch in Java und .NET Programmen ist das Gang und Gebe und per se auch überhaupt kein Problem.

Du kannst genauso gut mit normalen Sockets innerhalb von weniger Codezeilen Sicherheitslücken aufreißen.

6.0.2.5.1.2 Monolithische Architektur
In dem Paragraph finde ich soviel FUD das ich nicht auf alles eingehen werde.

Ab Vista ist nichts mehr von der Grafik im Kernel. Und zudem gab es dort selbst zu den Anfangszeiten von XP nie Sicherheitslücken. Ich wüsste nicht wo bei Mac OS X der Kernel weniger monolithisch sein soll. XNU basiert ja auf dem Microkernel MACH und einer guten Portion FreeBSD-Code. Das ganze haben sie dann für XNU durch den Mixer gelassen und die Kernel-Trennung in Prozesse entfernt, weil der nicht monolithische Kernel zu lahm war.

Und das der Explorer "untrennbar" mit dem System verwoben ist, ist auch völliger Bullshit. MSHTML wird eben auch von anderen Programmen als Library verwendet und kann deshalb nicht gelöscht werden. Insofern ist Safari nicht mehr oder weniger in mit OS X "verwoben", denn WebKit ist auch eine System-Lib.

6.0.2.5.1.3Unkontrollierte Anwendungs-Nachrichten
Es gibt in Windows die Möglichkeit für Sicherheitsrelevante Prozesse (UAC-Prompt, aber auch Googles Sandbox) in einem separatem Desktop laufen zu lassen um dies zu verhindern.

6.0.2.5.1.4 Arbeitsverzeichnis im Suchpfad
Sehe ich überhaupt nicht als Problem an. Unter OS X könnte man z.B. dafür ohne weiteres ein komplettes Programm als normaler User ersetzen wenn erstmal Schadcode läuft. Das ist in Windows nicht möglich.

6.0.2.5.1.3 Installations-Risiken
Das die Installation bei Mac OS X selber keine Änderungen am System vornehmen kann ändert überhaupt nichts an der Sicherheit. Ob der Dialog dazu nun vom Installer oder beim Ausführen dieses erfolgt ist doch egal.

Kurzum: Der Typ hat nur sehr oberflächlich Ahnung pickt sich aber gezielt Punkte heraus die er meint irgendwie gegen Windows auslegen zu können.

MacMark

2010-04-11, 10:59:54

… Das Web ist auch vollständig auf RPC aufgebaut.…

Das ist völliger Unfug. Das Web ist auf HTTP (Anwendungsprotokoll) über TCP/IP (Transportprotokoll) aufgebaut.

RPC ist ein weiteres Protokoll der Anwendungsebene (analog/parallel zu HTTP, Telnet, FTP, SSH, …). RPC kann über die Transportprotokolle TCP oder UDP laufen. Das Web hat nichts mit RPC zu tun.

Man sollte die Grundlagen schon kennen, wenn man bei Netzwerk- und System-Sicherheit mitreden möchte.

… Kurzum: Der Typ hat nur sehr oberflächlich Ahnung …

Das sagt der Richtige. ;D

Coda

2010-04-11, 14:15:55

Das ist völliger Unfug. Das Web ist auf HTTP (Anwendungsprotokoll) über TCP/IP (Transportprotokoll) aufgebaut.
Nein, das ist kein Unfug. Wenn du eine PHP/ASP/JSP-Seite aufrufst wird eine bestimmte Funktion auf dem Server ausgeführt und eine Antwort zurückgeliefert. Genau das und nichts anderes ist die Definition für RPC.

Siehe http://en.wikipedia.org/wiki/Web_service#Styles_of_use

RPC ist ein weiteres Protokoll der Anwendungsebene (analog/parallel zu HTTP, Telnet, FTP, SSH, …). RPC kann über die Transportprotokolle TCP oder UDP laufen. Das Web hat nichts mit RPC zu tun.
RPC steht für "Remote Procedure Call". Es gibt nicht das RPC-Protokoll. Beispiele sind z.B. ONC RPC (http://en.wikipedia.org/wiki/ONC_RPC), XML-RPC (http://en.wikipedia.org/wiki/XML-RPC) oder Java RMI (http://en.wikipedia.org/wiki/Java_Remote_Method_Invocation).

Ersteres wird in NFS eingesetzt, das auch dein geheiligtes Mac OS X implementiert.

Das sagt der Richtige. ;D
Absolut unterste Schublade. Aber was anderes hätte ich nach der Webseite auch nicht erwartet. (http://en.wikipedia.org/wiki/Crank_(person))

Du kannst uns ja gerne mal im Detail erklären was die gewöhnlichen Sicherheitsprobleme von RPC sind und wie sich das im Vergleich zu Applikationen verhält die einfach nur Sockets verwenden. Zudem würde ich gerne wissen was genau dagegen getan werden kann und in welchen Sprachen welche Probleme dabei auftreten.

Gast

2010-04-11, 16:10:49

Solange es auf OS-X kein DEP gibt erübrigt sich die Diskussion über (Un)sicherheiten von Windows vs. OS-X...

Gast

2010-04-11, 16:11:53

Solange es auf OS-X kein DEP gibt erübrigt sich die Diskussion über (Un)sicherheiten von Windows vs. OS-X...
DEP gibt es unter OSX. Von daher erübrigt sich wohl die Diskussion mit Dir ;)

Marscel

2010-04-11, 16:14:53

Das ist völliger Unfug. Das Web ist auf HTTP (Anwendungsprotokoll) über TCP/IP (Transportprotokoll) aufgebaut.

Unter anderem das, was du normalerweise mit dem Browser benutzt, läuft auf Basis des HTTP. Dem Netz ist das egal, das wird nämlich unter dem IP betrieben. Nur um "Web" nicht durcheinanderzuwürfeln.

RPC ist ein weiteres Protokoll der Anwendungsebene (analog/parallel zu HTTP, Telnet, FTP, SSH, …). RPC kann über die Transportprotokolle TCP oder UDP laufen. Das Web hat nichts mit RPC zu tun.

Nein, es ist eine Funktionsweise. AJAX ist schließlich auch kein Protokoll, sondern die Technik, Javascriptanfragen asynchron vom Nutzerrequest zu tätigen und darauf ne Antwort zu erhalten. Ob das nun in XML, JSON, HTML oder Pipi Langstrumpf ist und wie das entsprechende XML/JSON/... auszusehen, wird NICHT festgelegt.

Wenn du dir anguckst, was alles unter "Remote Prodcedure Calls" fällt, könnte dir auffallen, dass HTTP-Anfragen ebenso darunter fallen. Du als Client stellst ne Anfrage (GET/POST...), hängst Paramter daran und erhälst eine Antwort vom Server der entsprechender deiner Forderung reagiert.

Wenn mein Client-Programm "GET /ivoice.php?id=1234 HTTP/1.1" an den Server sendet, der stinknormal auf Port 80 läuft und ein PHP-Modul hat und mir als Antwort Daten im XML-Format sendet, die ich indivduell strukturiert habe, um dann daraus eine PDF zu erstellen und auszudrucken (ohne dass dabei irgendwie ein Browser im Spiel war), voilà, Beispiel für ein RPC für HTTP. Soweit klar?

Aber da wiederhole ich jetzt eigentlich Coda.

Man sollte die Grundlagen schon kennen, wenn man bei Netzwerk- und System-Sicherheit mitreden möchte.

Dann bitte auch beachten, dass es dem gehijackten Benutzer egal ist, solange Apple es versäumt, seine 88 Lücken rechtzeitig zu patchen aber im Prinzip ja total sicher sei. Denn solange hat Microsoft auch seine Berechtigung, effektive Flickenschusterei auf unsicheres Design zu betreiben.

MacMark

2010-04-11, 17:46:47

Windows verwendet RPC intern zu oft. Lokale Kommunikation über Remote-Protokolle ist unnötiges Risiko. Viele Windows-Programme verwenden RPC ohne wirklich Netzfunktionalität zu brauchen. Das wird durch die MS-Dev-Tools noch forciert. Der massive Einsatz von RPC auf Windows macht es unnötig per Netz angreifbar.

Es geht um das RPC, das sämtliche RPC-Würmer für Windows so dankbar nutzen. Dummerweise kann RPC in Windows nicht abgeschaltet werden, dann startet Windows nicht mehr. Man kann den Programmen auch nicht RPC nachträglich rausschneiden. Also muß Plan B her: Eine Firewall, die alle offenen Ports sperrt, die irgendwelche RPC-Programme auf Windows offen haben. Ohne Firewall ist Windows ein Einfallstor für Remote-Angriffe, bei denen der Benutzer nicht mithelfen muß.

Eure HTTP-Kommunikation ist kein RPC. (Vergleichbar zu RPC ist allenfalls etwas wie Javas RMI und darauf aufbauende Frameworks.) Der RPC-Portmapper läuft auf Port 111 TCP und UDP und nennt RPC-Anfragen den jeweiligen dynamischen Port der gesuchten RPC-Anwendung. Dann kommuniziert der RPC-Client direkt mit dem RPC-Server über den genannten Port. Der RPC-Portmapper ist nötig, weil es nicht genug Ports gibt, um allen Kombinationen aus RPC-Programmen und deren Versionen einen festen Port zu geben.

Ende der Geschichte ist, daß Windows-User sich ein Leben ohne Firewall (oder NAT-Router) nicht mehr vorstellen können. Auf Unix-Systemen laufen auch ohne Firewall keine (oder keine unerwünschten) RPC-Ports.

Coda

2010-04-11, 17:56:56

Windows verwendet RPC intern zu oft. Lokale Kommunikation über Remote-Protokolle ist unnötiges Risiko. Viele Windows-Programme verwenden RPC ohne wirklich Netzfunktionalität zu brauchen. Das wird durch die MS-Dev-Tools noch forciert. Der massive Einsatz von RPC auf Windows macht es unnötig per Netz angreifbar.
Was genau ist an RPC besser oder schlechter was den Sicherheitsaspekt angeht als an einer Socket-Kommunikation?

Diese Frage bist du uns bis jetzt schuldig geblieben. Und ich vermute auch mal, dass du sie gar nicht beantworten kannst.

Eure HTTP-Kommunikation ist kein RPC. (Vergleichbar zu RPC ist allenfalls etwas wie Javas RMI und darauf aufbauende Frameworks.) Der RPC-Portmapper läuft auf Port 111 TCP und UDP und nennt RPC-Anfragen den jeweiligen dynamischen Port der gesuchten RPC-Anwendung. Dann kommuniziert der RPC-Client direkt mit dem RPC-Server über den genannten Port. Der RPC-Portmapper ist nötig, weil es nicht genug Ports gibt, um allen Kombinationen aus RPC-Programmen und deren Versionen einen festen Port zu geben.
Port 111 ist "sunrpc" für NFS (ONC RPC), das wird von Windows überhaupt nicht verwendet. Das ist eine reine Unix-Geschichte für NFS.

Und nochmal: Es gibt nicht das RPC. Begreif es endlich. Microsoft verwendet DCE/RPC (http://en.wikipedia.org/wiki/DCE/RPC) alias MSRPC (http://en.wikipedia.org/wiki/MSRPC). Das hat nichts mit sunrpc auf Port 111 zu tun.

Und das du behauptest dass es RPC-Webservices über HTTP nicht gibt zeigt mir abermals, dass du nicht verstanden hast was RPC überhaupt macht.

MacMark

2010-04-11, 18:09:20

Ich kann schon, aber Du stellst die falschen Fragen, die Dich nicht weiterbringen.

Es gibt diverse Mechanismen, um Programme miteinander kommunizieren zu lassen (IPC). Es gibt lokale IPC-Mechanismen und remote IPC-Mechanismen. Windows und seine Programme verwenden für lokale Kommunikation jedoch häufig einen Remote-IPC-Mechanismus: RPC.

RPC und Sockets sind beides Remote-IPC-Mechanismen. Deren Verwendung ist okay, solange man damit keine lokale Kommunikation umsetzt. Denn damit eröffnet man dann einen unnötigen remote Angriffspunkt. Und das ist einer der heftigsten Architekturfehler, die Windows begeht: An Stellen, wo local IPC ausreichen würde, remote IPC (Windows RPC) zu nutzen.

Edits:

Welchen Port Microsoft für sein RPC-Mapping verwendet, ist letztendlich egal. Laß es dort 135 sein. Die Funktionsweise ist die gleiche wie ich beschrieben habe oben.
"Microsoft TechNet: The Danger of Exposing RPC to the Internet"
http://technet.microsoft.com/en-us/library/cc751166.aspx#XSLTsection124121120120

Soap und XML-RPC sind kein klassisches RPC. Und kein Thema hier, weil Windows diese für lokale Kommunikation nicht nutzt.

Coda

2010-04-11, 18:15:40

Welche lokalen Dienste sollen das genau sein? Und genau was davon ist seit spätestens Windows XP SP2 nicht komplett nach außen zugeschnürt?

Womit wir zu diesem Punkt kommen:

Das wird durch die MS-Dev-Tools noch forciert.
Wird es nicht. Schon ewig nicht mehr.

Du weichst zudem aus. Zuerst war es RPC an sich was schlimm sein soll, und jetzt auf einmal nur noch dass es auch lokal Verwendung findet.

MacMark

2010-04-11, 19:23:51

Lies mich genauer. Es geht mir immer um den Fehleinsatz von RPC.

Mit der Windows-Version wurde die Firewall eingeführt meines Wissens, ja. Ist aber ein Notbehelf, weil Windows aufgrund der RPCs sonst Toast ist. Wie oben beschrieben. Und wie von Microsoft beschrieben. Link ebenfalls wie oben:
"Microsoft TechNet: The Danger of Exposing RPC to the Internet"
http://technet.microsoft.com/en-us/library/cc751166.aspx#XSLTsection124121120120
Die Firewall darf diesen Architekturfehler deckeln.

Falls Du mit "lokale Dienste" lokale IPC meinst, dann blättere mal hier bis Interprocess Communication runter:
"Microsoft TechNet: Functional Comparison of UNIX and Windows"
http://technet.microsoft.com/en-us/library/bb496993.aspx#EAAA
Sie nennen nicht alle, aber ein paar wichtige. Wissen also schon, daß es auch anders geht. Aber die Erkenntnis kommt zu spät. Windows ohne RPC geht nicht.

Falls Du meinst, welche RPC-Dienste das sind: Jedes (System- oder Anwendungs-) Programm von Microsoft oder Dritten, das RPC zur Kommunikation anbietet.
Der Portmapper (auf 135 oder 111) dient nur als Info und nennt dann den passenden RPC-Port des Dienstes, siehe:
"Microsoft TechNet: An Example of RPC Client-Server Communications"
http://technet.microsoft.com/en-us/library/cc751166.aspx#XSLTsection123121120120
Die RPC-Dienste des Rechners laufen jedoch auf dynamisch vergebenen Ports, über die der Portmapper informiert. Die Firewall macht also besser alles zu.
Diese RPC-Problematik gibt es auf OS X und UNIX allgemein nicht. Probier mal ein "rpcinfo -p".

Coda

2010-04-12, 16:20:41

Und ich sage, dass das kein Problem von RPC ist, sondern einfach Sicherheitslücken die sich remote ausnutzen lassen. Wenn die Dienste für ein Socket-Protokoll implementiert hätten wären sie bei Fehlern darin genauso verwundbar.

Windows Vista und 7 sind auch ohne Firewall "nicht Toast". Die RPC-Lücken wurden alle geschlossen. Da steht nur dass es potentiell problematisch ist. Genauso ist es potentiell problematisch alle Socket-Ports offen zu lassen.

Es ist was Sicherheit angeht völlig egal wie etwas gegenüber dem Netz zur Verfügung gestellt wird. Es kommt drauf an ob es ausnutzbare Fehler hat oder nicht.

Falls Du mit "lokale Dienste" lokale IPC meinst, dann blättere mal hier bis Interprocess Communication runter:
"Microsoft TechNet: Functional Comparison of UNIX and Windows"
http://technet.microsoft.com/en-us/library/bb496993.aspx#EAAA
Sie nennen nicht alle, aber ein paar wichtige. Wissen also schon, daß es auch anders geht. Aber die Erkenntnis kommt zu spät. Windows ohne RPC geht nicht.
Du hast immer noch nicht einen lokalen Dienst genannt der unbedingt RPC braucht um zu funktionieren und diesen auch nach außen zur Verfügung stellt.

Ich gehe nämlich mal stark davon aus, dass da das allermeiste über RPC/NP also Named Pipes geht und damit remote überhaupt nicht ausnutzbar ist. Und auch lokal braucht man erstmal entsprechende Authentifizierung mit dem Endpoint um überhaupt was aufrufen zu können.

Wenn überhaupt etwas problematisch ist an dem RPC-Kram, dann die unglaubliche Komplexität der Konfigurations-Interfaces die darüber laufen. Das ist aber nunmal einer der Verkaufspunkte von Windows Server.

Gast

2010-04-13, 09:17:26

MacMark

2010-04-16, 18:49:27

Coda,
das Grundproblem ist, daß in vielen Fällen Netzwerkzugriff angeboten wird, obwohl dieser nicht benötigt wird. Ob das durch RPC oder Sockets passiert, ist dabei prinzipiell egal. Bei Windows ist RPC jedoch mit fast flächendeckender Verbreitung im Einsatz, so daß viel unnötiger Netzzugriff angeboten wird mittels RPC.

Dieser übertriebene RPC-Einsatz ist nicht nur problematisch durch vergangene Fehler im RPC-Dienst selbst, sondern vor allem deshalb, weil ein ansonsten nur lokal ausnutzbarer Bug in RPC-Programmen dadurch per Netz ausgenutzt werden kann. Das ist ärgerlich, weil die meisten dieser Programme RPC gar nicht bräuchten und sich somit unnötig im Netz exponieren. Darum nutzt Windows eine Firewall, die diesen nicht sinnvollen Netzzugriff verhindert.

Du wolltest wissen, welche der Windows-Dienste RPC benötigen. Ich frage mich eher: Welche nicht? Denn es sind fast alle, und zwar:

Network Location Awareness, IP Helper, Performance Logs & Alerts, Internet Connection Sharing (ICS), Base Filtering System, Windows Connect Now - Config Registrar, Microsoft Software Shadow Copy Provider, Windows Installer, Windows Firewall, Extensible Authentication Protocol, Remote Access Auto Connection Manager, Windows Media Center Receiver Service, Parental Controls, Protected Storage, Tablet PC Input Service, Windows Management Instrumentation, Windows Audio, DFS Replication, COM+ Event System, Quality Windows Audio Video Experience, Security Accounts Manager, System Event Notification Service, Wired AutoConfig, Offline Files, Routing and Remote Access, Fax , Group Policy Client, Windows Media Center Scheduler Service, IKE and AuthIP Ipsec Keying Modules, SL UI Notification Service, Windows Defender, Software Licensing, Security Center, Telephony, Server, Function Discovery Resource Publication, Terminal Services UserMode Port Redirector, PnP-X IP Bus Enumerator, Windows Backup, WLAN AutoConfig, Network List Service, Volume Shadow Copy, Superfetch, Windows Search, Remote Registry, Certificate Propagation, CNG Key Isolation, Shell Hardware Detection, Background Intelligent Transfer Service, Computer Browser, Health Key and Certificate Management, Windows Color System, Windows Update, COM+ System Application, Link-Layer Topology Discovery Mapper, Network Access Protection Agent, Distributed Transaction Coordinator, Program Compatibility Assistant Service, Windows Remote Management (WS-Management), Windows Media Center Extender Service, Windows Media Center Service Launcher, IPsec Policy Agent, Smart Card Removal Policy, Function Discovery Provider Host, ReadyBoost, Application Information, Terminal Services, Virtual Disk, Network Connections, Task Scheduler, Windows Image Acquisition (WIA), Cryptographic Services, Print Spooler, Distributed Link Tracking Client, User Profile Service, KtmRm for Distributed Transaction Coordinator, Portable Device Enumerator Service, Terminal Services Configuration.

Das Hauptproblem sind jedoch nicht mal die Windows-Dienste, sondern die Anwendungsprogramme, die nach Laune RPC mißbrauchen, so wie "Gast" im Beitrag drüber dazu neigt, indem er sagt: "Sobald Interprozesskommunikation stattfindet, ist RPC nun mal nötig."

Und nein, "Gast", für Interprozeßkommunikation ist kein RPC nötig. Solch eine fatale Überzeugung ist mit die Ursache für das RPC-Desaster auf Windows: Sämtliche verheerenden Windows-Würmer waren RPC-Würmer.

Coda wollte weiter oben noch wissen: "Was genau soll denn am OS-X-Systemdesign noch viel sicherer sein als von Vista und 7 mit UAC?" Alles, denn UAC ist vom Konzept her schon unsicher und ist laut MS noch nicht mal ein Sicherheitsmechanismus. Details habe ich hier beschrieben:
http://www.macmark.de/blog/osx_blog_2009-01.php#windows_7_uac_broken_by_design
http://www.macmark.de/blog/osx_blog_2009-03.php#windows_7_whitelist_for_silent_elevation_bypassing_uac

Gast

2010-04-17, 01:08:20

Die Experten sagen ja schon nicht umsonst seit Monaten, für eine hoche Sicherheit sollte man unter Win7 genauso wie schon davor unter XP den eingeschränkten Benutzer auch wirklich nutzen.

Schnelle Benutzerumschaltung erleichtert das Leben, falls man schnell etwas installieren will.

Und wenn ich unter Win7-64 mit dem Eingeschränkten fahre, dann komm und Hack mich doch mal oder hetz mir irgendeine chinesische Meute an den Hals. Oder bewirf mich mit Links zu präparierten Seiten.

Coda

2010-04-17, 15:57:05

Dieser übertriebene RPC-Einsatz ist nicht nur problematisch durch vergangene Fehler im RPC-Dienst selbst, sondern vor allem deshalb, weil ein ansonsten nur lokal ausnutzbarer Bug in RPC-Programmen dadurch per Netz ausgenutzt werden kann.
Dafür bist du mir immer noch ein Beispiel schuldig. RPC-Dienste das nur lokal gebraucht wird für IPC werden natürlich auch nicht ins Netz exponiert.

Du wolltest wissen, welche der Windows-Dienste RPC benötigen. Ich frage mich eher: Welche nicht? Denn es sind fast alle, und zwar:
Und du raffst immer noch nicht, dass man davon nur einen Bruchteil von außen überhaupt ansprechen kann. RPC läuft lokal auch nicht über TCP/IP sondern über Named Pipes.

Coda wollte weiter oben noch wissen: "Was genau soll denn am OS-X-Systemdesign noch viel sicherer sein als von Vista und 7 mit UAC?" Alles, denn UAC ist vom Konzept her schon unsicher und ist laut MS noch nicht mal ein Sicherheitsmechanismus. Details habe ich hier beschrieben:
Was soll an einem UAC-Prompt unsicherer sein als an einer Passwort-Maske? Beides hebt die Rechte des eingeschränkten Admin-Benutzers auf volle Admin-Rechte (ja auch OS X legt standardmäßig einen Superuser-Account an). Es gibt technisch keinerlei Unterschiede. UAC ist nicht "vom Konzept her unsicher". Falls es das wäre, wäre es der Passwort-Prompt von OS X genauso.

Bei OS X läuft der Passwort-Prompt anscheinend nichtmal in einem abgeschotteten Desktop, so dass man es mitloggen kann als andere App. Nur weil derzeit keiner so versucht OS X aufzumachen heißt es noch lange nicht, dass da alles eine Sicherheits-Blumenwiese wäre.

Und das UAC-Problem von Windows 7 ist in der Final behoben worden. (http://www.istartedsomething.com/20090206/microsoft-changes-windows-7-uac-control/) Du verbreitest wie gehabt FUD.

MacMark

2010-04-17, 19:28:01

Die UAC ist weiterhin broken by design dank der Whitelist:
http://www.macmark.de/blog/osx_blog_2009-03.php#windows_7_whitelist_for_silent_elevation_bypassing_uac
Im Grunde völlig wertlos also.

Die Paßwort-Eingabe erfolgt bei OS X in einem Dialog des Security-Agenten. Steht alles auf meiner Seite:
http://www.macmark.de/osx_security.php#security_server

RPC ist ein Application-Level-Protokoll, kein Transport-Protokoll. Der Transport wird je nach Lage von Client und Server passend von der RPC-Runtime-Library dynamisch gewählt. Das ist dann nach Bedarf ein lokaler Transport oder ein Netztransport. RPC hat da diverse Varianten zur Verfügung. Wenn der Client auf dem selben Host läuft, nimmt die RPC-Runtime-Lib ein lokales Transport-Protokoll, läuft der Client auf einem anderen Host, wählt die RPC-Runtime-Lib ein Netz-Transport-Protokoll.
Die angebotenen RPCs werden am RPC-Endpoint-Mapper registriert und dort von Clients abgefragt. Bei meiner Vista-Test-Installation sehe ich dort 137 registrierte RPC-Endpoints.

iDiot

2010-04-18, 10:10:39

Gehst du eigentlich immer von der DAU- Konfig bei Windows aus?
Also als "quasi-admin" unterwegs sein?

Demirug

2010-04-18, 10:54:44

RPC ist ein Application-Level-Protokoll, kein Transport-Protokoll. Der Transport wird je nach Lage von Client und Server passend von der RPC-Runtime-Library dynamisch gewählt. Das ist dann nach Bedarf ein lokaler Transport oder ein Netztransport. RPC hat da diverse Varianten zur Verfügung. Wenn der Client auf dem selben Host läuft, nimmt die RPC-Runtime-Lib ein lokales Transport-Protokoll, läuft der Client auf einem anderen Host, wählt die RPC-Runtime-Lib ein Netz-Transport-Protokoll.
Die angebotenen RPCs werden am RPC-Endpoint-Mapper registriert und dort von Clients abgefragt. Bei meiner Vista-Test-Installation sehe ich dort 137 registrierte RPC-Endpoints.

Das ist nicht ganz korrekt. Ein RPC Server registriert die Endpunkte die er unterstützen will beim RPC Dienst. Ein solcher Endpunkt enthält sowohl das Protokoll wie auch einen eindeutigen Bezeichner. Registriert ein RPC Server nur Endpunkte für den lokalen Zugang (ncalrpc) ist ein Zugang über das Netzwerk nicht möglich. Ein Security Problem gibt es dabei allerdings wirklich. Die Endpunkte werden für den Prozess und nicht für einen spezifischen Server registriert. Lädt man mehrere RPC Server in den gleichen Prozess so sind alle diese Server theoretisch über alle registrierten Endpunkte zugänglich. Das ist ein Problem welches aus der DCE Vergangenheit der RPC Spezifikation kommt.

In der Praxis lädt man aber zum einen keine Dienste mit unterschiedlicher Reichweite in den gleichen Prozess. Zudem sollte jeder RPC Dienst eine weitere Sicherung enthalten. Diese prüft bei jedem Aufruf den Sicherheitscontext. Zu dieser Prüfung gehört auch der Endpunkt über den der Aufruf gekommen ist.

Gast

2010-04-18, 11:25:05

[off topic]
Grundsätzlich gefällt mit Chrome 5 super - gerade auch unter OS X. Allerdings hat Chrome 5 schon das ein oder andere mal etwas geschafft, das ich sonst noch nicht unter OSX gesehen habe: Das ganze System runtergerissen.
Es erscheint dann eine Meldung, dass man den Rechner neu starten soll. :ugly:
Kam zwar nur selten vor aber das es überhaupt passiert.

[/off topic]

Gast

2010-04-18, 12:21:30

Gehst du eigentlich immer von der DAU- Konfig bei Windows aus?
Also als "quasi-admin" unterwegs sein?Meinst du prozentual die real laufenden Installationen oder die praktischen Möglichkeiten? ;)

MacMark

2010-04-18, 15:52:30

… Registriert ein RPC Server nur Endpunkte für den lokalen Zugang (ncalrpc) ist ein Zugang über das Netzwerk nicht möglich. …
Das sieht Microsoft anders.
http://msdn.microsoft.com/en-us/library/aa373774(v=VS.85).aspx

Gast

2010-04-18, 17:05:16

Das sieht Microsoft anders.
http://msdn.microsoft.com/en-us/library/aa373774(v=VS.85).aspx

Was sieht da Microsoft anders? Dort steht doch genau dasselbe, was Demirug gesagt hat. Was im obigen Text steht, sagt nur, dass man Security Descriptoren zur Sicherung der RPC Endpunkte vermeiden soll, weil damit keine effektive Sicherheit exisitert.

Demirug

2010-04-18, 17:08:32

Das sieht Microsoft anders.
http://msdn.microsoft.com/en-us/library/aa373774(v=VS.85).aspx

Kann es sein das du nicht verstanden hast was du da gelesen hast?

In dem Abschnitt geht es um den SecurityDescriptor Parameter der RpcServerUseProtseq Funktion. Über welche Schnittstellen ein RPC Server erreichbar ist wird aber durch den ProtSeq Parameter festgelegt. Ein Prozess der hier nur ncalrpc verwendet ist nicht über tcp oder ein anderes Netzwerk Protokoll erreichbar.

MacMark

2010-04-18, 18:31:04

Vielleicht folgst Du auch noch dem Link gegen Ende des verlinkten Artikels.

Demirug

2010-04-18, 19:08:06

Keine Sorge ich kenne die ganze RPC Dokumentation da ich mich damit auch beruflich zu tun habe.

Der entsprechende Abschnitt beschreibt nichts anderes als das was ich in meinem ersten Post bereits erwähnt habe. Mischt man im gleichen Prozess Netzwerk und lokale Dienste baut man sich ein potenzielles Sicherheitsloch. Das tut man aber auch unabhängig von RPC da es allgemein als schwere Sicherheitssünde gilt Netzwerk und lokale Dienste in einem gemeinsamen Prozess laufen zu lassen. Damit dies aber in Verbindung mit RPC wirklich zu einem Sicherheitsproblem wird muss man noch zusätzlich gegen die Regel verstoßen das man bei jedem externen Aufruf (egal ob lokal oder übers Netzwerk) den Sicherheitskontext prüfen soll.

MacMark

2010-04-18, 19:17:09

Sicher wäre, für lokale Kommunikation gar kein RPC zu nutzen.

Nachtrag:

… da es allgemein als schwere Sicherheitssünde gilt Netzwerk und lokale Dienste in einem gemeinsamen Prozess laufen zu lassen. …

Korrekt. Ein wunderschönes Negativbeispiel wurde ausgenutzt durch den Wurm "SQL-Slammer": Die SQL Server Engine, die Netzfunktion enthält, wird in Desktop-Apps eingesetzt. Und das ist von Microsoft so gewünscht. Ein Bug in der Engine war dann damals in hunderten Desktop-Apps remote ausnutzbar.
Wollen wir noch raten, was passiert, wenn diese Server Engine demnächst in WinFS verwendet werden wird?

Coda

2010-04-18, 21:03:52

Sicher wäre, für lokale Kommunikation gar kein RPC zu nutzen.
Ach und wieso, wenn man diese überhaupt nicht über TCP zulässt? Diese Frage hast du uns immer noch nicht beantwortet, sondern redest nur drumrum.

Wie ich IPC über eine lokale named pipe mache (ob direkt oder über irgend eine Abstraktion wie RPC) ist für die Sicherheit völlig egal. Genauso ist es für die Sicherheit völlig egal ob ich die Netzkommunikation über RPC oder Sockets mache. Und es ist auch schlecht IPC und Sockets in einem Prozess zu mischen - das ist genauso wenig auf RPC beschränkt.

Du versuchst hier allgemeine Designfehler von RPC zu konsturieren, die es schlicht und einfach nicht gibt.

Gast

2010-04-19, 05:37:37

Wollen wir noch raten, was passiert, wenn diese Server Engine demnächst in WinFS verwendet werden wird?Nein müßen wir nicht. WinFS nutzt einen Kastrat davon der keine Netzfunktion hat.

Natürlich stellte sich MS diese Frage nicht :crazy2:

Gast

2010-04-19, 05:45:25

Darum nutzt Windows eine Firewall, die diesen nicht sinnvollen Netzzugriff verhindert.Worauf Apple natürlich seit Tiger verzichtet :ulol:

Nein warte, seit Leopard. Da ist das nämlich kein Paketfilter mehr, sondern eine Art Codesign Dienst. Und ist per default aus. Was auch gut ist, weil man damit sonst immernoch eine Programmintegrität beschädigen kann.

DAS ist Sicherheit :uup:

iDiot

2010-04-19, 11:04:57

Meinst du prozentual die real laufenden Installationen oder die praktischen Möglichkeiten? ;)

Das was für mich relevant ist. Was interessieren mich noobs :tongue:

Ganon

2010-04-19, 12:03:28

Was auch gut ist, weil man damit sonst immernoch eine Programmintegrität beschädigen kann.

Das ist Käse, gar nichts wird dadurch beschädigt. OS X signiert nur alle vom Benutzer bestätigen Programme, sofern sie nicht signiert sind.

Das Problem damals war nur, dass Spiele wie WoW das Binary selbst noch mal geprüft haben, und dabei ja nunmal die Signatur von OS X dabei war.

Der ganze Signierungsablauf hat mit der FireWall selbst nichts zu tun, die FireWall nutzt diese nur zusätzlich.

Gast

2010-04-19, 13:19:05

Das was für mich relevant ist. Was interessieren mich noobs :tongue:Du bist aber nicht das Threadthema ;)

Gast

2010-04-19, 13:21:45

Der ganze Signierungsablauf hat mit der FireWall selbst nichts zu tun, die FireWall nutzt diese nur zusätzlich.Wenn man sie anmacht. Ich denke bei der mittlerweile brauchbaren Verbreitung und dieser ewig übergroßen Klappe wird es langsam Zeit OSX auf den löchrigen Zahn zu fühlen.

Freut euch drauf ;)

Ganon

2010-04-19, 14:01:48

Wenn man sie anmacht. Ich denke bei der mittlerweile brauchbaren Verbreitung und dieser ewig übergroßen Klappe wird es langsam Zeit OSX auf den löchrigen Zahn zu fühlen.

Die wenigsten Sicherheitslücken in OS X könnte die FireWall überhaupt blockieren. Afaik stecken alle Standard-Dienste, die Kommunikation nach außen erlauben, in einer Sandbox (z.B. ntpd).

Die meisten Sicherheitslöcher in OS X kommen durch manipulierte Daten die per Mail oder Safari eintrudeln und dann in Webkit/QuickTime/Imagelibs stecken. Das ist schon längst hinter der FireWall.

Darum ist das Teil auch standardmäßig aus. Die Programmsignierung läuft immer.

Coda

2010-04-19, 17:42:49

Wenn man sie anmacht. Ich denke bei der mittlerweile brauchbaren Verbreitung und dieser ewig übergroßen Klappe wird es langsam Zeit OSX auf den löchrigen Zahn zu fühlen.

Freut euch drauf ;)
Das siehst nicht nur du so:
http://blog.fefe.de/?ts=b54caa44

Ich bin da auch mal gespannt darauf. Könnte einige blöde Gesichter zur Folge haben.

MacMark

2010-04-19, 19:00:14

… wenn man diese überhaupt nicht über TCP zulässt? … Du versuchst hier allgemeine Designfehler von RPC zu konsturieren, die es schlicht und einfach nicht gibt.

Auch ein nacktes Vista hat einige RPC-Dienste für TCP laufen. Schau selbst nach. Aber darum geht es mir gar nicht.

Es geht um den Fehleinsatz von RPC, nicht um die Existenz an sich.

… da ich mich damit auch beruflich zu tun habe.…
Mein Beileid.

… WinFS nutzt einen Kastrat davon der keine Netzfunktion hat. …
Das sehen wir dann, wenn es kommt.

… seit Leopard. Da ist das nämlich kein Paketfilter mehr, sondern eine Art Codesign Dienst. …
"Ich mach mir die Welt, Wi di wi di wie sie mir gefällt." - oder was?
Leopard hat die ipfw wie die älteren OS X-Versionen und zusätzlich eine Application-Level-Firewall:
http://www.macmark.de/osx_security.php#firewall
http://www.macmark.de/osx_skype.php

Coda

2010-04-19, 19:06:14

Auch ein nacktes Vista hat einige RPC-Dienste für TCP laufen. Schau selbst nach. Aber darum geht es mir gar nicht.
Ja, für die es sinnvoll ist.

Es geht um den Fehleinsatz von RPC, nicht um die Existenz an sich.
Nach außen ist es ganz bestimmt kein "Fehleinsatz" und für lokale IPC ist RPC auch eine sehr hilfreiche Sache.

Und vor allem nicht unsicherer als manuell den Named-Pipe-Strom zu parsen. Das ist nämlich in C/C++ nicht so ohne weiteres sicher möglich.

Ganon

2010-04-19, 23:47:52

Das siehst nicht nur du so:
http://blog.fefe.de/?ts=b54caa44

Ich bin da auch mal gespannt darauf. Könnte einige blöde Gesichter zur Folge haben.

Wobei die Zahl sich ziemlich schnell relativiert, wenn man Sachen von "OS X Server" raus nimmt und dann auch noch die Zeit betrachtet der zwischen 10.6.2 und 10.6.3 verstrichen ist. Und dann ist die Summe auch noch aus 10.5 und 10.6 zusammen und nicht nur 10.6 alleine.

Sammelt ja auch keiner die Sicherheitsfixes aller "Linux-Libs" über einen Zeitraum. Denn viele Lücken stammen aus bekannten fixes in den OpenSource-Libs (Perl, PHP, curl, cups, xorg, libpng, apache, clamav etc.). D.h. Linux etc. hatte die Lücke auch.

D.h. wenn mal die OpenSource-Welt mal einen riesen Patch-Aufwand betreibt und 1000 Sicherheitslücken fixt, dann ist das im Endeffekt nicht nur Apples schuld, dass die Lücken da waren, obwohl es dann gerne allgemein so hingestellt wird.

Wie immer übertreibt fefe auch hier gerne mal wieder. Ist teils sehr parteiisch der Junge ;)

Ich will damit nicht den Kern der Aussage abstreiten und mir ist klar, dass Apple mehr in Sicherheit "investieren" muss. Aber man kann es auch übertreiben, mit den unheilvollen Ankündigungen. Bisher ist keine Lücke dabei, die ohne zutun des Nutzers wirksam ist. Meist muss dann entweder OS X Server laufen, oder ein Dienst muss angeschaltet werden, oder es muss eine manipulierte Datei geöffnet werden.

Coda

2010-04-20, 00:11:58

Sammelt ja auch keiner die Sicherheitsfixes aller "Linux-Libs" über einen Zeitraum.
Dürfte Größtenteils auch nicht viel besser aussehen. Open Source hat meiner Meinung nach mitnichten automatisch einen Sicherheitsheitsbonus. Über PHP kann man echt nur den Kopf schütteln z.B., auch wenn ich es teilweise einsetzen (muss).

Linux hat den Vorteil, dass die einzigen lohnenden Angriffsziele Server sind, d.h. es gibt keinen der mit den Kisten im Web surft oder großartig Client-Side-Programme verwendet. Und die Serverdienste (Apache etc.) haben sie schon relativ gut zugezogen.

Btw. glaube ich nichtmal, dass Fefe meint, dass bei Linux alles Friede-Freude-Eierkuchen ist. Dafür kennt er sich zu gut aus.

Bisher ist keine Lücke dabei, die ohne zutun des Nutzers wirksam ist. Meist muss dann entweder OS X Server laufen, oder ein Dienst muss angeschaltet werden, oder es muss eine manipulierte Datei geöffnet werden.
Es gibt mehr als genügend 0-Days für Safari (bzw. WebKit), und ein anderes Einfallstor braucht man nicht.

Hat Apple aber anscheinend gerafft und macht es gleich richtig in "WebKit 2" - wie Chrome. Sandbox drumrum. Bleibe aber gewiss noch genügend andere Dinge übrig die offen sind wie Scheunentor.

Gast

2010-04-20, 00:24:01

Bleibe aber gewiss noch genügend andere Dinge übrig die offen sind wie Scheunentor.
Ich habe allerdings den Eindruck, dass Apple das Thema "Sicherheitslücken" allmählich anfängt ernster zu nehmen. Es wurden in den letzten Monaten auch der ein oder andere Sicherheitsexperte eingestellt.

Coda

2010-04-20, 00:27:45

Sollten sie auch. Langsam haben sie wirklich genügend Marktanteil um lohnende Ziele zu sein.

(del)

2010-04-20, 01:32:36

Das sehen wir dann, wenn es kommt.Dann mach eine Story draus, wenn es soweit ist :|

Die Liste bei fefe ist leider doch recht lustig.
Die ersten echten Schlägereien haben sie noch vor sich. Schicke Klamotten zu tragen und fein duften nützt in der dunklen Gasse nichts.

MacMark

2010-04-20, 18:55:03

… für lokale IPC ist RPC auch eine sehr hilfreiche Sache. …
Besonders "hilfreich" war das damals für den SQL-Slammer.

Es kommt nicht auf die Anzahl, sondern auf die Schwere der Bugs an. Allein der Bug für den Conficker war gefährlicher als alle Bugs für OS X in 10 Jahren zusammen.
http://www.macmark.de/osx_security.php#fehlerarten
http://www.macmark.de/osx_security.php#design_fehler_schwer_behebbar

Geringer Marktanteil hat noch nie geschützt.
http://www.macmark.de/osx_security.php#scheinargument_marktanteil

Der Sicherheitsbonus von Open Source liegt im leichteren und schnellerem Fixen von Fehlern. Zur Not eigenhändig. Oder durch einen Patch von Dritten ungleich dem Original-Autor.

Coda

2010-04-20, 20:00:11

Besonders "hilfreich" war das damals für den SQL-Slammer.
Ja und? Die Sicherheitslücken hätten genauso gut in Socket-Code oder dem Parsing des IPC-Stroms aus einer Named Pipe sein können. Schlechter Code hat nichts mit RPC zu tun. Raff es endlich.

Du kannst die Links auf deine Seite übrigens bleiben lassen, die nimmt als Quelle hier sowieso niemand mehr ernst.

Der Sicherheitsbonus von Open Source liegt im leichteren und schnellerem Fixen von Fehlern. Zur Not eigenhändig. Oder durch einen Patch von Dritten ungleich dem Original-Autor.
Macht nur niemand.

Oder es passieren auch solche Sachen: http://digitaloffense.net/tools/debian-openssl/ :facepalm:
Die andere Seite der Medaille ist nämlich, dass jeder Depp Code-Maintainer sein kann.

steve.it

2010-04-28, 00:23:09

Sollten sie auch. Langsam haben sie wirklich genügend Marktanteil um lohnende Ziele zu sein.

John Callas (http://www.esecurityplanet.com/headlines/article.php/3878241/PGP-Co-Founder-Takes-Apple-Security-Job.htm) (PGP Mitbegründer) ist jetzt bei Apple, nachdem u.a. Window Snyder angeworben wurde.
Offenbar nimmt Apple auch das Thema "Sicherheit" allmählich ernst(er).

Gast

2010-04-28, 00:33:45

Ja sicher. Die wissen doch wieviel sie nachzuholen haben. Sie nehmen NUN das Thema ernst. Ungefähr da wo man bei MS nach XPsp1 endgültig das Schrillen der Glocken wahr nahm.

Coda

2010-04-28, 04:07:49

John Callas (http://www.esecurityplanet.com/headlines/article.php/3878241/PGP-Co-Founder-Takes-Apple-Security-Job.htm) (PGP Mitbegründer) ist jetzt bei Apple, nachdem u.a. Window Snyder angeworben wurde.
Offenbar nimmt Apple auch das Thema "Sicherheit" allmählich ernst(er).
Krypto hat aber nichts direkt mit Anwendungssicherheit zu tun.

/dev/NULL

2010-04-28, 09:51:40

Ich freu mich immer wieder wenn man sieht wie verblendet Fanboys sein können. Schreiben sich nen Wolf um ihre eigenen Ansichten zu untermauern und sind absolut unfähig eine andere Position auch nur in Erwägung zu ziehen.

Mußte mich spontan an http://www.spiegel.de/spiegel/0,1518,689588,00.html erinnern.

Mir ist es im Endeffekt egal, ob Windows Broken by Design ist und Apple so viel besser designed wurde.
Es ist doch so, dass Apple genauso Sicherheitslücken stopfen muß wie jeder andere Softwarehersteller auch und zZ tut sich Apple da wie auch M$ nicht hervor was die Geschwindigkeit angeht.

Ich habe seit Windows 3.1 Windows (aktuell XP) und einen Server der seit 10 Jahren mit diversen Debian Installationen lief, OS X kenne ich bgislang nicht (zu teuer). Ich hatte weder nen SQL Slammer, noch einen anderen Wurm/Virus oder Einbruch. Folglich ist für mich Windows ausreichend sicher, aber ich klick auch nicht auf jeden Scheiss.

Dieses fanatische geflame von Mac/NVidia/ATI/Windows Usern geht mir aber immer auf die Eier. Leben und Leben lassen.