News CPU-Sicherheitslücken: Intel kämpft zum dritten Mal mit ZombieLoad

[aldaric]

Warum sollte sich irgendjemand hinstellen und sagen, dass sie Sicherheitslücke X ausgenutzt haben ?

 

[Silverangel]

Es gibt ja nicht nur die Täter

 

[Pocketderp]

Es gibt ja nicht nur die Täter

Denkst du man hätte Spectre, Zombieload oder Meltdown so gut beschreiben können weil die Experten dahinter via Malstift das als Bild gefasst haben?

 

[Silverangel]

Du weisst schon, wie diese Lücken häufig entdeckt und "erarbeitet" werden?
Das vorhandensein und dass Forscher sie entdeckt haben, sagt nichts darüber aus ob es eine aktive und tatsächliche Ausnutzung gibt.
Da sie teilweise nicht "sofort" geschlossen werden, aber man weiß worauf man achten muss/sollte (siehe auch Artikel von @chithanh), wäre zumindest eine teilweise Erkennung von Angriffen möglich.

Zumindest nach dem Artikel (leider ja schon 2 Jahre alt) aber zu dem Zeitpunkt keine tatsächliche Ausnutzung bekannt. (Deswegen auch die Frage nach was aktuellem)

Ich übernehme nicht einfach Blind "Lücke existiert, also wird sie auch dauernd aktiv genutzt". Teilweise ist es ja auch schlicht den Aufwand nicht wert(siehe ebenfalls Artikel).
Vorhandensein≠Ausnutzung

 

[Pocketderp]

Du weisst schon, wie diese Lücken häufig entdeckt und "erarbeitet" werden?
Das vorhandensein und dass Forscher sie entdeckt haben, sagt nichts darüber aus ob es eine aktive und tatsächliche Ausnutzung gibt.

Und wie man erarbeitet man sie? Indem man die CPU höflich fragt? Lücken werden erarbeitet indem man die Lücke erstmalig aktiv ausnutzt, erst dann kann man sie faktisch auch als solche offiziell bezeichnen weil sie bis dato nicht bekannt war. Klingt logisch, oder? Die Experten die dies tun werden diese natürlich auch sauber dokumentieren weil oftmals auch entsprechende Bountyprogramme dran hängen. Und das im speziellen bereits Spectre und Meltdown wild unterwegs waren wurde bereits erwähnt.

 

[Banned]

Zur Wahrheit gehört aber auch, dass man über Spectre eben nicht zielgerichtet Daten abgreifen kann. Man erhält viele Datenfetzen aus der spekulativen Befehlsausführung (das ist zumindest meine Information). Das muss man dann erst mal analysieren. Und da ist das Risiko eben groß, dass man einfach gar nichts Brauchbares findet. Kurz gesagt: Spectre ist viel Aufwand mit wenig Ertragschancen. Da gibt es vielversprechendere Methoden. Und oft braucht man, wie gesagt, sogar noch weitere Berechtigungen mit denen man ohnehin viel mehr anfangen kann.
Ob jemand etwas unter Laborbedingungen nachstellen kann, ist immer die eine Sache; wie es dann in der Praxis aussieht (also nicht nur, ob jemand es kann, sondern auch, ob es wirklich jemand macht), die andere.

Bitte verzeiht mir, dass ich deswegen nicht meine CPU wechsle, weil ich vor Angst keine Auge mehr zu bekomme.

 

[HerrRossi]

Es ist völlig irrelavant, ob die Lücken auch tasächlich ausgenutzt werden. Die gesamte Industrie musste mit den Lücken umgehen, es mussten Patches programmiert werden, es mussten Server und Workstations runtergefahren und gepatcht werden, manche Betriebssysteme haben Hyperthreading sogar gänzlich deaktiviert. Das alles kostet Zeit, Geld, Manpower und Leistung.

 

[KnolleJupp]

Spectre, Meltdown, Zombiload und andere Lücken, die die Out-of-Order Funktionalität betreffen, bewirken das man Daten aus CPU-Cache-Registern rekonstruieren könnte
und bringen erstmal keine unmittelbar konkreten Informationen.
Das sind zusammenhanglose Bits, die alles mögliche darstellen können, interessantes und völlig uninteressantes. Und es sind nur Nullen und Einsen.

