Cisco AP

[andy_m4]

Kein Hersteller ist unbeleckt betreffs Sicherheitsluecken. Keiner.

Mag sein. Aber es geht nicht nur um die Anzahl der Sicherheitslücken, sondern auch um die Art.
Sowas wie hardcoded Credentials ist schon ne harte Nummer. Vor allem wenn es nicht nur einmal vorkommt, sondern mehrmals.

Nur entdeckte Lücken können geschlossen werden

Naja. Bugs sind ja jetzt kein unausweichliches Schicksal, sondern hat auch was mit Qualität im Entwicklungsprozess zu tun.
Mal angesehen davon hast Du auch nicht selten den Fall, das Lücken schon ne Weile in freier Wildbahn ausgenutzt werden.

nicht wie beim den meisten SOHO-Herstellern ungepatcht.

Mag sein. Aber Cisco nimmt für seine Produkte ja auch ordentlich Geld. Willst Du jetzt ernsthaft da die gleichen Maßstäbe anlegen wie beim China-Router der irgendwie auf nem Hinterhof zusammengeschraubt wurde?

Und dann vergleiche mal jeweils mit anderen vergleichbar komplexen Systemen.

Komplexe Systeme, ja?
Dann frag ich mich, wie das die großen Linux-Distributionen schaffen ihre Lücken zeitnah zu fixen. Und das ist deutlich komplexer und ist nicht mal deren eigene Software.

Finde es ja faszinierend, wie Fanboys hier das Versagen "ihre" Firma verteidigen.

 

[Atkatla]

Komplexe Systeme, ja?
Dann frag ich mich, wie das die großen Linux-Distributionen schaffen ihre Lücken zeitnah zu fixen. Und das ist deutlich komplexer und ist nicht mal deren eigene Software.

Finde es ja faszinierend, wie Fanboys hier das Versagen "ihre" Firma verteidigen.

Faszinierend ist, wie krass du schon konditioniert bist. Man weist dich auf einen Umstand hin, der nicht nur für Cisco gilt, sondern auch für deren Konkurrenten (Fortinet, Palo Alto usw). Und weil du dich nicht inhaltlich mit dem Argument auseinandersetzen kannst oder willst, kommst du mit so unsinnigen Fanboy-Sortierungen? Ironischerweise ist Cisco in "meinen" Netzen seit 10 Jahren aus dem Backbone und den Accessnetzen raus.

Zu deinem "Argument": was soll der Vergleich mit großen Linux-Distributionen? Das was man dir hier gesagt hat war: Cisco hat ein riesiges aufgeblähtes Portfolio mit extrem vielen unterschiedlichen Systemen. Hast du auch nur annähernd eine Vorstellung davon, wieviel verschiedene unterschiedliche Eigenentwicklungen und Open Source Komponenten und Distributionen in den Unterbauten dort in dem Ökosystem involviert sind? Das war doch sogar aus der Liste ersichtlich und du wurdest darauf hingewiesen. Dort kommt die hohe Anzahl der CVEs pro Zeiteinheit her. Sehr viele der Systeme kommen nicht originär von Cisco, sondern wurden durch Firmenübernahmen eingekauft und werden eingebunden.

Wenn du glaubst, dass eine Linux-Distrubition deutlich komplexer sei, als das Ökosystem eines großen Systemausrüsters, dann hast du echt völlig falsche Vorstellungen. Und wieso suggerierst du plötzlich ein Mehr oder Minder an "Zeitnähe" der Fixes? Woran machst du das bitte aus?

Und lass bitte dieses Fanboy-Zeugs. Das ist echt peinlich. Sowas taugt nicht mal als Totschlag-Argument. Denn selbst wenn ein [insert-your-favourite-fanyboy-klischee-hersteller]-Anbeter sagt, dass bei diesem Hersteller etwas ist, wie es ist, hat er immer noch recht, wenn es um etwas faktisches, messbares und nicht um etwas subjektives geht. Die Menge der unterschiedlichen Softwareplattformen eines Ausrüsters ist messbar und die CVE-Menge darauf normalisierbar. Die meisten Laien denken bei Cisco nur an ein paar Router und Switches und das iOS darauf. Aber die Realität ist weit davon entfernt.

