Da sieht man mal wie verschroben so manche Statistik sein kann. Firefox gehört natürlich trotz der vielen Lücken zu den sichereren Browsern.

Ist doch logisch, dass man bei einem Open Source Produkt mehr Lücken findet. Das Schließen selbiger macht das Produkt aber umso sicherer. Das ist als ob ich sage, der Mann, der öfter zum Arzt geht ist ungesünder, weil er öfter behandelt werden muss...

ja, firefox zählt noch zu den besten in seiner kategorie.Ich glaube die community meldet auch jeden bug und nicht wie bei windows dass die users bis zu dem patchday warten bis der bug beseitigt wird.oder bei den safari users die einige gar nicht interessiert sind/bzw es ist ihnen egal.

außerdem
und das ist absolut wahr ! nicht so wie bei den ie wo man mindestens ein monat warten muss oder bei safari das erst nach mindestens 3 monaten mit ein update rechnen muss

Hmmh, das heisst doch jetzt nicht das der FF der unsicherste ist... Ich glabe ihr interpretiert die Meldung falsch. Umso mehr Lücken gefixt werden, umso sicherer wird das Produkt. Das hier ist ja nur eine Statistik über die bekannten Sicherheitslücken des letzten Jahres.

@argelborps

als ob ich sage, der Mann, der öfter zum Arzt geht ist ungesünder, weil er öfter behandelt werden muss...sagen wir mal so, da kann dann weniger schief gehen

ah, ok…dein wohnort erklärt deine verwunderung/aussage-
da wird auch versucht zu heilen und keine abm massnahmen ergriffen, aka behandlung…experimente, afaik.

bestes beispiel, auch wenn es eher bader und friseure betrifft: zahnklinik erlangen, studentenkurs…

ohh, die spritze wirkt nicht, auch nach drei gaben…ähmm, schon mal was von entzündteten gewebe gehört…ach, das bisschen wurzelkanalbehandlung im entzündeten gewebe halten sie schon aus.

hier könnte man wohl auch statt von behandlung oder experimenten von schlichter folter sprechen.

wohl auch ein grund das jeder dritte mediziner/apotheker statistisch in der gewaltopfer sparte auftaucht, ob berechtigt oder unberechtigt lasse ich jetzt mal aussen vor.

Bei Open-Source-Produkten wie Firefox liegen die Lücken alle offen auf dem Tisch. Sie werden offen dokumentiert, sie werden transparent und für jeden nachvollziehbar gefixt.

Bei Closed-Source-Produkten oder Halb-Closed-Source-Produkten sind nur diejenigen Lücken bekannt, die bekannt gemacht werden bzw. die das betreffende Unternehmen selbst bekannt macht oder zugesteht, dass sie bekannt gemacht werden dürfen. Wie hoch ist die Dunkelziffer an Fehlern und Sicherheitslücken, die aufgrund dieser Closed-Source-Strukturen weder öffentlich noch von Dritten aufgespürt werden können, weil der Hersteller da die Hand draufhält bzw. keinen Zugang zu den Sourcen gewährt? Bei Closed-Source-Produkten sind die Fehler also nur in soweit bekannt, wie der Hersteller es zulässt, dass sie bekannt werden. Deshalb ist es dann auch immer ganz besonders spektakulär, wenn dann mal ein Außenstehender eine Lücke findet.

Aus dieser Position eines Closed-Source-Herstellers ist es deshalb immer wohlfeil, genau so zu argumentieren und das Bild zu vermitteln, bei Open-Source-Software würden mehr Fehler gefunden, und deshalb sei diese Open-Source-Software oder OSS generell unsicherer als die eigene bzw. als Closed-Source-Software.

Das Gegenteil ist bei näherer Betrachtung meistens der Fall: je offener die Strukturen, je offener und transparenter die Review- und Audit-Prozesse, desto sicherer das Endprodukt am Ende.

Die Geschwindigkeit beim Schließen der gefundenen Lücken kommt dann noch als weiterer Faktor dazu, erst recht bei kritischen Lücken.

Es hat übrigends seinen Grund, warum die wesentlichen/wichtigsten Sicherheitsmechanismen, die das Internet von heute tragen, ihre Protokolle und Implementierungen alle auf offenen Standards beruhen und die Algorithmen und wesentliche Implementierungen derselben als Quellcode offen zugänglich und für jeden Interessierten einsehbar und nachvollziehbar sind und regelmäßig irgendwelchen Code-Reviews und -Audits unterzogen werden bzw. verbessert werden, wenn derlei Audits ergeben, dass nachgebessert werden muss. Das wäre bei Closed-Source so nicht möglich bzw. da wäre die Sicherheit/Qualität mit an Sicherheit grenzender Wahrscheinlichkeit nicht so hoch, weil dort nur ein eingeschränkter Kreis Zugang dazu hätte -- und das noch nicht mal notwendigerweise mit neutralen Hintergedanken.