Das verstehen viele offensichtlich komplett falsch. Es ist nämlich überhaupt nicht so das man da plötzlich z.B. Passwörter im Klartext lesen könnte o.Ä.
Auch ist es sehr umständlich diese Lücken auszunutzen.

Es gibt natürlich immer irgendwo irgendjemanden, der damit sein Glück versucht.
Und auch wenn die Lücken ärgerlich und unnötig sind, eine unmittelbar konkrete Gefahr geht von ihnen nicht aus. Die Gefahr ist ehr theoretischer Natur.
Damit will ich das Risiko keinesfalls kleinreden. Aber ein wenig mehr Realismus bei der Einschätzung täte vielen ganz gut.

Kritisch zu sehen ist der mit dem Patchen einhergehende Leistungsverlust. Denn die ganzen Funktionen, die diese Lücken aufweisen, dienen einzig dazu die Arbeitsgeschwindigkeit des Prozessors zu erhöhen.
Notwendig, um ein grundsätzliches Funktionieren der CPU zu gewährleisten, sind diese lückenhaften Funktionen nicht.
Zur Not kann man die gesamte Out-of-Order Funktion entfernen, dann ist man aber wieder auf die Arbeitsgeschwindigkeit eines besseren Taschenrechners runter.

Bei Meltdown und Spectre werden Bereiche des Arbeitsspeichers in einen Cache der CPU geladen und dort vorgehalten, von dem die CPU annimmt das sie als nächstes gebraucht werden könnten.
Dabei kann es vorkommen das der Prozess, von dem die CPU annimmt das dieser diese Daten vielleicht brauchen könnte, gar keine Berechtigung hat auf die ausgelesenen Bereiche des Arbeitsspeichers zuzugreifen.
Das wird nicht geprüft.

Selbst wenn die CPU diese Daten anschließend wieder verwirft, weil er eben fälschlicherweise annahm sie würden gebraucht,
kann man aufgrund von sehr umständlichen Laufzeitmessungen Rückschlüsse ziehen welche Daten die CPU gelesen hatte.

Nur was das konkret war, dass weißt du dann immer noch nicht. Es kann zufälligerweise etwas "interessantes" gewesen sein, meist wird das nicht der Fall sein.
Und diese Daten stehen im keinem direkten Zusammenhang, man muss also aufwändig rekonstruieren was diese Daten letztlich darstellen.

Ein Patch sieht z.B. so aus das vorher überprüft wird auf welche Speicherbereiche ein Prozess überhaupt zugreifen darf. Das kostet wertvolle Zeit und verlangsamt die Arbeitsgeschwindigkeit,
weil nun ein weiterer Bearbeitungsschritt nötig ist und diese Information wieder irgendwo vorgehalten werden muss, so dass zusätzlich Platz für anderes verloren geht.

Interessant werden diese Lücken hauptsächlich für Datacenter, wo auf einer Maschine ganz viele Kundendaten laufen.
So könnte theoretisch Kunde A auf Daten von Kunde B zugreifen.

Spectre, Meltdown, Zombiload & Co. sind Glücksspielautomaten. Man kann Glück haben oder, weit wahrscheinlicher, man zieht eine Niete nach der anderen.

 

[Pocketderp]

Das verstehen viele offensichtlich komplett falsch. Es ist nämlich überhaupt nicht so das man da plötzlich z.B. Passwörter im Klartext lesen könnte o.Ä.
Auch ist es sehr umständlich diese Lücken auszunutzen.

Ach, hier mal so vorgeführt, oder hier. Wie praktisch das man auch erst gar nicht zur Tabelle greifen muss um das Binäre umzuwandeln, das macht das Programm gleich allein.

Bitte verzeiht mir, dass ich deswegen nicht meine CPU wechsle, weil ich vor Angst keine Auge mehr zu bekomme.

Und dies hat im speziellen wer verlangt?

 

[KnolleJupp]

Mit Verlaub, aber diese Videos sind Unfug.
Denn dort wird der Cache direkt ausgelesen und die CPU quasi genötigt genau die gewünschten Bereiche zu lesen.

Ich kann natürlich ein einfaches Programm schreiben, in dem sich zwei Threads gegenseitig Daten zuschieben, auf die sie normalerweise nicht zugreifen dürften.
Damit kann ich die Lücke nachweisen. Durch Hyper-Threading und spekulative Sprungvorhersage wird Programmcode vor-ausgeführt, der linear abgearbeitet sofort verworfen worden wäre.
Indem ich die Laufzeiten der Daten analysiere, kann ich Rückschlüsse ziehen welche Daten die CPU gelesen hatte.

