Heise: Zyxel hat Backdoor in Firewalls einprogrammiert
Hallo zusammen,
Wer ein Endgerät (UTM/ Firewall/ AP) von Zyxel besitzt, sollte aufgrund fest hinterlegter und nicht änderbarer Zugangsdaten mal ein Update einspielen:
https://www.heise.de/amp/news/Zyxel-hat-Backdoor-fix-in-Firewalls-einpro ...
Gruß
em-pie
Wer ein Endgerät (UTM/ Firewall/ AP) von Zyxel besitzt, sollte aufgrund fest hinterlegter und nicht änderbarer Zugangsdaten mal ein Update einspielen:
https://www.heise.de/amp/news/Zyxel-hat-Backdoor-fix-in-Firewalls-einpro ...
Gruß
em-pie
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 637326
Url: https://administrator.de/contentid/637326
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
36 Kommentare
Neuester Kommentar
Zitat von @VGem-e:
wer weiß, welcher andere Hersteller so etwas nicht auch eingebaut hat und der "Fehler" so nur noch nicht bekannt ist?
wer weiß, welcher andere Hersteller so etwas nicht auch eingebaut hat und der "Fehler" so nur noch nicht bekannt ist?
Im Zweifel sollte man immer mal bei Cisco nachsehen
Ja klar! Cisco hatte ja in letzter Zeit ja "kaum" Sicherheitslücken.
(Router, Switches, WebEx, Security Manager. ...)
Gruß
its
Und selbst bei groben Bugs bei Cisco das Update für DEREN Fehler nur dann erhältlich is wenn man auch nen Supportvertrag hat.. Eigentlich nicht blöd - Erst verkaufe ich was mit Fehlern, dann lasse ich mir das beseitigen der Fehler auch noch mal pro Jahr bezahlen (und natürlich sind die Updates dann auch wieder mit Fehlern die was anderes zerlegen...)
Hallo,
ohne Studium des Quellcodes davon zu träumen, dass ClosedSource sicher ist, ist schon ziemlich grotesk.
Gilt natürlich auch für LANCOM, Cisco, Juniper und wie sie alle heißen...
Gruß,
Jörg
ohne Studium des Quellcodes davon zu träumen, dass ClosedSource sicher ist, ist schon ziemlich grotesk.
Gilt natürlich auch für LANCOM, Cisco, Juniper und wie sie alle heißen...
Gruß,
Jörg
Hallo!
Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
(Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.)
Wenn sich keiner um den Code kümmert, dann bleiben auch die Lücken.
Beispile Linux:
LZO - Sichheitslücke war 20 Jahre offen
Userspace-Krypto-API - Sichheitslücke war 10 Jahre offen
SOCKOPS_WRAP - Sichheitslücke war 8 Jahre offen
Dirty-Cow - Sichheitslücke war 10 Jahre offen
Speicherverwaltung - Sichheitslücke war 20 Jahre offen
...
Gruß
its
Zitat von @117471:
ohne Studium des Quellcodes davon zu träumen, dass ClosedSource sicher ist, ist schon ziemlich grotesk.
ohne Studium des Quellcodes davon zu träumen, dass ClosedSource sicher ist, ist schon ziemlich grotesk.
Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
(Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.)
Wenn sich keiner um den Code kümmert, dann bleiben auch die Lücken.
Beispile Linux:
LZO - Sichheitslücke war 20 Jahre offen
Userspace-Krypto-API - Sichheitslücke war 10 Jahre offen
SOCKOPS_WRAP - Sichheitslücke war 8 Jahre offen
Dirty-Cow - Sichheitslücke war 10 Jahre offen
Speicherverwaltung - Sichheitslücke war 20 Jahre offen
...
Gruß
its
Hallo,
Du verwechselst gerade Sicherheitslücken (die zum Zeitpunkt der Codeerstellung noch gar nicht relevant waren - siehe z.B. PPTP) und bewusst eingebaute Backdoors.
Ich habe durchaus Kunden, die Regierungen Informationen vorenthalten müssen (z.B. die Kalkulationsgrundlagen für öffentliche Aufträge). Und ich war auch schon in Firmen tätig, in denen für Microsoft, Google, SAP usw. usf. programmiert wird. Da ginge es dann unter Umständen nicht nur um das betriebsinterne Rechenwerk, sondern auch um das geistige Eigentum.
Gruß,
Jörg
Wenn sich keiner um den Code kümmert, dann bleiben auch die Lücken.
Du verwechselst gerade Sicherheitslücken (die zum Zeitpunkt der Codeerstellung noch gar nicht relevant waren - siehe z.B. PPTP) und bewusst eingebaute Backdoors.
Ich habe durchaus Kunden, die Regierungen Informationen vorenthalten müssen (z.B. die Kalkulationsgrundlagen für öffentliche Aufträge). Und ich war auch schon in Firmen tätig, in denen für Microsoft, Google, SAP usw. usf. programmiert wird. Da ginge es dann unter Umständen nicht nur um das betriebsinterne Rechenwerk, sondern auch um das geistige Eigentum.
Gruß,
Jörg
Zitat von @117471:
Du verwechselst gerade Sicherheitslücken (die zum Zeitpunkt der Codeerstellung noch gar nicht relevant waren - siehe z.B. PPTP) und bewusst eingebaute Backdoors.
Du verwechselst gerade Sicherheitslücken (die zum Zeitpunkt der Codeerstellung noch gar nicht relevant waren - siehe z.B. PPTP) und bewusst eingebaute Backdoors.
Ich meinte nur, dass OpenSource kein Garant für einen sauberen Code ist. Die RICHTIGEN müssen sich halt um den Code kümmern, ohne Kontrolle geht es auch da nicht.
Ich erinnere mich noch vage, als Anfang des Jahrtausends (ca. 2001) herauskam, dass eine Backdoor im Kernel 2.4 war, die bereits 1997 eingeschleust wurde. Nur erst Jahre später wurde sie halt entdeckt. Trotz OpenSource. Niemand hatte Lust die damals 3,5 Millionen Zeilen zu durchforsten. Die NSA hat mehrfach versucht (nachweislich in den 90ern, 2003 und 2013) Backdoors zu implementieren.
Die (Open)SSH Backdoor (war keine Sicherheitslücke, sondern eine bewusste Backdoor und) wurde glücklicherweise 2019 offen gelegt. (Darum schwebte eine ganze Backdoor Galaxie.)
Auf aktuelle Backdoors möchte ich da gar nicht eingehen, schon aufgrund der Forenregeln.
Nochmals, ich bin ein echter Freund von OpenSource. Aber ich liebe noch mehr sauberen Code.
Ich bin kein Freund von Backdoors, so gut sie auch gemeint sein mögen. Weder in Open- noch ClosedSource. Irgendwann werden sie immer entdeckt und dann missbraucht.
Fast jeder möchte sein Werk irgenwie geschützt sehen. Verständlicherweise. Nur Backdoors sind dafür nach meiner Meinung ein ungeeignetes Mittel. Und sie können sicherlich nicht dafür eingesetzt werden um Regierungen Informationen vorzuenthalten. Die Backdoors dienen eher dazu zusätzliche Informationen oder Kontrolle zu verschaffen.
Gruß
its
Zitat von @117471:
Ich habe durchaus Kunden, die Regierungen Informationen vorenthalten müssen (z.B. die Kalkulationsgrundlagen für öffentliche Aufträge).
Ich habe durchaus Kunden, die Regierungen Informationen vorenthalten müssen (z.B. die Kalkulationsgrundlagen für öffentliche Aufträge).
Nunja. Nichts gegen berechtigte Geheimhaltungsinteressen und nichts gegen ein gesundes Misstrauen gegenüber staatlichen Institutionen und Organisationen, aber gerade bei öffentlichen Aufträgen kann man sowohl gesetzlich als auch vertraglich verpflichtet sein, die eigenen Kalkulationsgrundlagen gegenüber dem öffentlichen Auftraggeber offen zu legen. Beispielsweise im Rahmen der Auskömmlichkeitsprüfung während des Vergabeverfahrens oder bei der Unterbreitung von Nachtragsangeboten, bei Anwendung von Lohngleitklauseln oder sonstigen Preisanpassungsklauseln u.v.m.
Gruß
sk
Zitat von @VGem-e:
wer weiß, welcher andere Hersteller so etwas nicht auch eingebaut hat und der "Fehler" so nur noch nicht bekannt ist?
Wenn die Dinger aus AmiLand kommen behaupte ich mal -> alle. Wie sollten die geheimdienste denn ansonsten die geräte ausspionieren? Nicht jeder setzt Windows ein und man muß doch trotzdem an die Daten kommen.wer weiß, welcher andere Hersteller so etwas nicht auch eingebaut hat und der "Fehler" so nur noch nicht bekannt ist?
🖖
So so...und alles was aus China kommt ist dann potentiell sicher ??
Nicht einmal bei europäischen Firmen ist das so:
https://www.br.de/nachrichten/netzwelt/cryptoleaks-wie-bnd-und-cia-gemei ...
Nicht einmal bei europäischen Firmen ist das so:
https://www.br.de/nachrichten/netzwelt/cryptoleaks-wie-bnd-und-cia-gemei ...
Wohl eher nicht, aber auch nicht schlimmer.
Nicht einmal bei europäischen Firmen ist das so:
Aber bei den Meisten. DSGVO und so. Das kann teuer werden, wenn da jemand was findet.
🖖
Zitat von @Dr.Bit:
Aber bei den Meisten. DSGVO und so. Das kann teuer werden, wenn da jemand was findet.
Aber bei den Meisten. DSGVO und so. Das kann teuer werden, wenn da jemand was findet.
Echt, ist das so?
Bekannte mit kleiner Praxis ruft mich vor 2 Wochen an, das Gesundheitswesen möchte zukünftig das IT-Sicherheits-Nirgendwo äh Niveau weiter erhöhen. Fritzbox ist jetzt des Teufels, zukünftig macht das "SICHERE PRAXIS IT" mit was "professionellem" für 29 EUR/Monat. Die machen dann auch (von extern) Updates und Firewall-Überwachung
Bin ja mal gespannt, was die da für diese Gelddruckmaschine an HW verbauen!
Ich sehe nur: Ist ne GmbH mit Stammkapital 25.000 vor ner Woche im HR eingetragen für irgendwas mit "Gesundheits-Cloud", im Zweifel mit guten Connection in die Politik und ner Anwaltskanzlei an der Hand um die Verantwortung "gerecht" zu verteilen
Und 1-2 Tage später lese ich dann das Ergebnis der letzten IT-Sicherheits-Kraftanstrengung unserer IT-Novizen:
https://www.heise.de/news/Sicherheitsmaengel-in-Kartenterminals-und-Kran ...
Deswegen: "Das KANN teuer werden" Und das nicht alles Gold ist was glänzt, sollte jedem klar sein. Ich persönlich (bezogen auf den Link und die Krankenkasen Apps) würde auch erwarten, daß mir meine Kasse eine sichere App zur Verfügung stellt bzw. Eine nennt, für die die dann auch verantwortlich zeichnen.
🖖
🖖
Hallo,
Japp. In der Praxis ist das allerdings so, dass derartige Bedingungen im Vorfeld offengelegt werden müssen und dass die "guten" Unternehmen da gar nicht erst mitbieten.
Du glaubst ja gar nicht, wie viele öffentliche Aufträge über den Deister gehen bzw. ausgesessen werden, weil ich niemand findet, der sich auf die Ausscheibungsmodalitäten einlässt. Das, was sich da erniedrigt, ist häufig nur der Bodensatz. Ich selber habe das z.B. schon bei der Bundeswehr erlebt. Wenn Du da in eine Ausschreibung guckst, werden tatsächlich noch Begriffe wie "MS-DOS" und "Telefax" erwähnt - das geht hier sofort in den Ofen^^
Gruß,
Jörg
Zitat von @sk:
aber gerade bei öffentlichen Aufträgen kann man sowohl gesetzlich als auch vertraglich verpflichtet sein, die eigenen Kalkulationsgrundlagen gegenüber dem öffentlichen Auftraggeber offen zu legen
aber gerade bei öffentlichen Aufträgen kann man sowohl gesetzlich als auch vertraglich verpflichtet sein, die eigenen Kalkulationsgrundlagen gegenüber dem öffentlichen Auftraggeber offen zu legen
Japp. In der Praxis ist das allerdings so, dass derartige Bedingungen im Vorfeld offengelegt werden müssen und dass die "guten" Unternehmen da gar nicht erst mitbieten.
Du glaubst ja gar nicht, wie viele öffentliche Aufträge über den Deister gehen bzw. ausgesessen werden, weil ich niemand findet, der sich auf die Ausscheibungsmodalitäten einlässt. Das, was sich da erniedrigt, ist häufig nur der Bodensatz. Ich selber habe das z.B. schon bei der Bundeswehr erlebt. Wenn Du da in eine Ausschreibung guckst, werden tatsächlich noch Begriffe wie "MS-DOS" und "Telefax" erwähnt - das geht hier sofort in den Ofen^^
Gruß,
Jörg
Ja, natürlich aber nur für Hinz und Kunz.
Alle die ganz groß auf die Sicherheits-Kacke hauen haben immer mehrere Ebenen um die Verantwortung - die bei den Preisverhandlungen natürlich riesig ist - auch ganz sicher von sich weg zu schieben.
Ist ja jetzt nicht so, als ob z.B. Cisco auf Grund von Kundenklagen bzgl. Ihrer programmierten Backdoors vor der Pleite steht.
Und so läuft das doch seit Jahren: Auf der einen Seite steigt der Aufwand, die Sicherheitsvorgaben und die Kosten dafür ins fast schon unermessliche .... und auf der anderen Seite zahlt dann doch niemand, wenn Du es ausreizt.
Alle die ganz groß auf die Sicherheits-Kacke hauen haben immer mehrere Ebenen um die Verantwortung - die bei den Preisverhandlungen natürlich riesig ist - auch ganz sicher von sich weg zu schieben.
Ist ja jetzt nicht so, als ob z.B. Cisco auf Grund von Kundenklagen bzgl. Ihrer programmierten Backdoors vor der Pleite steht.
Und so läuft das doch seit Jahren: Auf der einen Seite steigt der Aufwand, die Sicherheitsvorgaben und die Kosten dafür ins fast schon unermessliche .... und auf der anderen Seite zahlt dann doch niemand, wenn Du es ausreizt.
Hallo,
eben!
Ich bin weitestgehend von diesem eierlegenden Wollmilchsaukack ab.
Gerade LANCOM & Co. hat immer mehr von „Nero - Burning ROM“. Ein Router ist nun mal kein Printserver und auch keine Telefonanlage.
Gruß,
Jörg
eben!
Ich bin weitestgehend von diesem eierlegenden Wollmilchsaukack ab.
Gerade LANCOM & Co. hat immer mehr von „Nero - Burning ROM“. Ein Router ist nun mal kein Printserver und auch keine Telefonanlage.
Gruß,
Jörg
Zitat von @IT-Spezi:
Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
Sehe ich anders. Genau das ist doch schon ein Vorteil von Open Source: Viele schauen drauf und du selbst kannst schauen, was die Software macht, ob Backdoors drin sind etc. Bei proprietärer Software hat außer dem Hersteller keiner überhaupt die Möglichkeit dazu.Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
Eine Garantie, dass JEDE Software ständig und tiefgehend geprüft wird, ergibt sich daraus natürlich nicht. Das ist die falsche Schlussfolgerung, die du ziehst. Schließlich braucht es dafür Ressourcen und den Wille, diese in Qualität zu investieren. Das ist grade bei großen Codebasen eine Mammutaufgabe, zumal man das regelmäßig machen müsste.
Übertrage dein Argument doch mal ähnliche Sachverhalte, dann du vllt besser warum ich diese Aussage für sinnfrei halte - Beispiel:
Aber zu glauben, dass mit Sicherheitsgurt zu fahren besser sei, nur weil dieser einem bei einem Unfall retten kann, ist grotesk
Der Logik nach sollten wir also keine Gurte verwenden, weil schon Menschen verletzt wurden oder sogar gestorben sind, trotz Sicherheitsgurt. Die Schlussfolgerung ist Falsch, weil der Gurt die Chance auf geringere Verletzungen bzw. sogar überleben erhöht. Mit Gurt fahren ist daher immer besser.Mit OS ist es nicht viel anders. Was man sagen kann ist, dass die Codequalität von OS nicht zwingend besser sein muss. Wie bei jeder Software hängt das von den Entwicklern ab und den Anspruch der leitenden Personen. Bei FreeBSD z.B. zählt schon fehlende Dokumentation als Bug. Es gibt aber auch Projekte, da werden Tickets permanent geschlossen, wenn sich mal jemand ein paar Tage nicht meldet - teils sogar vom Team und auch bei Sicherheitslücken.
Aber das ändert ja eben nichts an den Vorteilen, die OS prinzipiell bietet: Du kannst den Code anschauen (und z.B. feststellen, dass der grottig ist und du das lieber nicht für was kritisches einsetzen willst), begutachten, verändern, bist nicht zu 100% von einem Hersteller abhängig, kannst das Projekt ggf weiter nutzen wenn der Hersteller es einstellt und so weiter und so fort. Schon alleine deswegen ist die Aussage, OS wäre nicht besser weil es offen ist, falsch. Genau das macht es schon besser. Im Optimalfall ist natürlich auch die Codequalität besser, aber das schwankt eben. Ist proprietär übrigens nicht anders. Manche arbeiten gewissenhafter an ihrem Code, woanders baut jemand Hintertüren an und als man das Jahre später merkt braucht man 3 Anläufe um das Sicherheitsloch am Ende noch größer zu machen...
Zitat von @IT-Spezi:
Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.
Dann solltest du das doch eigentlich auch wissen Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.
@asp.net.core
Selten erlebt, dass jemand einen einzelnen Satz so aus dem Kontext reißt.
In meine Antwort auf @117471 (gegen ClosedSource) ging es darum, dass auch in (gängiger) OpenSource-Software schlechter Code vorhanden ist und auch OpenSource-Programmierer Mist verzapfen.
Später ging ich auf die Backdoors ein, die bewusst in OpenSource eingebaut wurden:
Interessant ist allerdings Deine Aussage:
Egal ob Closed- oder OpenSource. Nach meiner Meinung haben Backdoors in (sauberen) Code nichts verloren, da sie langfristig mehr Schaden anrichten als sie anfänglich Nutzen bringen.
Gruß
its
Selten erlebt, dass jemand einen einzelnen Satz so aus dem Kontext reißt.
In meine Antwort auf @117471 (gegen ClosedSource) ging es darum, dass auch in (gängiger) OpenSource-Software schlechter Code vorhanden ist und auch OpenSource-Programmierer Mist verzapfen.
Wenn sich keiner um den Code kümmert, dann bleiben auch die Lücken.
Beispiele Linux:
LZO - Sichheitslücke war 20 Jahre offen
Userspace-Krypto-API - Sichheitslücke war 10 Jahre offen
SOCKOPS_WRAP - Sichheitslücke war 8 Jahre offen
Dirty-Cow - Sichheitslücke war 10 Jahre offen
Speicherverwaltung - Sichheitslücke war 20 Jahre offen
...
Beispiele Linux:
LZO - Sichheitslücke war 20 Jahre offen
Userspace-Krypto-API - Sichheitslücke war 10 Jahre offen
SOCKOPS_WRAP - Sichheitslücke war 8 Jahre offen
Dirty-Cow - Sichheitslücke war 10 Jahre offen
Speicherverwaltung - Sichheitslücke war 20 Jahre offen
...
Später ging ich auf die Backdoors ein, die bewusst in OpenSource eingebaut wurden:
Ich meinte nur, dass OpenSource kein Garant für einen sauberen Code ist. Die RICHTIGEN müssen sich halt um den Code kümmern, ohne Kontrolle geht es auch da nicht.
Ich erinnere mich noch vage, als Anfang des Jahrtausends (ca. 2001) herauskam, dass eine Backdoor im Kernel 2.4 war, die bereits 1997 eingeschleust wurde. Nur erst Jahre später wurde sie halt entdeckt. Trotz OpenSource. Niemand hatte Lust die damals 3,5 Millionen Zeilen zu durchforsten. Die NSA hat mehrfach versucht (nachweislich in den 90ern, 2003 und 2013) Backdoors zu implementieren.
Die (Open)SSH Backdoor (war keine Sicherheitslücke, sondern eine bewusste Backdoor und) wurde glücklicherweise 2019 offen gelegt. (Darum schwebte eine ganze Backdoor Galaxie.)
Die (Open)SSH Backdoor (war keine Sicherheitslücke, sondern eine bewusste Backdoor und) wurde glücklicherweise 2019 offen gelegt. (Darum schwebte eine ganze Backdoor Galaxie.)
Nochmals, ich bin ein echter Freund von OpenSource. Aber ich liebe noch mehr sauberen Code.
Ich bin kein Freund von Backdoors, so gut sie auch gemeint sein mögen. Weder in Open- noch ClosedSource. Irgendwann werden sie immer entdeckt und dann missbraucht.
Ich bin kein Freund von Backdoors, so gut sie auch gemeint sein mögen. Weder in Open- noch ClosedSource. Irgendwann werden sie immer entdeckt und dann missbraucht.
Interessant ist allerdings Deine Aussage:
Eine Garantie, dass JEDE Software ständig und tiefgehend geprüft wird, ergibt sich daraus natürlich nicht. Das ist die falsche Schlussfolgerung, die du ziehst.
So eine Schlussfolgerung gab es von mir gar nicht!Egal ob Closed- oder OpenSource. Nach meiner Meinung haben Backdoors in (sauberen) Code nichts verloren, da sie langfristig mehr Schaden anrichten als sie anfänglich Nutzen bringen.
Gruß
its
Zitat von @GNULinux:
Eine Garantie, dass JEDE Software ständig und tiefgehend geprüft wird, ergibt sich daraus natürlich nicht. Das ist die falsche Schlussfolgerung, die du ziehst. Schließlich braucht es dafür Ressourcen und den Wille, diese in Qualität zu investieren. Das ist grade bei großen Codebasen eine Mammutaufgabe, zumal man das regelmäßig machen müsste.
Übertrage dein Argument doch mal ähnliche Sachverhalte, dann du vllt besser warum ich diese Aussage für sinnfrei halte - Beispiel:
Zitat von @IT-Spezi:
Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
Sehe ich anders. Genau das ist doch schon ein Vorteil von Open Source: Viele schauen drauf und du selbst kannst schauen, was die Software macht, ob Backdoors drin sind etc. Bei proprietärer Software hat außer dem Hersteller keiner überhaupt die Möglichkeit dazu.Aber zu glauben dass OpenSource besser sei, nur weil man den Code studieren kann, ist genauso grotesk.
Eine Garantie, dass JEDE Software ständig und tiefgehend geprüft wird, ergibt sich daraus natürlich nicht. Das ist die falsche Schlussfolgerung, die du ziehst. Schließlich braucht es dafür Ressourcen und den Wille, diese in Qualität zu investieren. Das ist grade bei großen Codebasen eine Mammutaufgabe, zumal man das regelmäßig machen müsste.
Übertrage dein Argument doch mal ähnliche Sachverhalte, dann du vllt besser warum ich diese Aussage für sinnfrei halte - Beispiel:
Aber zu glauben, dass mit Sicherheitsgurt zu fahren besser sei, nur weil dieser einem bei einem Unfall retten kann, ist grotesk
Der Logik nach sollten wir also keine Gurte verwenden, weil schon Menschen verletzt wurden oder sogar gestorben sind, trotz Sicherheitsgurt. Die Schlussfolgerung ist Falsch, weil der Gurt die Chance auf geringere Verletzungen bzw. sogar überleben erhöht. Mit Gurt fahren ist daher immer besser.Moin, nur das du bei Software heute keinerlei Kontrolle darüber hast. Du kannst dir EIN Stück bei OS angucken (wenn du es denn machst), fein. Es wird aber idR. zig externe Frameworks beinhalten die jedes für sich auch wieder geprüft werden müssten (und die teils eben nich offen sind). Dann hast du noch die Faktoren das du ggf. durch die Verwendung in deinem Kontext eine Sicherheitslücke aufreisst... Übertragen auf dein Auto bedeutet das also: Du glaubst das dein Sicherheitsgurt sicher is weil du den anlegst. Du weisst aber gar nicht ob z.B. die Halteschrauben ggf. nur aus Plastik sind, ob der Gurt selbst nich schon nur noch an 2 dünnen Fäden hängt oder ob dein ganzes Auto ggf. schon kurz vor der Explosion steht. Du sagst aber es ist sicher weil du den letzten Teil im System siehst und meinst der is sicher?
Mit OS ist es nicht viel anders. Was man sagen kann ist, dass die Codequalität von OS nicht zwingend besser sein muss. Wie bei jeder Software hängt das von den Entwicklern ab und den Anspruch der leitenden Personen. Bei FreeBSD z.B. zählt schon fehlende Dokumentation als Bug. Es gibt aber auch Projekte, da werden Tickets permanent geschlossen, wenn sich mal jemand ein paar Tage nicht meldet - teils sogar vom Team und auch bei Sicherheitslücken.
Aber das ändert ja eben nichts an den Vorteilen, die OS prinzipiell bietet: Du kannst den Code anschauen (und z.B. feststellen, dass der grottig ist und du das lieber nicht für was kritisches einsetzen willst), begutachten, verändern, bist nicht zu 100% von einem Hersteller abhängig, kannst das Projekt ggf weiter nutzen wenn der Hersteller es einstellt und so weiter und so fort. Schon alleine deswegen ist die Aussage, OS wäre nicht besser weil es offen ist, falsch. Genau das macht es schon besser. Im Optimalfall ist natürlich auch die Codequalität besser, aber das schwankt eben. Ist proprietär übrigens nicht anders. Manche arbeiten gewissenhafter an ihrem Code, woanders baut jemand Hintertüren an und als man das Jahre später merkt braucht man 3 Anläufe um das Sicherheitsloch am Ende noch größer zu machen...
Trotzdem ist eben OS nicht zwingend besser - das würde eben bedeuten das du auf ALLES einen Zugriff hast, das hast du eben nicht. Du guckst dir den Quellcode an - schön, und? Was passiert denn mit dem Compiler den du zum übersetzen nutzt? Beim BS eher nicht, aber nehmen wir an es ist ne Java-Anwendung - schon wirst du dir eher nicht vom Compiler den Code angucken weil der bei Oracle nicht frei ist. Damit hast du wieder einen Teil gesehen und behauptest das ganze is deshalb sicherer?
Zitat von @IT-Spezi:
Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.
Dann solltest du das doch eigentlich auch wissen Nur um das klar zu stellen: Ich liebe OpenSource! Ich setzte OpenSource-Software jeden Tag gerne ein.
Nein - auch da sollte man wissen wo die grenzen liegen. Ich nutze auch viel OS aber das macht es eben nicht automatisch sicherer. Die Sicherheit kommt eben nicht (nur) vom Code, sondern auch davon was derjenige damit macht der es einsetzt. Und da ist es leider nicht Schwarz/Weiss... Leider ist es bei OS wie bei CPUs, beim BS,... -> viele "Glaubenskriege" weil jeder meint nur seine Lösung würde passen...
Nach meiner Meinung haben Backdoors in (sauberen) Code nichts verloren
Das ist richtig, die Praxis sieht aber bekanntlich ganz anders aus:https://www.heise.de/news/Juniper-Skandal-China-uebernahm-angeblich-Hint ...
Da brechen dann alle Dämme.
Zitat von @IT-Spezi:
@asp.net.core
Selten erlebt, dass jemand einen einzelnen Satz so aus dem Kontext reißt.
In meine Antwort auf @117471 (gegen ClosedSource) ging es darum, dass auch in (gängiger) OpenSource-Software schlechter Code vorhanden ist und auch OpenSource-Programmierer Mist verzapfen.
@asp.net.core
Selten erlebt, dass jemand einen einzelnen Satz so aus dem Kontext reißt.
In meine Antwort auf @117471 (gegen ClosedSource) ging es darum, dass auch in (gängiger) OpenSource-Software schlechter Code vorhanden ist und auch OpenSource-Programmierer Mist verzapfen.
Der Kontext ändert nichts daran, dass du gesagt hast: OS sei nicht besser, nur weil man den Quellcode studieren kann. Von sauberem Code stand in dem Post nichts, sondern nur pauschal OS wäre nicht besser. Dass die Codequalität in Software grundsätzlich variiert, egal ob OS oder proprietär, ändert nichts daran, dass diese Aussage falsch ist. Denn OS bietet zahrleiche weitere Vorteile, wie ich oben ausführlich erklärt habe.
Das unterschreibe ich, aber wie gesagt hast du Anfangs was anderes geschrieben. Worauf ich mit meinem Post hinaus wollte ist, dass OS - unabhängig von der Codequalität - Vorteile bietet. Im Grunde ist OS ja die Voraussetzung dafür, die Codequalität überhaupt erst mal seriös bewerten zu KÖNNEN. Bei proprietärer Software sieht außer dem Hersteller keiner den Code. Da kann man nur Vermutungen auf Basis von öffentlichen Vorkommnissen erstellen. Es sollte aber klar sein, dass wir uns da ziemlich von einer seriösen und wissenschaftlichen Herangehensweise entfernen und so was in Richtung Niveau von "Der hat mehr (bekannte) Sicherheitslücken, also ist dessen SW unsicherer als vom anderen bei dem es weniger bekannte gibt".
Direkt vielleicht nicht, aber indirekt liegt dieser Aussage ja der Gedanke zugrunde, dass die Codequalität von OS grundsätzlich viel besser sein muss, damit es Sinn ergibt hervorzuheben, dass dies nicht zwingend der Fall ist.
Zitat von @IT-Spezi:
Egal ob Closed- oder OpenSource. Nach meiner Meinung haben Backdoors in (sauberen) Code nichts verloren, da sie langfristig mehr Schaden anrichten als sie anfänglich Nutzen bringen.
Egal ob Closed- oder OpenSource. Nach meiner Meinung haben Backdoors in (sauberen) Code nichts verloren, da sie langfristig mehr Schaden anrichten als sie anfänglich Nutzen bringen.
Dann sind wir letztendlich ja doch einer Meinung
Zitat von @maretz:
Du kannst dir EIN Stück bei OS angucken (wenn du es denn machst), fein. Es wird aber idR. zig externe Frameworks beinhalten die jedes für sich auch wieder geprüft werden müssten (und die teils eben nich offen sind).
Du kannst dir EIN Stück bei OS angucken (wenn du es denn machst), fein. Es wird aber idR. zig externe Frameworks beinhalten die jedes für sich auch wieder geprüft werden müssten (und die teils eben nich offen sind).
Grundsätzlich gebe ich dir Recht, dass Abhängigkeiten ein Problem sind. Gerade weil der Trend dahin geht, dutzende Abhängigkeiten ohne großartige Prüfung einzubinden. Besonders krass bei NodeJS, da gibts externe Pakete für Kleinigkeiten wie String mit Leerstellen auffüllen die aus 5 Zeilen Code bestehen. Modularität in allen Ehren, aber dafür würde ich mir keinen fremdem Code einbinden wollen.
Zitat von @maretz:
Trotzdem ist eben OS nicht zwingend besser - das würde eben bedeuten das du auf ALLES einen Zugriff hast, das hast du eben nicht.
Da widerspreche ich. Warum muss OS alle Probleme zu 100% lösen können, um besser zu sein? Der Logik nach könnte man auch sagen, mit Sicherheitsgurt zu fahren ist nicht besser als ohne, schon alleine weil du auch da nicht alle Faktoren kennst und weißt, ob der Gurt dich bei einem Unfall rettet.Trotzdem ist eben OS nicht zwingend besser - das würde eben bedeuten das du auf ALLES einen Zugriff hast, das hast du eben nicht.
Ist natürlich Unsinn, weil der Sicherheitsgurt eben in manchen Situationen hilft und es damit BESSER macht als ohne Gurt. Warum setzt du bei OS einen völlig anderen und zudem unrealistischen Maßstab an?
Und wenn wir schon dabei sind: Was ist deiner Meinung nach die bessere Alternative? Proprietäre Software?! Selbst wenn bei einem OS Projekt ein Teil proprietär ist, so ist das ganze immer noch WEIT transparenter als ein komplett proprietäres Projekt.
Zitat von @maretz:
Du guckst dir den Quellcode an - schön, und? Was passiert denn mit dem Compiler den du zum übersetzen nutzt? Beim BS eher nicht, aber nehmen wir an es ist ne Java-Anwendung - schon wirst du dir eher nicht vom Compiler den Code angucken weil der bei Oracle nicht frei ist.
Du guckst dir den Quellcode an - schön, und? Was passiert denn mit dem Compiler den du zum übersetzen nutzt? Beim BS eher nicht, aber nehmen wir an es ist ne Java-Anwendung - schon wirst du dir eher nicht vom Compiler den Code angucken weil der bei Oracle nicht frei ist.
Java ist ein schlechtes Beispiel, dafür gibt es offene Implementierungen. Statt des proprietären (und teuren) Oracle Java könnte man z.B. auch OpenJDK nehmen.
Aber ich sehe worauf du hinaus willst. In der Theorie gebe ich dir Recht, wir können das Spiel noch viel weiter treiben: Was ist mit deinem Betriebssystem? Der Hardware? Da gibt es dutzende oft propritäre Treiber in denen ein Backdoor stecken könnte, der deine mühsam abgesicherte Anwendung kaputt macht. Es gibt sogar erfolgreiche Bemühungen die Strahlen eines Bildschirmes über etliche Meter abzufangen und Rückschlüsse zu ziehen, was angezeigt wurde.
Und noch viel mehr, aber worauf zielt das ab? Dass Sicherheitsmaßnahmen die einen Teil abdecken unsinnig sind? Das halte ich für fundamental falsch. Irgendwo muss man eine Grenze ziehen. Es ist unmöglich alle möglichen Vektoren abzudecken. Sondern man konzentriert sich auf das was realistisch und wahrscheinlich ist. Nicht nur in der IT. Oder hast du dein Haus dagegen versichert, falls zufällig ein Raumschiff darüber fliegt, etwas abbricht und das durch dein Dach kracht? Wie das hast du etwa nicht?! Dann kannst du die Türschlösser auch gleich rausnehmen, weil ist ja nicht mehr 100% sicher!!!111einself
Zitat von @maretz:
Damit hast du wieder einen Teil gesehen und behauptest das ganze is deshalb sicherer?
Damit hast du wieder einen Teil gesehen und behauptest das ganze is deshalb sicherer?
Das ist es doch auch. Nicht 100% sicher, aber sicherer wie wenn ich diesen Teil nicht begutachtet hätte ist es.
Ich meine schauen wir uns doch mal die Realität an: Werden Cisco oder Zyxel Switche angegriffen, weil im Nachbargebäude ein 20 Köpfiges Team die Elektrischen Wellen mitschneidet, in Handarbeit analysiert und daraus private Schlüssel generiert? Habe ich in der Praxis noch nie gehört. Wovon ich ständig höre ist, dass auf ziemlich niedrigem Niveau geschlampt wird: Ein hart kodiertes PW für alle Geräte, weils zum entwickeln einfacher war, jemand vergessen hat und es keine Qualitätssicherung gab. Eine Backdoor schlummert Jahrelang ohne besonders gutes Versteck im Quellcode, weil kommerzielle Firmen Geld mit Features verdienen wollen statt es für Sicherheitsprüfungen auszugeben. Und so weiter und so fort.
Es gibt zig hochkomplexe Angriffsvektoren die aber im Alltag keine Rolle spielen, weil man sich doch mit viel weniger Aufwand ziemlich erfolgreich durchmogeln kann. Mit dem Quellcode des jeweiligen Systemes/Produktes hast du schon mal einiges gewonnen, da die Wahrscheinlichkeit hoch ist, dass (vor allem Backdoors) direkt da drin liegen. Außerdem kannst du bei Abhängigkeiten zumindest die Versionen prüfen um zu checken, ob zumindest Sicherheitspatche eingespielt wurden. Das halte ich beim Thema Sicherheit noch für den am ehesten praktikabelsten Mittelweg.
Zitat von @maretz:
Nein - auch da sollte man wissen wo die grenzen liegen. Ich nutze auch viel OS aber das macht es eben nicht automatisch sicherer.
Da kommen wir nun in die Details. Wenn du einfach die Nutzung einer OS Software mit einer proprietären Vergleichst, bist du auf der Abstraktion tatsächlich nicht automatisch sicherer mit OS. Im Grunde vertraust du dann eben einer Community statt eines kommerziellen Unternehmens. Man kann diskutieren, was davon vertrauenswürdiger ist. Aber pauschal kann man nicht sagen A oder B.Nein - auch da sollte man wissen wo die grenzen liegen. Ich nutze auch viel OS aber das macht es eben nicht automatisch sicherer.
Wenn wir es mal nur auf die Sicherheit reduzieren (ohne sonstige Vor/Nachteile) kannst du einen von beiden nur dann als sicherer bewerten, wenn es z.B. Audits gibt. Oder du eben selbst den Code anschaust bzw anschauen lässt. Das ist natürlich nicht für Jedermann praktikabel. Und man muss sich auch klar sein, dass unabhängige Audits bei OS kein Problem sind, bei proprietärer Software dagegen schwierig. Aber von dieser Zielgruppe sprichst du wohl nicht, wenn wir uns darüber unterhalten, Abhängigkeiten und proprietäre Compiler auseinander zu nehmen - das wäre eher die Zielgruppe, die sehr viel Wert auf Sicherheit legt und sich aus diesem Grunde für OS entscheidet um es auseinander nehmen zu können
Zitat von @maretz:
Die Sicherheit kommt eben nicht (nur) vom Code, sondern auch davon was derjenige damit macht der es einsetzt.
Das stimmt, wobei ich sicheren Code bzw. Anwendungen als eine Art Fundament sehe. Wenn die Anwendung nicht sicher ist, kann auch ein guter Admin das nur begrenzt wieder grade biegen. Wie bei so vielem braucht man für das Optimale Ergebnis ein stimmiges Gesamtkonzept. 1A gewartete Anwendungen nützen auch nur begrenzt, wenn z.B. das OS darunter uralt und ungepflegt ist.Die Sicherheit kommt eben nicht (nur) vom Code, sondern auch davon was derjenige damit macht der es einsetzt.
Zitat von @maretz:
Und da ist es leider nicht Schwarz/Weiss... Leider ist es bei OS wie bei CPUs, beim BS,... -> viele "Glaubenskriege" weil jeder meint nur seine Lösung würde passen...
Im Gesamtbild hat OS tendenziell mehr Vorteile gegenüber proprietärer Software. Diese Meinung habe ich nicht weil ich blind daran "glaube" wie an irgend einen Gott, das halte ich in der IT für falsch. Da sollte es eher ein sachliches/wissenschaftliches Vorgehen geben. Daher frage ich mich, warum OS sich heutzutage gegenüber proprietärer Software noch so rechtfertigen muss. Bei mir ist das eher umgekehrt, dass proprietäre Software entsprechende Vorteile haben muss, damit sie zu OS eine Alternative darstellen kann.Und da ist es leider nicht Schwarz/Weiss... Leider ist es bei OS wie bei CPUs, beim BS,... -> viele "Glaubenskriege" weil jeder meint nur seine Lösung würde passen...
Das muss nicht heißen, dass es gar keine proprietäre Software gibt. Es gibt ja durchaus Bereiche, in denen es noch keine wirklich guten OS Projekte gibt und man daher keine Wahl hat. Tendenziell wird das aber immer weniger. In vielen Bereichen ist offene/freie Software sogar zum Standard geworden. MS selbst ist da ein gutes Beispiel, die schon vor Jahren zugeben durften, dass mehr Linux VMs in der hauseigenen Cloud laufen als Windows. Aber hier sind wir halt auch an einem Punkt, den ich in den letzten Beiträgen schon angesprochen habe: Bei OS geht es nicht nur um Sicherheit. Das ist ein Aspekt von vielen.
Für optimale Sicherheit stimmt das. Aber auch hier die Frage: Was ist die Alternative, wenn du dieses Niveau an Sicherheit willst? Bei OS hast du die Möglichkeit. Bei proprietärer Software musst du nicht nur darauf vertrauen, dass der Hersteller dich nicht verarscht. Sondern auch, dass der wiederum ausreichend in die Absicherung seiner Systeme investiert, damit er nicht unbemerkt kompromittiert wird. Wie sehr dieses Vertrauen nach hinten los gehen kann, sehen wir aktuell an SolarWinds. Ein Unternehmen wird gehackt, merkt es nicht und schon sind etliche Behörden bis hin zu AKWs und selbst Softwareriesen wie Microsoft kompromittiert. Denen wurde ja sogar der Windows Quellcode geklaut.
Es gibt dutzende Projekte die von einer großen und aktiven Community gepflegt werden. Und klar gibt es auch welche wie openssl, die total unterbesetzt waren. Hier sollte sich aber auch jeder selbst an die Nase fassen und SW-Projekte die er nutzt unterstützen. Wenn man keine Zeit hat zumindest hier und da mal mit einer Geldspende. Denn am Ende hat man davon ja auch einen Nutzen. Und OS kann nur funktionieren, wenn ein gewisser Teil sich mit einbringt. Muss gar nicht viel sein, wenn es genug sind, sodass es effektiv immer noch günstiger sein kann als was zu kaufen.
Es gibt dutzende Projekte die von einer großen und aktiven Community gepflegt werden. Und klar gibt es auch welche wie openssl, die total unterbesetzt waren. Hier sollte sich aber auch jeder selbst an die Nase fassen und SW-Projekte die er nutzt unterstützen. Wenn man keine Zeit hat zumindest hier und da mal mit einer Geldspende. Denn am Ende hat man davon ja auch einen Nutzen. Und OS kann nur funktionieren, wenn ein gewisser Teil sich mit einbringt. Muss gar nicht viel sein, wenn es genug sind, sodass es effektiv immer noch günstiger sein kann als was zu kaufen.
Zitat von @Herbrich19:
Was ist mit den Zyxel IES5005 DSLAM und seinen Line Cards? Sind diese Geräte auch betroffen?
Was ist mit den Zyxel IES5005 DSLAM und seinen Line Cards? Sind diese Geräte auch betroffen?
Nein. Dein steinalter DSLAM bassiert(e) noch auf ZyNOS.
Von dem hier genannten Problem sind nur die auf Linux basierenden dedizierten WLAN-Controller und Firewalls (welche ebenfalls WLAN-Controller-Funktionalität besitzen) betroffen.
Da bei den Firewalls lediglich Version 4.60 angreifbar sein soll, während bei den dedizierten WLAN-Controllern wohl auch ältere Versionen betroffen sind, erscheint es mir naheliegend, dass das Problem über eine Rückportierung des Controller-Codes auf die (bezüglich WLAN-Controller-Funktionalität immer etwas hinterher hinkenden) Firewalls in letztere Einzug hielt.
Gruß
sk