HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 113.949
... weiterlesen
TEE, TME und SGX: Intel spricht über die Sicherheit der Icelake-Xeons
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
Intel und Sicherheit. 
Die letzte Lücke "Bleedingtooth" hat Intel seit Monaten für sich behalten, relevante, fertige (!) Patches nicht an die Community weitergereicht.
Intel hat massive Probleme - an allen Fronten.
Die letzte Lücke "Bleedingtooth" hat Intel seit Monaten für sich behalten, relevante, fertige (!) Patches nicht an die Community weitergereicht.
Intel hat massive Probleme - an allen Fronten.
Intel bezahlt Forscher dafür, dass diese Sícherheitslücken in deren Hardware finden. So wo ist das Problem?
Wow, trollst du oder bist du echt nicht einmal in der Lage korrekt wiederzugeben, was in einem Text steht?
- Ist dies keine Intel Sicherheitslücke
- Hat nicht nur Intel die Sicherheitslücke für sich behalten, sondern u.a. auch Google, damit genug Zeit besteht die Lücke zu fixen, bevor diese veröffentlicht wird, was ein völlig normales Vorgehen ist..
- Ist doch gerade ein Teil der Kritik, dass Intel die Lücke zu früh veröffentlicht hat
- Hat Intel die Patches bereitgestellt, aber nicht auf dem vorgesehenen Weg oder die Leute informiert. Wie erklärst du dir sonst, dass diese bei SuSE unwissentlich eingepflegt wurden?
Lustig, dass du mir mangelndes Leseverständnis vorwirfst, aber scheinbar selbst keine Ahnung von dem hast, was du da eigentlich liest.
1. Ich habe nirgends geschrieben, dass das eine "Intel"-Sicherheitslücke wäre. Es geht um Intels Sicherheitspolitik.
2. Du bist absolut null informiert. Intel hat nicht nur Patches zurückgehalten bzw. ungenügend "unter der Hand" informiert - Intel hat auch noch viel zu früh die Lücken an die Öffentlichkeit gebracht.
3. Weil du nicht lesen kannst: Intel hatte die Patches bereits seit Monaten verfügbar (die Lücke besteht wohl seit 2016), aber keine Verteilung für die Distris vorgesehen. Und deswegen JETZT zu früh bekanntgegeben.
4. Exakt - Intel hat NICHT "unter der Hand" - wie das in Sicherheitskreisen üblich ist - die Patches verteilt und dann, wenn alles halbwegs sicher ist, die Öffentlichkeit informiert.
Also, nochmal für dich: wieder einmal präsentiert sich Intel beim Thema "Sicherheit" von seiner absoluten Schokoladenseite. Nicht.
- Wollte nur sicher gehen, dass du das verstehst. Bei dir weiß man da nie
- Google hat die Lücke entdeckt und nicht Intel, aber ich bin 0 informiert.. Ok
- und 4. Intel hat die Patches gepushed aber in den falschen Branch: https://twitter.com/theflow0/status/1316499900251635718
1. Ich habe nie geschrieben, wer die Lücke entdeckt hat.
Wie du immer versuchst abzulenken...2. Intel hat das komplett verbockt, ich zitiere:
Wie unfähig kann man denn sein? Womit wir wieder bei meinem ersten Beitrag wären. Also Dank für deine Bestätigung.
1. Ich habe nie geschrieben, wer die Lücke entdeckt hat.
2. Intel hat das komplett verbockt, ich zitiere:
- Ich versuche nicht abzulenken, nur wirfst du Intel vor, dass diese die Distributoren nicht über die Lücke informiert hätten. Doch ist das auch gar nicht die Aufgabe von Intel, sondern hat Google als Entdecker der Lücke dies getan. Intel hat nur Patches für diese Lücken erstellt.
- Das mit dem Mergen der Patches haben die von Intel verbockt
Der ja nicht wirklich korrekt ist
Der ja nicht wirklich korrekt ist
Was ist denn bitte nicht korrekt?
Dass über bereits verfügbare Patches seit August wiederholt nichts kommuniziert wurde? Dass bekannte Sicherheitslücken nicht weitergegeben wurden?
Ich habe für dich das Finden der Problematik, die hinreichend kompetente Personen der Branche deutlich als solche identifizieren, hier nochmal aufgeführt.
[URL='https://www.golem.de/news/bleedingtooth-aus-fehlern-lernt-intel-nicht-2010-151602.html' schrieb:
[URL='https://www.golem.de/news/bleedingtooth-google-und-intel-warnen-vor-neuen-bluetooth-luecken-2010-151526.html' schrieb:
Meine Güte, was ist daran bitte so schwer zu verstehen?
Es gibt mehrere Lücken, die Intel - durch entdecker Google oder X - hinreichend bekannt gewesen sind, da bereits im August dafür Patches bereitgestellt wurden. Über diese Angriffsflächen wurde die entsprechende Community allerdings nicht informiert. Das ist eine Sache, die in ähnlicher Form bereits mehrfach vorgekommen ist und daher ein Problem.
Easy.
Genau das hier: Die letzte Lücke "Bleedingtooth" hat Intel seit Monaten für sich behalten, relevante, fertige (!) Patches nicht an die Community weitergereicht.
Das ist nicht korrekt, da
- Google die Lücken entdeckt hat und entsprechende Stellen informiert hat
- Intel Patches bereitgestellt hat, aber diese in den next anstatt mainline Branch gemerged hat: https://twitter.com/theflow0/status/1316499900251635718
1. Irrelevant und falsch. Unabhängig davon, von wem die Sicherheitslücke entdeckt worden ist, ist Intel als Urheber verpflichtet, davon in Kenntnis zu setzen, vor allem, nachdem sie in der Vergangenheit wiederholt auf bestehende Infrastruktur diesbezüglich hingewiesen wurden.
2. Exakt. Alle drei Personen in Deinem Twitterlink halten Intel für Intransparenz und NICHT vorhandene Kommunikation verantwortlich. Wird sogar geschrieben, dass Fixes trotz gegenteiliger Behauptung in 5.9 nicht vorhanden waren.
Es ist immer wieder erstaunlich, wie du es schaffst, aus Sätzen plötzlich Inhalte herauszulesen, die da gar nicht stehen.
Intel wusste seit Monaten von der Lücke - das hat rein gar nichts damit zu tun, wer diese Lücke zuerst entdeckt hat.
Intel hat seit Monaten Patches zur Verfügung - das hat rein gar nichts damit zu tun, wer diese Lücke zuerst entdeckt hat.
Die Patches von Intel kamen viel zu spät - und dann auch noch, wie von dir genannt, in die falsche Branch.
Intel hat von der Linux-Kernel-Community eine verschlüsselte Infrastruktur zur Verfügung gestellt bekommen, um genau solche "Probleme" adäquat & schnell an die richtigen Leute zu bringen.
Aber genau das haben sie verzapft.
Und du versuchst mal wieder irgendwo irgendwelche Dinge zu lesen, die nirgendwo geschrieben wurden.
Die Patches wurden im August released, nur halt in den falschen Branch. Dies ist entgegen deiner Behauptung, dass man die relevanten Patches nicht weitergeleitet hätte. Über die fehlende Kommunikation der Verfügbarkeit Patches wird sich beschwert. Den Rest reimt ihr euch da zusammen.
Ich will euch mal nicht weiter dabei stören.
Reimen wir uns zusammen? 
Also wenn dir die Argumente ausgehen, sind wir und ein renommiertes Onlinemedium doof und reimen uns was zusammen.
Zitat:
"Dieses auch als Coordinated Disclosure bezeichnete Prozedere ist ein über Jahrzehnte erprobtes Modell, das meist problemlos funktioniert und eigentlich auch von allen Beteiligten akzeptiert wird. Offenbar hat Intel das System aber immer noch nicht verstanden oder ist einfach nicht willens, Sicherheitslücken wirklich ernst genug zu nehmen.
Zwar hat das Unternehmen bereits vor rund zwei Monaten Patches für die Lücken erstellt, aber allem Anschein nach haben weder Intel noch der bei Intel angestellte Bluetooth-Maintainer diese Patches irgendwie sinnvoll weitergereicht. Dafür hagelt es von vielen Kernel-Entwicklern berechtigterweise teils harsche Kritik.
(...)
Der Linux-Distributor Suse hat dabei unter anderem festgestellt, einen der Patches zufälligerweise schon aus einem anderen Zweig übernommen zu haben - ohne jedoch zu wissen, dass damit eine Sicherheitslücke geschlossen wurde und darauf entsprechend reagieren zu können. Noch mehr Durcheinander geht kaum."
Intel hat es nicht gebacken bekommen. Du brauchst also gar nicht versuchen, uns der Dichtkunst zuzuschreiben, nur weil dir die Argumente ausgehen.
Also wenn dir die Argumente ausgehen, sind wir und ein renommiertes Onlinemedium doof und reimen uns was zusammen.
Zitat:
"Dieses auch als Coordinated Disclosure bezeichnete Prozedere ist ein über Jahrzehnte erprobtes Modell, das meist problemlos funktioniert und eigentlich auch von allen Beteiligten akzeptiert wird. Offenbar hat Intel das System aber immer noch nicht verstanden oder ist einfach nicht willens, Sicherheitslücken wirklich ernst genug zu nehmen.
Zwar hat das Unternehmen bereits vor rund zwei Monaten Patches für die Lücken erstellt, aber allem Anschein nach haben weder Intel noch der bei Intel angestellte Bluetooth-Maintainer diese Patches irgendwie sinnvoll weitergereicht. Dafür hagelt es von vielen Kernel-Entwicklern berechtigterweise teils harsche Kritik.
(...)
Der Linux-Distributor Suse hat dabei unter anderem festgestellt, einen der Patches zufälligerweise schon aus einem anderen Zweig übernommen zu haben - ohne jedoch zu wissen, dass damit eine Sicherheitslücke geschlossen wurde und darauf entsprechend reagieren zu können. Noch mehr Durcheinander geht kaum."
Intel hat es nicht gebacken bekommen. Du brauchst also gar nicht versuchen, uns der Dichtkunst zuzuschreiben, nur weil dir die Argumente ausgehen.
Dir ist aber schon bewusst, was IMHO bedeutet und wie sich das von einem Artikel abgrenzt?Also wenn dir die Argumente ausgehen, sind wir und ein renommiertes Onlinemedium doof und reimen uns was zusammen.
Falls nicht, steht unter dem Kommentar, denn das ist, was du verlinkt hast
Ach und dass Onlinemedien öfters mal Sachen falsch interpretieren, ist in der Vergangenheit schon oft genug vorgekommen. Daher sollte man immer ziemlich vorsichtig bei der Betrachtung von sekundär Quelle sein.
Hä, ich schreibe doch selber von schlechter Kommunikation bzgl. der Patches und mergen in den wohl nicht dafür vorgesehenen Branch. Alles darüber dichtet ihr euch zusammen.
Zuletzt bearbeitet:
Wir reimen uns zusammen, dass Intel an der Stelle vollkommen unfähig agiert hat?
Das sieht fast die komplette Linux-Kernel-Community so. Dermaßen stümperhaftes Vorgehen von einer Branchengröße wie Intel wirft ein ganz schlechtes Licht auf Intels Sicherheitsgebahren.
Und genau dieses Licht steht seit Meltdown & Co. ziemlich schief.
Das sieht fast die komplette Linux-Kernel-Community so. Dermaßen stümperhaftes Vorgehen von einer Branchengröße wie Intel wirft ein ganz schlechtes Licht auf Intels Sicherheitsgebahren.
Und genau dieses Licht steht seit Meltdown & Co. ziemlich schief.
Hier machst du es doch direkt wieder ->
Weil diese auch nur aus 2-3 Leuten besteht. Alles klar
Die meisten haben sich dazu bis jetzt nicht einmal geäußert...
Ist auch nur etwas, was der Meinung des Autors in seinem Kommentar zu der Angelegenheit entspricht. 🤷♂️
Hauste!
Habe besseres zu tun
Genau.
Mit der kleinen unbedeutenden Tatsache, dass dessen Meinung sekundiert wird u.A. von einem Google-Sicherheitsforscher und einem der prominentesten Linux-Kernel Entwickler. Kann man ja getrost vernachlässigen!
Mhm, und übrigens:
Die Patches sind wohl entgegen kolportierter Meldung Intels in 5.9 immer noch nicht verhanden, sondern benötigen nun 5.10, das Dez. 2020 releast werden soll.
Bravo, Intel!
Der Paddy92 versucht, wie immer, die Aussagen anderer als haltlos oder unwichtig dastehen zu lassen. Komme ihm gar nicht erst mit Fakten. Insbesondere die bedeutungslosen Forscher bei Google oder Entwickler in der Linux Kernel Community haben doch gar keine Ahnung im Vergleich zu Paddy92.
Nur hat dieser nichts verlauten lassen, was auf die Aussage von dem Autor - obwohl Intel seit den Meltdown-Lücken nicht nur unter kritischer Beobachtung der Linux-Kernel-Community steht - schließen lässt. Dies kommt lediglich von dem Autor.
Nein 5.10 wird nicht benötigt, sondern können die Patches auch für ältere Kernels backported werden.
Du bringst ja keine Fakten 🤷♂️
Nichts weiter als Polemik.Insbesondere die bedeutungslosen Forscher bei Google oder Entwickler in der Linux Kernel Community haben doch gar keine Ahnung im Vergleich zu Paddy92.
Äh, doch? Nur weil Du das nicht wahrhaben willst, heißt es nicht, dass das nicht der Realität entspricht.
Grag Kroah-Hartman schrieb:
Nein 5.10 wird nicht benötigt, sondern können die Patches auch für ältere Kernels backported werden.
Stimmt nicht generell. Gilt nur für: 5.9.1, 5.8.16, 5.4.72, 4.19.152, 4.14.202, 4.9.240. Zumal das ganze erst seit knapp einer Woche der Fall ist. 5.9 wurde vor einer Woche releast. 5.9.1 ist zum Zeitpunkt meines Posts wie alt? Drei Tage? Ok, konzessiert.
Ändert absolut nichts daran, dass der Fuck-Up seit Bekanntwerden auf ganzer Linie bei Intel lag.
Das wurde und wird weiterhin - zu Recht - kritisiert.
Zuletzt bearbeitet:
Nein?
Der von mir hervorgehobene Part wurde auch nicht in dem Zitat genannt, welches du herausgesucht hast.
Da wird nur aufgelistet welche stable Kernels ein Update mit den Patches erhalten haben und nicht, wo dies möglich ist.
Paddy92, dein ganzes Palaver ändert nichts daran, dass sowohl Google als auch die Linux-Kernel-Entwickler das Verhalten Intels kritisieren.
Zurecht. Nicht umsonst hat man für Intel eine Infrastruktur geschaffen, die Intel einzig für diesen einen Zweck nutzen konnte und sollte.
Und was die Patches angeht - Intel hat die kommunizierte Verteilung viel zu spät gestartet. Dass sie die Patches teilweise etwas früher ohne Kommunikation auf falschen Wegen verteilt haben, macht die Sache an der Stelle überhaupt nicht besser, siehe SuSE.
Und das sind beides Fakten, die von Google und den Entwicklern kommuniziert werden. Aber du willst sie ja nicht wahrhaben. So viel zu deiner nächsten Ablenkungstaktik, ich würde keine Fakten liefern.
Das Einzige, was du kannst, sind deine Versuche, die Aussagen anderer zu zerreden. Erfolglos wie man sieht.
Zurecht. Nicht umsonst hat man für Intel eine Infrastruktur geschaffen, die Intel einzig für diesen einen Zweck nutzen konnte und sollte.
Und was die Patches angeht - Intel hat die kommunizierte Verteilung viel zu spät gestartet. Dass sie die Patches teilweise etwas früher ohne Kommunikation auf falschen Wegen verteilt haben, macht die Sache an der Stelle überhaupt nicht besser, siehe SuSE.
Und das sind beides Fakten, die von Google und den Entwicklern kommuniziert werden. Aber du willst sie ja nicht wahrhaben. So viel zu deiner nächsten Ablenkungstaktik, ich würde keine Fakten liefern.
Das Einzige, was du kannst, sind deine Versuche, die Aussagen anderer zu zerreden. Erfolglos wie man sieht.
@Paddy92 der gute Fortunes möchte doch nur hören, wie schlimm dieser Fehler von Intel war. Auch wenn ein Entwicklerteam dort mal menschliche Fehler macht und sich nicht an die allgemein bekannte FOSS Netiquette hält, zeigt das doch nur die pöhsen Machenschaften des Halbleitergiganten-Komplexes. Weitermachen !...
Dagegen sage ich doch nichts. Ich korrigiere lediglich deine überspitzten Aussagen.
Nur war deine anfängliche Behauptung, dass Intel die Patches zurückgehalten hätte. Das ist etwas anderes als -> Patches verteilt, aber in falschen Branch..
Klar, deswegen springst du auch von der über dramatisierten Aussage - Patches zurückgehalten - zu - Patches verteilt, aber falsch.
Wenn du also schon von Fakten redest, dann halte dich doch an diese und gib die nicht falsch wieder. Es kann so einfach sein...
Und noch einer, der wissentlich verschweigt, dass man für Intel eine separate, verschlüsselte Infrastruktur geschaffen hat, um genau solche Fehler zu umschiffen.
Weit weg von "allgemein bekannter FOSS Netiquette". Also einfach mal bei der Wahrheit bleiben, gelle?
Beitrag automatisch zusammengeführt:
Nochmal nur für dich:
Zitat:
"Zwar hat das Unternehmen bereits vor rund zwei Monaten Patches für die Lücken erstellt, aber allem Anschein nach haben weder Intel noch der bei Intel angestellte Bluetooth-Maintainer diese Patches irgendwie sinnvoll weitergereicht. Dafür hagelt es von vielen Kernel-Entwicklern berechtigterweise teils harsche Kritik."
Nicht (sinnvoll) weiterreichen nennt man auch zurückhalten. Und das obwohl Intel eine eigene, verschlüsselte Infrastruktur für exakt solche Situationen bekommen hat.
Ich bin ja nicht der einzige, der das so anprangert. Jeder, der auch nur im Entferntesten mit der Betreuung einer Linux-Umgebung betraut ist, kotzt gerade so richtig.
Noch einmal für dich: Du zitierst einen IMHO-Kommentar, welchen golem explizit von den eigentlichen Artikeln abgrenzt. Das ist einfach nur die Meinung von einem Schreiberling, der sich da was aus Tweets zusammen reimt. Der ist nicht einmal in der Position zu beurteilen, ob die Verteilung wirklich sinnvoll war.
Noch einmal für dich: Die Patches wurden weitergereicht und das schon im August
https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-1-luiz.dentz@gmail.com/
https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-2-luiz.dentz@gmail.com/
https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-3-luiz.dentz@gmail.com/
https://lore.kernel.org/linux-bluetooth/20200806181714.3216076-4-luiz.dentz@gmail.com/
https://git.kernel.org/pub/scm/linu.../?id=a2ec905d1e160a33b2e210e45ad30445ef26ce0e
Es wird sich lediglich die schlechte Kommunikation kritisiert.
Dafür melden sich aber ziemlich wenig Leute zu Wort. Nicht einmal die größte Heulsuse Torvalds heult rum, wie er es doch sonst immer tut....
Du hast anscheinend noch nie in einer großen Unternehmung gearbeitet, oder (DAX-Konzern) ? Da weiß oft Department A nicht was Department B macht, es kann also gut möglich sein, dass die Abteilung, die für Bluetooth Entwickung verantwortlich ist, noch keinen Schimmer von dieser verschlüsselten Infrastruktur (was auch immer das sein mag) gehabt hat. Das färbt natürlich auf die ganze Firma ab, das ist klar, aber das hat möglicherweise nix mit den sonstigen Fixes bzw. CPU Flaws zu tun.
Du machst wieder aus einer Mücke einen Elefanten, wie sonst auch, wenn es um Intel und Sicherheitslücken, oder angebliche Benachteiligungen von Mitbewerbern geht.
Jo stimmt, Bluetooth ist bestimmt in vielen Server/Container-Farmen verbaut, oder nutzen heute echt schon die meisten Firmen Linux als reguläre MA-Plattform ?
Und es geht lustig weiter:
Sogar die Schutztechnik KASLR kann überlistet werden. Patches beheben den normalen Nutzerzugriff, ein Root-Zugriff ist aber weiterhin möglich. Dagegen helfen nur Microcodes - die für Haswell und älter nicht mehr kommen dürften.
Intel und die Sicherheit.
Sogar die Schutztechnik KASLR kann überlistet werden. Patches beheben den normalen Nutzerzugriff, ein Root-Zugriff ist aber weiterhin möglich. Dagegen helfen nur Microcodes - die für Haswell und älter nicht mehr kommen dürften.
Intel und die Sicherheit.