Auf einer "richtigen" Maschine hast du aber Null Ahnung welche Bereiche des Arbeitsspeichers die Sprungvorhersage wann liest,
was in diesen Speicherbereichen liegt, wie lange diese Daten im Cache liegen und mit was sie anschließend ersetzt werden,
weil ein Prozess entweder diese Informationen tatsächlich anfordert (gut) oder doch ganz andere (schlecht).

Auf Deutsch nennt man das eine Seitenkanalattacke, indem man nicht eine Funktion selber knackt, sondern Lücken in ihrer Implementierung ausnutzt.

 

[Pocketderp]

Ich kann natürlich ein Programm schreiben, das sich zwei Threads gegenseitig Daten zuschieben, auf die sie normalerweise nicht zugreifen könnten.

Ehm nein, der Prozess sieht in diesen Fall zur Demonstration einen Sende und Empfangsprozess vor, zudem können die jeweiligen Zellen ob im Cache oder ggf im gesicherten Speicher durchaus allokiert werden, klar wird hier in den Beispiel auf einen bestimmten Wert bzw Adresse geprüft um den Vorgang selbst deutlich zu beschleunigen aber selbst dies sollte so gesehen nicht möglich sein. Michael Schwarz (vom dem das Video ist) ist übrigen einer der Entdecker der Lücke, nachzulesen hier. Um Werte in einen Cache und den gesicherten Bereich vorab finden zu können (was ja wie schon geschrieben erst gar nicht möglich sein sollte) reicht es die nach Hit und Miss-Methode der Rechnung bestimmte Werte vorzugeben die dann gleichwohl im Cache und Ram liegen werden bei die CPU nun mal beides vorab berechnet.

 

[KnolleJupp]

Ich will nicht weiter darauf herum reiten und im Grunde hast du Recht, aber du interpretierst zu viel in diesen Proof of Concept.
Auf diese Art kannst du ziemlich einfach das Vorhandensein dieser Sicherheitslücke(n) überprüfen.
Aber mehr auch nicht. Den dazugehörenden Programmcode findest du sogar öffentlich auf Wikipedia.

Mit dieser Methode ist es möglich, nein, falsch formuliert... Das Problem ist das die CPU zum einen Programmcode nicht Zeile für Zeile abarbeitet, sondern Aufgaben parallelisiert
und zum anderen das die Sprungvorhersage nicht prüft welche Berechtigungen ein Prozess hat. Beides dient dazu die Arbeitsgeschwindigkeit der CPU schön hoch zu halten.

Ganz banales und vereinfachtes Beispiel:
Programm darf auf die Speicherbereiche A, B und C zugreifen.

Programm fordert Bereich A an, macht was damit, fordert schließlich Bereich B und C an und macht wieder was damit.
Die CPU könnte sich jetzt vielleicht denken das das Programm auch Speicherbereich D brauchen könnte. Also liest es den Bereich ein und hält ihn im Cache.
Da dieser deutlich schneller gelesen werden kann als der Arbeitsspeicher, kann das Programm auf diese Weise schneller mit den vielleicht verlangten Daten versorgt werden.

--> Dummerweise liegt in Bereich D aber zufälligerweise das gerade eingegebene Passwort für... irgendwas.

Im Programmcode steht sogar das nur auf die Bereiche A, B und C zugegriffen werden darf.
Dummerweise wird das Programm aber komplett eingelesen und mehreren Threads zugewiesen.

--> Während Thread 1 zufällig bereits in vorauseilendem Gehorsam Speicherbereich D gelesen hat,
hat Thread 2 den Programmcode noch nicht so weit abgearbeitet das bemerkt worden wäre das Bereich D tabu ist.

Anhand von komplizierten Berechnungen kann man rekonstruieren welche Informationen die CPU eingelesen hatte,
selbst wenn der Cache bereits vom nächsten Informationshappen überschrieben wurde.

Nur hast du keinen Einfluss darauf was die spekulative Sprungvorhersage der CPU macht. Und das meinte ich mit Glücksspielautomat.

 

[Pocketderp]

Hehe, alles gut, ich wollte dir auch nicht zu nahe treten.

 

[Kacha]

@Kacha

Side-canel-Attacken funktionieren nur Programm- bzw. Prozess-Intern.