Ergänzung (8. Mai 2024)

Mag sein. Aber Cisco nimmt für seine Produkte ja auch ordentlich Geld. Willst Du jetzt ernsthaft da die gleichen Maßstäbe anlegen wie beim China-Router der irgendwie auf nem Hinterhof zusammengeschraubt wurde?

Die Maßstäbe ändern nichts an dem Endergebnis, dass bei SOHO-Systemen die Lücken ungepatcht bleiben, weil der Billig-hersteller dir keine neue Firmware mehr gibt, sondern will, dass du ein neues Gerät kaufst oder unentdeckt bleiben, weil keine eigenen Tests gefahren werden. Und selbst wenn du Maßstäbe anlegst: die Billigsysteme haben eine deutlich geringere Komplexität, sowohl in der Software (was die alles kann) als auch im Portfolio. D.h. auch eine TP-Link u.ä. hat Kapazitäten Lücken zu schliessen. Wenn dort aber die Hardware keine neue Firmware mehr bekommt, dann besteht genau das genannte Problem. Es gibt hier nur wenige positive Ausnahmen, wie AVM. Kannst ja mal schauen, ob das so bleibt wenn die übernommen wurden. Alle großen Systemausrüster hingegen fahren interne Tests um Lücken möglichst schnell zu finden, bevor sie jemand externes findet. Auch wenn die Lücke intern gefunden und gefixt wird, wird das Ergebnis dennoch publiziert und geht in CVE.

long story short: Es gibt keinen Grund, die Sicherheit des genannten 2700 AP deswegen herabzureden, weil er von Cisco ist. Da Problem ist, dass er von der Softwareversorgung abgeschnitten und das Produkt EoL ist.

 

[andy_m4]

Man weist dich auf einen Umstand hin, der nicht nur für Cisco gilt, sondern auch für deren Konkurrenten (Fortinet, Palo Alto usw).

Mag ja sein. Aber hier geht es nun mal um Cisco und nicht um irgendwelche anderen Firmen.

Und weil du dich nicht inhaltlich mit dem Argument auseinandersetzen kannst oder willst, kommst du mit so unsinnigen Fanboy-Sortierungen?

Lustig das Du das sagst und gleichzeitig das Argument mit den hardcoded Credentials komplett ignorierst.
Mir ist natürlich klar, warum. Weil das das mit nichts relativieren oder gar schönreden lässt.
Das ist einfach ein Epic Fail. Das ist so, als wenn Du ein Auto kaufst und dann ab und an mal die Bremsen nicht funktionieren. Wie gesagt: Wenn das EINMAL passiert, ok. War vielleicht ne Debug-Schnittstelle und die haben sie vergessen im Release rauszupatchen. Aber wenn das ein paar Mal vorkommt, dann spricht das dafür das es entweder Absicht ist oder der Entwicklungsprozess im Eimer ist. Beide Möglichkeiten sind sehr schlecht und disqualifizieren die Produkte.

Zu deinem Argument: was soll der Vergleich mit großen Linux-Distributionen?

Naja. Um den Argument der komplexen Software und des riesigen Portfolios entgegen zu treten. Das Problem ist halt nicht Cisco-Exklusiv. Und wirklich was dagegen setzen konntest Du ja auch nicht.

Sehr viele der Systeme kommen nicht originär von Cisco, sondern wurden durch Firmenübernahmen eingekauft und werden eingebunden.

Das zählt wohl kaum als Argument. Das war ja dann den ihre Entscheidung. Wenn die sich so viel an Land ziehen aber gleichzeitig nicht in der Lage sind sich darum adäquat zu kümmern, warum machen sie es dann?
Mir ist ehrlich gesagt ne Firma lieber, die ein kleines Portfolio hat aber die Produkte funktionieren dann auch.