Irgendwie klingt das immer nach "wir müssen neue Interneterweiterungen bringen, damit wir neue Sicherheitslücken bekommen".

Wenn man einen Browser mal extremst runter bricht, was macht der dann anders, als etwas zu lesen und anzuzeigen und Befehle seitens Tastatur/Maus zu übermitteln. Vom Up/Download mal abgesehen.

Wenn dem nicht so ist - ich mag da ja falsch liegen - müßte man das ganze Konzept in Frage stellen. Sollten dann diese gefährlichen Prozesse nicht generell gekapselt laufen? Also kein Durchgriff auf jegliche Resourcen.

Relevanz von Bugs

Wie so oft schauen sie nur auf die Anzahl, aber nicht auf die Qualität der Bugs.

SchaubFD:

Da sprichst Du bzgl. der Kapselung etwas an, was man auch als "Sandboxing" bezeichnet und was z.B. spätestens mit und seit der clientseitigen VM von Java so praktiziert wird bzw. zum dortigen Konzept gehört.

Und als erster Browser nutzt z.B. Google Chrome konsequent so ein Sandboxing, siehe hier: und hier: .
Auch der neue Internet Explorer 8 läuft auf ähnliche Weise in einer so abgeschlossenen Umgebung bzw. wird laufen.

MacMark beschreibt hier und hier , wie man Sandboxing zum Beispiel unter MacOSX nutzen kann.

Was Mozilla, Opera und Apple Safari diesbzgl. zu diesem Thema vorhaben, ob sie ihre Browser in Zukunft auch so einschließen, darüber habe ich im Moment keine Kenntnis, habe mich da aber ehrlich gesagt auch noch nicht so drum gekümmert. Es scheint die eine oder andere Drittsoftware zu geben dazu.
Abgesehen davon wird mit Firefox 3.5 bzw. Firefox 4.0 zum Beispiel dessen JavaScript-Engine, der JIT-Compiler, wohl nicht nur ein richtig schneller Compiler sein, sondern der wird nach allem, was ich bisher weiß, in einer solchen eigenen Sandbox-Umgebung laufen. Also arbeitet man wohl auch bei Firefox an diesem Thema.

MacMark:

Ich stimme Dir zu.

Bei Chrome kann jeder Tab in einem eigenen Prozeß laufen. Das ist keine Sandbox.

MacMark:

Gehe bitte auf die Links, die ich zu Chrome gepostet habe und lies sie Dir durch, dann weißt Du mehr.
Zumindest derzeit für Windows.
Und MacOSX bietet ja auch Sandboxing Machanismen an, wie Du auf Deinen eigenen Seiten richtigerweise schreibst. Vielleicht lässt der MacOSX Port von Chrome ja deshalb auf sich warten, weil man eben auch für die MacOSX-Version das vom OS bereitgestellte Sandboxing für sich nutzen will...

Zum Port von Chrome auf OS X habe ich zwei Artikel geschreiben. Der zweite ist im ersten verlinkt:


Danach Prüfungsfrage:
Warum laufen Windows-Libs nicht auf UNIX?

Zusatzfrage (für Note 1+):
Warum dauert es Chrome auf UNIX zu portieren?

Zur Chrome-"Sandbox":
"Anything that needs to be sandboxed needs to live on a separate process." sagt Deine Quelle deckungsgleich zu meiner Aussage. Das ist, worauf es basiert: Trennung der Prozesse durch das Betriebssystem. Kannste aber auf Windows eh knicken inklusive dem Integrity-Level-Theater auf Vista: Beispiel

MacMark:

Ja und? Was hat das, worüber Du dich dort auslässt, jetzt mit dem vorliegenden Thema zu tun? Ich sehe da nichts, noch nicht mal irgendwelche Berührungspunkte.

Wollen wir jetzt hier Fledderei begehen? Ich will mich jetzt nicht darauf versteigen, MacOSX bis auf die Hosen auszuziehen und dort irgendwelche Schwachstellen zu suchen und zu finden, die gibt es nämlich auch.
Als bleibe bitte beim Thema.
Google Chrome nutzt das vom OS bereitgestellte Sandboxing. Unter Windows bisher am konsequentesten, keine andere Anwendung zuvor hat davon bisher so konsequent Gebrauch gemacht, der kommende IE8 wahrscheinlich noch.