Deshalb ist ein Zugriff von einem auf ein anderes Tab (in einem Browser) auch nicht mehr möglich, wenn beide in einem jeweils eigenen Prozess laufen.

Das stimmt so nicht ganz. Das ist ja der Spass mit HT. Du kannst Sachen im kompletten Kern rausfinden, auch wenn dein Prozess nur im HT Teil laeuft. Intel hat da einen ganz schoenen Haufen Mist fabriziert.

Außerdem: Woher weißt du, dass AMDs Architektur von Anfang an auf höchstmögliche Sicherheit setzt? Auf dem Markt zählen zunächst mal nur Zahlen wie also Leistung, Stromverbrauch, Preis, Kühlbarkeit. Damit verdient man Geld und nicht mit dem Versprechen: "Auch in 10 Jahren wird es bei uns keine Sicherheitslücken geben." Denn das glaubt dir eh kaum einer und was in 10 Jahren ist, ist für kaum einen entscheidend bei seinem Kauf.

Schau dir die Architekturen an und was erlaubt ist. Sprungvorhersagen ueber Rechtedomains hinweg macht nur Intel. Andere haben AMD ja auch schon untersucht und AMD macht da wohl einiges richtiger. Natuerlich schliesst das nicht aus, dass man moeglicherweise irgendwann was findet, aber sie geben sich wenigstens Muehe prinzipiell Sicherheit miteinzubeziehen. Von Intel kann man das eben nicht behaupten wenn man so Spaesse wie die Sprungvorhersage so konzipiert.

Es sieht bei Intel tatsächlich so aus, wie du sagst. Aber andererseits hat das eben viele Jahre niemand wirklich gemerkt. Woher willst du jetzt also mit vollster Überzeugung sagen, dass auf der anderen Seite keine Leiche im Keller liegt? Ich halte es nicht für wahrscheinlich, aber 100%ig sagen kann man es eben nicht, außer du gehörst zu dem Team, das den Code geschrieben haben, wovon ich mal nicht ausgehe.

Dass AMD beim SMT einen anderen Weg gewählt hat ist löblich. Anderseits haben sie vielleicht auch einfach die Bombe bei Intel schon ticken gehört.

Intel wurde durchaus gewarnt wie @aldaric zeigt. Die haben es, wie jetzt auch, ignoriert und totgeschwiegen. Intels Reaktionen und die Art der Kommunikation sind grauenvoll. Schon vergessen, dass die Linux Kernel Entwickler erst so grob 4 Wochen vor Veroeffentlichung was von Intel gehoert haben? Obwohl Intel schon seit Monaten informiert war.

Waeren hinter den Veroeffentlichungen 2018 nicht einige grosse gestanden die schoen die Glocken gelaeutet haben, waere es gut moeglich, dass Intel das versucht haette unter den Teppich zu kehren. Gut, haben sie auch so versucht und noch ein bisschen mit Dreck um sich geschmissen. Gegen Intels PR hilft einfach nur PR und einige sind trotzdem taub.

@KnolleJupp Deine Erklaerung in aller Ehren, aber auch du versuchst es zu relativieren und erachtest die Leistungsverluste als schlimmer. Der Hauptgrund warum Spectre weniger ein Problem ist sind die Browserhersteller, die Mitigationen implementiert haben, die das Auslesen massiv erschweren. Das was du fuer Meltdown beschreibst ist zwar prinzipiell richtig, aber zum einen hat es nur Intel geschafft so schlecht an Sicherheit zu denken, dass Rechtedomains ignoriert werden, zum anderen ist dein letzter Satz falsch. Es gibt Wege die Sprungvorhersage zu beinflussen. Intel hat da einiges falsch gemacht.

Wenn du das ganze einsetzen willst, dann so weit gestreut wie moeglich und alles abgreifen was geht. Damit hast du zwar prinzipiell eine niedrige Erfolgschance bei jedem einzelnen Rechner, allgemein duerftest du aber trotzdem einiges rausbekommen. Und das beste? Kein Schwein bekommt es mit. Deswegen sind solche Kommentare wie von @Silverangel auch so frustrierend. Es muss anscheinend erstmal richtig krachen bis man aufwacht. Vielleicht sollten wir Forschern empfehlen das ganze erstmal an den meistbietenden Kriminellen mit PoC und Anleitung zu verkaufen damit einigen klar wird, dass das ganze doch auch sie selbst betreffen kann. Zum Glueck gibt es die Patches und zum zwingen es die meisten Hersteller auf.

 