Wenn du glaubst, dass eine Linux-Distrubition deutlich komplexer sei, als das Ökosystem eines großen Systemausrüsters, dann hast du echt völlig falsche Vorstellungen.

Naja. Es ist schon ziemlich herausfordernd eine Linux-Distribution zu bauen. Heutzutage ist das vielleicht nicht mehr ganz so dramatisch, weil sich Prozesse etabliert haben und sich gewisse Dinge eingeschliffen haben und auch die Koordination verbessert hat. Trotzdem bleibt das Grundproblem: Du hast eine große Menge eigentlich unabhängiger Software die Du zu einem lauffähigen, möglichst fehlerfreien System zusammenbauen musst.
Und was das bedeutet, davon kann man sich mal überzeugen, wenn man mal durch die entsprechenden Mailinglisten und Bugtrackern schaut.

Und was man halt auch sagen muss ist, das Cisco (und von mir aus auch die anderen Hersteller) auch Opfer ihre selbstgeschaffenen Komplexität sind. Da wurde ja Feature um Feature eingebaut und klar steigt damit auch die potentielle Anfälligkeit für Bugs. Tragisch dabei ist, das viele der Features von vielen auch gar nicht gebraucht werden. Nur kriegt man ja auch kaum noch wirklich einfachen Geräte.
Das heißt, das ist auch ein stückweit bewusste Produktpolitik: Features bauen um Verkaufsargumente zu haben, auf Kosten der Sicherheit.

Kurzum: Komplexität ist ein schlechtes Zeichen und i.d.R. auch selbst verursacht. Wenn Du argumentierst, das die Situation bei Cisco komplex ist, dann ist das ein Argument GEGEN Cisco und nicht umgekehrt.

Die Maßstäbe ändern nichts an dem Endergebnis, dass bei SOHO-Systemen die Lücken ungepatcht bleiben

Was hast Du bloß immer mit SOHO? SOHO ist sowas wie der Plaste-Router, den man von seinem Provider dazu kriegt, wenn man Internet bestellt. Das vergleichst Du jetzt ernsthaft mit Profi-Geräten von Cisco???
Das ist so, als würde ich Mercedes herumkritisieren und Du kommst dann mit nem klapprigen Trabant um die Ecke um zu belegen, das es ja noch schlimmer geht.

Und lass bitte dieses Fanboy-Zeugs. Das ist echt peinlich.

Naja. Das sind Erklärungsversuche. Wenn man ein solches Gebaren wie das von Cisco verteidigt, da gibts halt nicht so viele rationale Argumente. :-)

Wenn dort aber die Hardware keine neue Firmware mehr bekommt, dann besteht genau das genannte Problem.

Wie gesagt. Der Plasterouter vom Grabbeltisch kostet aber auch nur 30€
Und bei den Billig-Routern hab ich sogar noch ne relativ gute Chance irgendwie ein Linux zu installieren und mir dann darüber Updates und Funktionalität zu holen.
Cisco war da immer recht zugeknöpft. Das heißt, wenn ich (teuer) Cisco kaufe hab ich nicht mal die Option ggf. mein eigenes System zu installieren.

Alle großen Systemausrüster hingegen fahren interne Tests um Lücken möglichst schnell zu finden, bevor sie jemand externes findet.

Das scheint ja nur semi-gut zu funktionieren, wenn man sieht, wie viel da noch durch rutscht.

Auch wenn die Lücke intern gefunden und gefixt wird, wird das Ergebnis dennoch publiziert und geht in CVE.

Das wird ja nicht publiziert, weil die so nett und transparent sind, sondern weil es ungleich schwerer geheimzuhalten ist, wenn erst mal ein Patch da ist. Außerdem sind sie teilweise durch Regulierungen auch dazu gezwungen.