Um dieses Thema geht es. Um Browser-Sicherheit, Sicherheits-Lücken in Browsern, evtl. auch um Sandboxing (weil's hier eine in diese Richtung gehende Frage aufkam).

Und es geht nicht um's Thema, wie ich am wirkungsvollsten die anderen Betriebssysteme möglichst blöd darstellen kann und den eigenen Favoriten möglichst gut dastehen lassen kann. Und weil Du genau dazu nämlich sehr neigst, gehe ich an Deine Darstellungen meist auch eher etwas vorsichtiger ran bzw. erlaube mir an der einen oder anderen Stelle auch mal eine andere Sichtweise und einen Widerspruch.

Wenn Du meinst, Google böte kein "richtiges", kein "echtes" Sandboxing bzw. das Sandboxing unter MacOSX sei besser, dann meinetwegen. Fakt ist jedenfalls in dieser Hinsicht, dass auch Safari bisher von diesem Sandboxing keinen Gebrauch macht, sonst hättest Du wohl keine Gelegenheit haben können, damit herumzuexperimentieren und eine solche für Dich zu stricken und darüber zu schreiben. Mal sehen, wann Safari das standardmäßig anbietet, sodass Dein Proof-of-Concept damit überflüssig wird. Fakt ist jedenfalls bisher: Safari läuft standardmäßig nicht in einer Sandbox (auch wenn es theoretisch möglich ist). Google Chrome dagegen standardmäßig zumindest unter Windows schon mal mehr -- jedenfalls mehr als Safari bisher. Ob Du das nun anerkennst, ist eigentlich irrelevant.

Mehr sage ich dazu jetzt nicht. Ich habe keine Lust, das Thema jetzt zu vertiefen. Es würde wahrscheinlich auch zu sehr OT werden.

Es hat mit Deinem "Vielleicht lässt der MacOSX Port von Chrome ja deshalb auf sich warten" zu tun

Das UAC-Theater ist keine Schwachstelle, sondern Broken By Design. Lies den Artikel. Wirkungslose Augenwischerei.

Wenn Du statt Tabs neue Instanzen von Firefox aufmachst, hast Du auch jeweils "Sandboxen" vergleichbar mit Chrome.

das ist ja grade der Trugschluss darauß. Je mehr sicherheitslücken geschlossen wurden, desto besser.

Denn machen wir uns nichts vor, jede Software hat Sicherslücken ohne ende.

Und wer sich noch ein den Hacker-Contest von letztem Jahr erinnert, Apple war mit Safari die ersten die nach wenigen Minuten geknackt waren.

MacMark:

Nein, hat es nicht. Du hast offenbar nur dieses Stichwort gelesen und reflexartig gemeint, da etwas entgegnen zu müssen. Doch die Entgegnung hat inhaltlich damit überhaupt nichts zu tun. Außer dieser Äußerung/Fragestellung bzgl. der Verspätung für MacOSX -- die ja viele verschiedene Ursachen haben kann -- ist da nichts gemein. In der Schule würde man sagen: eine Antwort auf eine nicht gestellte bzw. thematisch ganz anders gezielte Frage. Sei's drum. Schnellschuss eben -- und vorbei geschossen.

Das kann sein, das mag sein. Darum geht's hier aber eigentlich nicht.

Das sehe ich ein wenig anders. Und so mancher Firefox-Verantwortliche, der sich dazu geäußert hat, wohl auch. Oder ich habe da in den betreffenden Äußerungen etwas gründlich missverstanden.

Auch da habe ich jetzt keine Lust, das Thema zu vertiefen, bitte sieh es mir nach. Und streiten will ich mit Dir hier jetzt schon mal gar nicht.
Also, lass uns hier das Thema mal langsam ausgleiten lassen. Vielleicht ein anderes Mal und an geeigneterer Stelle.

Ich antworte nicht nur auf Fragen, sondern korrigiere auch Aussagesätze.

Du siehst den Zusammenhang zwischen UAC und den Sandboxen von Chrome nicht? UAC > Integrity Level > ACEs an Prozessen > "Sandboxed" IE / "Sandboxen" für Chrome-Tabs.
Umgehen von ILs => UAC wertlos und IL-basierte "Sandbox" wertlos.

MacMark:

Genau. Alles wertlos. Alles, was nicht MacOSX oder Safari heißt: wertlos. Ist es diese Grundaussage, die Du damit tätigen willst?
Höre doch bitte endlich mal auf, ständig auf Windows und dessen Schwächen zu zeigen und das favorisierte MacOSX diesbzgl. zu erhöhen bzw. zu überhöhen. Hier geht's um was anderes. Hier geht's um Browser-Sicherheit. Und ein Google Chrome innerhalb einer Sandbox unter Windows ist ganz bestimmt sicherer als ein Google Chrome unter Windows, das nicht in einer Sandbox steckt. Und auch unter MacOSX wäre ein Safari innerhalb einer Sandbox bestimmt sicherer als ein Safari ohne Sandboxing.

In dem Umfeld, in dem sich das Sandboxing von Google Chrome unter Windows bewegt, ist es eine Erhöhung der Sicherheit gegenüber einer Lösung ohne Sandboxing.
Es ist völlig irrelevant, ob Du nun das Sandboxing unter Windows besser oder schlechter findest bzw. (natürlich!) das Sandboxing unter MacOSX besser.

Was also gibt es da jetzt dran zu rütteln? Wieso willst Du jetzt auf den Nebenkriegsschauplatz und an Windows und seinem "broken by design" (wobei sich seit Vista und Win7 da schon einiges gegenüber den Zuständen vorher gebessert hat) herumätzen? Das ist hier nicht Thema!

Wenn Du so fixiert darauf bist, jegliche Gelegenheit zu ergreifen, an Windows und seinem "broken by design" herumzuätzen (nebenbei bemerkt, ich mag Windows auch nicht bzw. lasse da i.d.R. auch kein gutes Haar dran und verwende deshalb vorzugsweise Linux und MacOSX), um MacOSX dagegen zu erhöhen, dann mache da bitte einen eignen Thread auf (eigentlich ja überflüssig, denn Deine eigene Website ist ja ergiebig genug zu diesem etwas einseitigen Thema).

Aber hier in dieser News-Meldung geht's jetzt nicht darum, zu konstatieren und diskutieren, welches Betriebssystem denn nun "den Längeren" hat, welches besser ist und welches schlechter, welches angeblich "broken by design" ist und welches nicht. Und deshalb lasse ich mich auch nicht auf den von Dir offenbar bevorzugten Nebenkriegsschauplatz verleiten, um fernab vom eigentlichen Thema das angebliche "broken by design" von Windows vorzuführen.

Du bist mir da einfach zu einseitig und zu selbstverliebt in der Betrachtungsweise was MacOSX angeht. MacOSX hat auch seine Fehler, Schwächen und Defizite. Und zu denen kannst Du Dich, nach allem, was ich bisher von Dir so lesen kann, anscheinend nur sehr mühsam (wenn überhaupt) bekennen. Und das ist jedenfalls mir zu einseitig.

Tut mir leid, dass ich Dir da nicht immer so bedingungslos und treu ergeben folgen kann.

Diese "Browser-Sicherheit" basiert auf exakt der Technik, auf der auch die UAC basiert: Integrity Level, ACEs für Prozesse et aliud. Diese Technik ist broken by design:
Allgemeiner Artikel:

Technischer Hintergrund:


Da beides auf derselben Technik basiert, hat beides denselben Grund, warum es nicht wirkt. Es ist daher keineswegs "Nebenschauplatz", sondern dieselbe Party.

Für Nicht-Techniker:
Wenn man zwei Häuser auf dem gleichen Sand baut, dann sind beide nichs wert. Der Grund, warum Haus 1 einstürzt ist derselbe aus dem Haus 2 einstürtzt.

MacMark:

Nochmal zum Mitschreiben: es geht hier um Browser-Sicherheit. Und nicht um OS-Sicherheit. Dass beides irgendwo und irgendwie zusammenhängt, ist unbestreitbar. Wenn Google Chrome für MacOSX herauskommt und dann das MacOSX-seitige Sandboxing benutzt, dann kannst Du meinetwegen beide gegeneinanderstellen und werten, wer denn das bessere Sandboxing betreibe. Vorher eher nicht, weil's ungleiche Bedingungen sind.

Diskutieren wir doch mal die Browser-Sicherheit von Safari bzw. wie Apple mit kritischen Lücken in seinem OS bzw. in Safari umgeht... (bitte ganz lesen incl. Resumé). Hmmm? Bisher zeigst Du Dich da verdächtig still und enthaltsam zu diesem Thema...

sierkb
Genau der Mastenbrook-Artikel ist mir jetzt auch gerade in den Sinn gekommen.
Du hattest den Link glaube ich schon vorige Tage gepostet.
Sehr interessant und leider auch etwas schade, dass Apple nicht schneller reagiert, wenn es um Sicherheitslücken geht.

Fen
Dass Du den Satz zu Firefox fett geschrieben hast, ist mir etwas sauer aufgestoßen. Das wirkt etwas voreingenommen, ist irreführend und wird dem Firefox nicht gerecht. Wenn auf einer Mac-Newsseite zu diesem Thema etwas hervorzuheben wäre, dann dass Safari-User sechs(!) Monate mit einer Schwachstelle dieser Brisanz durchs Internet gesurft sind. Ich würde mir wünschen, dass Ihr (die Redakteure von MTN) bei solchen Dingen wirklich neutral berichtet oder sogar dazu beitragt, dass der Leser ein realistisches Bild zur Sicherheitslage bekommt. Der Druck auf Apple muss noch deutlich steigen, wenn sich da etwas tun soll. Ich möchte ehrlich nicht erst warten müssen, bis gehäuft Schadensfälle publik werden.

Das ist nur eine Bitte und eine Anregung, also bitte nicht in den falschen Hals bekommen.

Ein Browser mit einer "Sandbox", die von Malware umgangen werden kann, ist gefährlicher als der gleiche Browser ohne diese trügerische Schein-Sicherheit. Das ist so, als wenn man Dir einen Papierhut verkauft und erzählt, damit wärest Du sicherer beim Motoradfahren. Tatsächlich bist Du aufgrund der Fehlinformation in größerer Gefahr als ohne Papierhut. Analoges gilt für wirkungslose Sandboxen.

Was meinst Du mit still und enthalsam? Ich habe über den Bug damals geschrieben:
macmark.de/blog/osx_blog_2009-01.php#safari_rss_bug

Und über einen anderen Safari-Bug durchaus kritisch folgendes:
www.macmark.de/blog/osx_blog_2008-12.php#macbook_not_hacked_in_two_minutes

Der Brian läßt sich da zu reihenweise Behauptungen hinreißen, die er nicht belegt, und die zeigen, daß er nicht ganz fit in OS X-Technik ist. Beispielsweise an der Stelle bezüglich "prompt the user for administrative credentials". Wenn er den technischen Hintergrund nicht kennt oder nicht versteht, dann soll er es halt einfach ausprobieren.

Der Mozilla Director of Security Engineering
Lucas Adamski ist übrigens von der Qualität dieser Studie wenig angetan.
Siehe auch:
Beware the Security Metric


z.B.
From a quick read it appears as though Firefox had almost 4 times as many security issues as IE or Safari! Like, OMG! However, that conclusion would be painfully incorrect. Mozilla discloses and releases bulletins for all security issues fixed in Firefox, regardless of how they were discovered. Unlike other vendors that only disclose issues reported by external independent parties, but not by internal developers, QA or security contractors.

oder auch:
The Secunia report is deeply disappointing on a number of levels. Frankly, it’s disappointing that security researchers aren’t taking the “research” part of their jobs as seriously as they once did. It’s also disappointing that Secunia would publish something like this as one really expect better from them. This sort of reporting only encourages companies to hide as many security issues and fixes as possible, which moves the state of security backwards. And this is perhaps the most disappointing thing of all.

Acronnax
Recht hat er!

Meine Rede seit Jahren. Hauptsache einen auf dicke Hose machen und Schlagzeilen produzieren.

MacMark & sierkb: Nutzt ihr das Sandboxing-Script für Safari? Ist das zu empfehlen?

MacMark: Bringt das "Pseudo"-Sandboxing von Chrome nicht vielleicht doch etwas? Auch wenn man das Sandboxing offenbar umgehen kann, würde es doch Schädlinge, die nicht für diese Art von Sandboxing geschrieben sind, aufhalten, oder?

Ich benutze meine Safari-Sandbox schon sehr lange.

Chrome verläßt sich auf die Prozeßtrennung, die Windows anbietet. Da ist nichts besonderes erforderlich. Der größte Unterschied zu vorher ist, daß die Webseiten nicht mehr in einem Prozeß laufen, sondern optional in eigenen.
Der "Ausbruch" erfolgt wie aus jedem anderen Windowsprogramm auch.

MacMark:

Ich wäre an Deiner Stelle mal etwas bescheidener und zurückhaltener mit so einer Aussage. Immerhin hat Brian Masterbrook eine Sicherheitslücke in Safari aufgedeckt, welche Apple mit seinem Security Update 2009-001 nach gut 7 Monaten dann endlich gefixt hat und in den Credits des erläuternden Dokuments zu diesem Fix u.a. auch den Namen Brian Masterbrook nennt bzw. ihn damit entsprechend würdigt. Dein Name hingegen steht da nicht.