[KnolleJupp]

Schau dir die Architekturen an

AMD und Intel arbeiten intern komplett anders, selbst wenn es im Kern die gleiche, uralte x86 Architektur ist.
Und auch AMD nutzt Hyper-Threading - nennt das nur anders - und nutzt umfangreiche Out-of-Order Funktionalitäten, wie eine spekulative Sprungvorhersage uvm.
Am Ende machen beide das gleiche, nur komplett anders umgesetzt.
So kommen auch die teilweise großen Leistungsunterschiede zu Stande, je nach Anforderung an die CPU, selbst bei gleicher Taktrate.

aber auch du versuchst es zu relativieren und erachtest die Leistungsverluste als schlimmer

Nun, ich sehe halt das der Leistungsverlust - selbst wenn er sich in Grenzen hält - immer da ist, das Risiko das die Sicherheitslücken aktiv ausgenutzt werden gibt es aber für manche Nutzer nur theoretisch.

Damit hast du zwar prinzipiell eine niedrige Erfolgschance bei jedem einzelnen Rechner, allgemein duerftest du aber trotzdem einiges rausbekommen.

Da stimmt, man muss schon eine Menge Daten abgreifen und analysieren. Je mehr Daten man so gewinnt, desto höher ist die Wahrscheinlichkeit das was relevantes dabei ist.

Ich relativiere das gar nicht. Ich finde Intel hat da einen ganz schlechten Job gemacht, auf der Suche nach immer mehr Leistung die Sicherheit außer Acht gelassen.
AMD ist da wohl von Anfang an etwas konservativer ran gegangen. Deshalb gibt es die große Vielzahl an Lücken bei AMD eben nicht.

Nichts ist jemals 100%ig sicher. Intel ist nicht dumm, sie werden gewusst haben was sie da fabrizieren. Ich schätze ihre Risikoabschätzung war aber zu schön gerechnet.
Beim Bestreben die Leistungskrone aufzubehalten, war es ihnen dieses Risiko wohl wert.

Jetzt haben wir den Salat. Es betrifft schließlich beinahe alle Intel CPUs der letzten 25 Jahre.
Und Patches sind schön und gut. Aber solange es keine diesbezüglichen Designänderungen an der Architektur gibt, ist man immer auf eine entsprechende Software-Lösung angewiesen.
Und ob die immer für jeden bereitstehen wird, kann niemand garantieren.

Die Lücken zielen auch mehr auf Datacenter, Cloud-Dienste usw. Und die kaufen Rechnerfarmen im Millionenwert und die spüren den Leistungsverlust durch die notwendigen Patches durchaus.
Immerhin kaufen die nur nach Bedarf.

Ich wollte bei dem ganzen nur darauf hinaus das manche wohl meinen das man durch diese Lücken nun irgendwelche Passwörter oder anderes unmittelbar auslesen kann.
Und das ist nicht so! Ja, man kann an solche Informationen kommen, aber nicht "bewusst gesteuert", so nach dem Motto: Jetzt lese ich mal deine Passwörter mit.
Es ist grundsätzlich möglich sensible Daten abzufischen. Aber letztlich bekommt man nur einen Datenhaufen, wo alles mögliche drin sein könnte. Natürlich auch sensible Dinge.

 

[Silverangel]

@Kacha:
Es ist für dich frustrierend, wenn man Nachweise für eine Aussage haben möchte wie viel von der Theorie denn nun wirklich aktuell Praxisrelevant für den Privatanwender ist?

Nach Theorie und "Chancen" hab ich nicht gefragt. Hast du denn Nachweise dazu? Ja? Dann liefer sie doch einfach. Wo ist das Problem? Theoretisieren könnt ihr doch dennoch. Daran bin ich nicht mal interessiert. Weil die Theorie ja überall bei den Themen breitgetreten wird.
Seh halt bisher wie @KnolleJupp es sagt, viel Theorie. Aber irgendwie nix belegtes, dass Privatanwender da jetzt großartig was abbekommen würden.

Also entweder hast du mich nicht verstanden, oder drehst absichtlich was anderes draus.

Eine Wertung des ganzen, egal ob positiv oder negativ (also ob relativieren oder Panikmache) hab ich nämlich (absichtlich) überhaupt nicht gemacht.
Juckt mich nämlich nicht die Bohne auf welcher Seite da wer stehen will.

 