Und das ganze ist noch weit weg von dem, was so unter Open-Source Standard ist, wo so ziemlich der gesamte Prozess transparent ist. Wo man dann auch nachvollziehen kann, welche Lücke wann entdeckt wurde und wie schnell gefixt worden ist.

Ganz oft hat man ja auch den Fall in proprietären Systemen das der Hersteller zwar eine Lücke findet aber die erst mal nicht fixt. Klar; sich darum zu kümmern kostet Zeit und Ressourcen, die man ggf. nicht hat, weil man noch andere Dinge machen will (dringendere Bugs oder neue Features). Das könnte man nur in den Griff kriegen, wenn man mehr Ressourcen aufwendet. Aber das Geld will man halt nicht aufwenden, weil es den Gewinn schmälert.

Auf der anderen Seite kann man Cisco ja nun nicht vorwerfen, das sie wenig Gewinn machen. Offenbar wollen sie das lieber einstreichen, statt in Produktqualität zu investieren.

Da Problem ist, dass er von der Softwareversorgung abgeschnitten und das Produkt EoL ist.

Wann war es jemals schon ein Problem, wenn Netzwerk-Produkte keine Softwareupdates mehr bekommen.
Du lieferst selbst Argumente für meinen Standpunkt, zieht aber nicht die Schlüsse daraus.

 

[Evil E-Lex]

Naja. Das sind Erklärungsversuche. Wenn man ein solches Gebaren wie das von Cisco verteidigt, da gibts halt nicht so viele rationale Argumente. :-)

Ich glaube, da hat einfach die Industrie gesiegt, die den Nutzern immer wieder Mantra-artig einredet, dass das ja alles keine Probleme sind, denn Software lässt sich patchen. Schlechte Leistung wurde über Jahrzehnte hinweg soweit normalisiert, dass wir mittlerweile auch Lücken in CPUs schulterzuckend akzeptieren. Es braucht hier dringend einen Kulturwandel und Produkthaftung für Software, sonst hört das niemals auf.

 

[Atkatla]

@andy_m4 Dein Argument mit den Hardcoded Credentials negiert eben nicht die Aussage, dass die hohe Anzahl der CVEs aus der hohen an Anzahl der Lösungen resultiert. Ja, HC sind bad practice. Findest du letztlich bei allen Herstellern an irgendeinem Punkt. Ich habe weder den Einsatz von HC verteidigt, noch habe ich Cisco verteidigt oder empfohlen. Du tust so, als würde ich Cisco verteidigen, obwohl wir selbst zu anderen Ausrüstern gewechselt sind. Hier ging es darum, dass du augenscheinlich nicht verstanden verstanden hattest, warum die CVE-Anzahl so hoch war. Und wenn eine Entwicklungsabteilung einer Lösung eines Konzerns HCs einsetzt, dann kann man nicht auf andere Lösungen schliessen. Wenn du alles in einen Topf wirfst, kommst du zwangsläufig zu falschen Ergebnissen. Es gibt dort kein Memo was sagt, HC ist ok. Da hat einer von den tausenden Ciscoentwicklern eine Abkürzung genommen und es ist aufgeflogen, weils bis zum Release nicht in Ordnung gebracht wurde. Im 11er und im 14er Branch des betroffnen Produktes gab es diese HC nie, nur im 12.5. Es war also nicht mal innerhalb des Produktes die Norm. Warum sollte man jetzt also vom Emergency responder auf Wifi-AccesPoints schliessen?

Deiner Aussage mit den Linux-Distributionen muss man nichts entgegen setzen, denn es war von dir ein Vergleich mit Äpfel und Birnen. Das Ökosystem eines großen Ausrüsters ist um Größenordnugen komplexer, denn dieser hat meist schon in vielen seiner Lösungen verschiedene Betriebssysteme/Distributionen im Unterbau plus Eigenentwicklungen. Und da reden wir noch nicht mal von den Anwendungs- und Schnittstellenebenen, wo dann die eigentlichen Schwachstellen liegen. Es hat keiner gesagt, das das etwas gutes ist. Es ist aber Fakt und Ursache.

Wann war es jemals schon ein Problem, wenn Netzwerk-Produkte keine Softwareupdates mehr bekommen.

Schon immer. Bei Wifi sind abgesehen vom Sicherheitsaspekt gefühlt, die Hälfte aller Issues in den Release Mitigationen von Problemen mit Endgeräte-Wifi-Adapter weil Qualcom, Broadcom Bugs in der Hardware oder Treibern haben.

Wenn ich jetzt wie der Threadersteller ein Wifi für die nächsten Jahre implementieren will und die Wahl zwischen Investiton in was Neues einerseits oder einen Controller um etwas, was bereits EoL und ohne Support ist, weiterzubetreiben andererseits, dann würde ich immer auf das neuere setzen. Denn dies hat dann die längere Lebenszeit. Jetzt einen Controller für einen AP2700 zu suchen wäre eine Investition in etwas, was schon tot ist und käme nur bei absoluter Mittelknappheit in Frage.

 

[andy_m4]

Ich glaube, da hat einfach die Industrie gesiegt, die den Nutzern immer wieder Mantra-artig einredet, dass das ja alles keine Probleme sind, denn Software lässt sich patchen.

Ja. Genau. Software lässt sich problemlos im Feld patchen. Dadurch hat man gar nicht mehr unbedingt den Anreiz, das Software möglichst fehlerfrei ausgeliefert wird.
Und die andere Sache, die immer wieder gesagt wird ist, das Software ja nicht fehlerfrei sein kann. Auch der Spruch hat sich ja weithin etabliert.
Und ja. Fehlerfreie Software gibts nicht. Aber man kann schon sehr viel dafür tun, um bestimmte Fehlerklassen auszumerzen oder zumindest zu minimieren. Und da geschieht insgesamt noch viel zu wenig.

dass wir mittlerweile auch Lücken in CPUs schulterzuckend akzeptieren.

Wobei auch fehlerhafte CPUs gab es schon immer. Inzwischen wird das nur offener kommuniziert als früher. Aber ja. Auch hier hast Du das Problem der wachsenen Komplexität und auch einer gewissen Überoptimierung. Viele problematische CPU-Bugs der vergangenen Jahre resultieren ja einfach daraus, das man extrem auf Performance optimiert.

Es braucht hier dringend einen Kulturwandel und Produkthaftung für Software, sonst hört das niemals auf.

Kulturwandel. Ja. Open-Source geht ja so in die Richtung. Und zwar nicht unbedingt, weil da die Leute rein schauen und Fehler finden und fixen, wie es ja gerne mal dargestellt wird.
Open-Source-Programmierer geben sich vor allem deshalb Mühe, weil da ihr Name dran steht. Außerdem sind es ja auch oftmals Projekte, an denen sie von sich aus Spaß haben. Und Open-Source-Projekte sind auf mitmachen ausgelegt. Das heißt, wenn Du da hingepfuschten Code hast, dann wird kaum einer Lust haben sich daran zu beteiligen.

All diese Effekte hast Du bei Closed-Source eben nicht. Im Gegenteil. Da hast Du Kostendruck und Deadlines. Und wenn Du pfuschst, sieht das auch niemand, weil ist ja closed.

Und ja. Produkthaftung oder andere regulatorische Maßnahmen für kommerzielle Produkte würde vermutlich helfen. In anderen Bereichen haben wir das ja auch (Hygienevorschriften, Bauvorschriften usw. usw. usw.). Der Softwaremarkt ist da aber immer noch ziemlich wenig reguliert. Und ob wir uns das noch leisten können angesichts dessen, das Software heutzutage so wichtig ist (und künftig noch wichtiger werden wird) ist fraglich.

Ergänzung (8. Mai 2024)

Dein Argument mit den Hardcoded Credentials negiert eben nicht die Aussage, dass die hohe Anzahl der CVEs aus der hohen an Anzahl der Lösungen resultiert.