[KnolleJupp]

Hast du denn Nachweise dazu? Ja? Dann liefer sie doch einfach.

Hier muss ich die anderen in Schutz nehmen. Denn das geht so nicht!

Es sei denn es würde allgemein bekannt das die Lücken aktiv ausgenutzt werden. Bis da hin sind das nur theoretische Möglichkeiten.
Man müsste auch erst ein aufwändiges System schaffen das die Daten unbemerkt abfischt, überträgt und analysiert.

Jede Sicherheitslücke, die nicht geschlossen wird, ist letztlich praxisrelevant für jeden oder kann das jederzeit werden.

Ob sich der böse Hacker aber speziell für deinen Spiele-Rechner zu Hause interessiert, ist fraglich. Da gibt es vermutlich dutzende weit einfacher auszunutzende Einfalltore.
Für kommerzielle Dienstanbieter ist das aber unmittelbar kritisch. Denn diese verdienen u.a. Geld mit verbriefter Datensicherheit.

 

[Silverangel]

@KnolleJupp: Wie weiter vorne bereits: Es ist klar, dass nicht alles damit aufgedeckt wird, aber durchaus wissen sie auf was sie (zumindest in teilen) achten müssen. Ergo müsste zumindest in Teilen auch hier und da was auffallen sofern es denn auch wirklich genutzt wird.
Und da ist ja laut dem Heise Artikel dann nichts auffälliges zu dem Zeitpunkt gewesen.(alter hingewiesen und gefragt obs was neueres gibt)
Werden ja auch nicht alle Lücken (zeitnah) geschlossen.
Und dass es einfachere Einfallstore oder Methoden gibt (ebenfalls weiter vorne schon gesagt) steht ja auch im Heise Artikel so drin.

Stehen wir wieder an der selben Stelle wie davor.
"Theorie... schön. Ist mir bekannt. Praxisrelevant für Privatanwender weil es genutzt wird? Und wieder auf Theorie verwiesen."
Merkst was?

Die "Möglichkeit" und "Theorie" interessiert mich kein Stück(kriegste an jeder Straßenecke bald). Verweist aber immer ausschließlich darauf.
Also geh ich von aus, dass dazu nichts belastbares vorhanden ist. Hätte mit einem Satz "Gibts aktuell nichts zu" direkt beantwortet werden können und wäre erledigt gewesen.

 

[KnolleJupp]

Nun, Sicherheitslücken sollten idealerweise geschlossen werden noch bevor sie aktiv ausgenutzt werden. Damit sie keinen Schaden anrichten können.
Wie werden Lücken gefunden? Indem aktiv danach gesucht wird, entweder mit guten oder bösen Absichten oder man zufällig darüber stolpert.
Kein echter Hacker würde jemals damit prahlen. Man kann also gar nicht wissen ob diese Lücken von irgendjemandem ausgenutzt werden.

Was diese speziellen Sicherheitslücken angeht, also Spectre, Meltdown, Zombiload usw. gibt es nichts auf das du achten könntest.
Das betrifft die interne Funktionsweise der CPU.
Genutzte Browser sollten auf einem aktuellen Stand sein, BIOS, Betriebssystem und Antiviren-Software sollten aktuell sein. Mehr kann man diesbezüglich nicht machen.

Hier hilft aktuell nur ein Microcode-Update.
Das entweder über aktualisierte BIOS-Versionen oder über entsprechende Betriebssystem-Treiber beim Start des Rechners (bei jedem Start) in die CPU geladen wird.

Ein Patch auf Hardware-Basis bedingt eine Überarbeitung der Prozessor-Architektur und somit ein Austausch der CPU.

Also geh ich von aus, dass dazu nichts belastbares vorhanden ist.

Bei allem Respekt, halte ich diese Denkweise für naiv.
Ich behaupte zwar das diese Sicherheitslücken nicht für jedermann gleich relevant sind, aber dennoch gibt es sie.

 

[Silverangel]

Ich leugne weder, dass die Lücken existieren, noch dass davon eine Gefahr ausgehen kann. Wieso also naiv?
Wahrscheinlich wie der Rest den ich geschrieben habe (und du mir grad noch mal erzählst): nicht gelesen oder nicht verstanden.

Wenn ihr dann euer Kategorien und schwarzweiß braucht, viel Spaß damit.