Soll es auch gar nicht. Weil das kein Argument ist, was sich auf die Anzahl der Lücken bezieht, sondern auf die Schwere der Lücken.
Um mal beim Autovergleich zu bleiben: Wenn ein Rad während der Fahrt abfällt wiegt das schwerer, als wenn das Autoradio zickt.

Ja, HC sind bad practice. Findest du letztlich bei allen Herstellern an irgendeinem Punkt.

Bei Cisco war das schon auffallend häufig. Aber wie gesagt, hab ja auch nirgends behauptet das Fortinet besser wäre. Dort sind hardcoded Credentials natürlich genauso schlimm wie bei Cisco.

Du tust so, als würde ich Cisco verteidigen, obwohl wir selbst zu anderen Ausrüstern gewechselt sind.

Das kommt vielleicht von Deiner Schönrederei. :-)

Hier ging es darum, dass du augenscheinlich nicht verstanden verstanden hattest, warum die CVE-Anzahl so hoch war.

Wie gesagt: Es ging nicht nur über die Anzahl der Lücken. Da kann man natürlich immer sagen: Wenn man viele Prdoukte hat, sieht es gemittelt dann doch nicht mehr so schlimm aus. Aber es geht auch um die Schwere der Lücken.

Und wenn eine Entwicklungsabteilung einer Lösung eines Konzerns HCs einsetzt, dann kann man nicht auf andere Lösungen schliessen.

Trotzdem hat man ja eine übergeordnete Instanz die sich um alles kümmern sollte(!). Damit man halt keine Schrott-Entwicklungsabteilungen in der Firma hat. Wenn also die Qualität von Entwicklungsabteilung zu Entwicklungsabteilung so unterschiedlich ist, dann ist es ja doch irgendwo ein Problem bei Cisco.
Sonst würden die das ja irgendwann mal gerade ziehen. Und wie gesagt, das mit den Lücken ist ja jetzt nicht erst seit ein paar Jahren so. Wo man sagen kann, das auch mal Dinge schieflaufen können. Das zieht sich schon über mehrere Jahrzehnte. Und dann liegt schon der Schluss nahe, das irgendwas Konzernintern nicht stimmt.

Mal abgesehen davon kann es ja auch nicht meine Aufgabe sein als Kunde erst mal zu recherchieren, welche Prdoukte von welcher Entwicklungsabteilung betreut werden und akzeptable Qualität haben und welche nicht.
Hier könnte übrigens Cisco selbst Transparenz zeigen, in dem man das einfach an die Produkte dran schreibt.
Tun sie aber auch nicht. Wie man es dreht und wendet, es sieht nicht gut für Cisco aus.

Das Ökosystem eines großen Ausrüsters ist um Größenordnugen komplexer, denn dieser hat meist schon in vielen seiner Lösungen verschiedene Betriebssysteme/Distributionen im Unterbau plus Eigenentwicklungen.

Du meinst, die Cisco-Produkte sind eigentlich ok , aber die Komponenten anderer Hersteller triggern Bugs in den Cisco-Produkten? Dann ist das trotzdem Ciscos Problem, weil kaputter Input nicht dazu führen darf, das etwas down geht oder gar exploited wird. Diese triviale Erkenntnis sollte sich doch langsam mal durchgesetzt haben.

die Hälfte aller Issues in den Release Mitigationen von Problemen mit Endgeräte-Wifi-Adapter weil Qualcom, Broadcom Bugs in der Hardware oder Treibern haben.

Du versuchst abzulenken. Es geht nicht um Issues weshalb dann plötzlich der USB-Wifi-Dongle mit dem Cisco-AP nicht zusammenarbeitet.
Und ja. Was Qualcom und Broadcom oder auch Realtek da teilweise abliefern ist unterirdisch. Und ja, wenn es da z.B. Probleme mit instabilen Verbindungen etc. gibt, ist das deren Schuld.
Nur ist das nicht das Thema.