HWL News Bot
News
Thread Starter
- Mitglied seit
- 06.03.2017
- Beiträge
- 113.975
... weiterlesen
AMDs Platform Security Processor ebenfalls von Lücke betroffen
- Ersteller HWL News Bot
- Erstellt am
... weiterlesen
NasaGTR
Enthusiast
- Mitglied seit
- 12.05.2013
- Beiträge
- 7.882
Die Überschrift ist ziemlich schlecht gewählt.
Im aktuellen News Umfeld suggeriert die, dass der PSP auch von Meltdown oder Spectre betroffen ist, dabei hat die Lücke ein ganz anderes Thema und gehört eher in die Ecke zu "geheimen Sicherheitszeug was nicht sicher ist" - ähnlich wie Intel ME.
Macht die Sache natürlich nicht weniger schlimm/unschön.
Im aktuellen News Umfeld suggeriert die, dass der PSP auch von Meltdown oder Spectre betroffen ist, dabei hat die Lücke ein ganz anderes Thema und gehört eher in die Ecke zu "geheimen Sicherheitszeug was nicht sicher ist" - ähnlich wie Intel ME.
Macht die Sache natürlich nicht weniger schlimm/unschön.
DragonTear
Legende
Sowas ist im Endefekt an den Programmiersprachen geschuldet. Es gibt auch kompilierbare Sprachen, welche Bufferoverflows prinzipiell aussschließen können und generell mit Daten nachvollziehbarer umgehen.
Rust ist so eine. Go auch (wobei die wohl für diese Anwendung weniger geeignet ist).
Leider ist die gesamte Industrie mangels Entwickler, immer noch bei Sprachen aus den 90ern oder gar 70ern als Effizienz, das allerhöchste Gebot hatte...
Naja, zumindest ist dieses Problem softwareseitig komplet behebbar, allerdings ist es in der Tat ein Problem dass nur ein bruchteil der Nutzer, Biosupdates durchführen.
Rust ist so eine. Go auch (wobei die wohl für diese Anwendung weniger geeignet ist).
Leider ist die gesamte Industrie mangels Entwickler, immer noch bei Sprachen aus den 90ern oder gar 70ern als Effizienz, das allerhöchste Gebot hatte...
Naja, zumindest ist dieses Problem softwareseitig komplet behebbar, allerdings ist es in der Tat ein Problem dass nur ein bruchteil der Nutzer, Biosupdates durchführen.
drakrochma
Enthusiast
AMD ist von Meltdown betroffen?
Hatte ich bisher anders verstanden.
Oder stimmt da im Text was nicht?
Der Text gehört wohl in die Kategorie Intel-FUD:
1. AMD ist von Spectre betroffen, Meltdown ist nur Intel
2. Für die Lücke braucht es bereits Administratorrechte. Das bedeutet, man kann ein bereits übernommenes System noch ein bisschen mehr übernehmen. Ist immer noch eine Sicherheitslücke - aber verglichen mit so manch anderem nicht so kritisch.
3. Hat NICHTS mit Meltdown oder Spectre zu tun. Eigentlich nicht mal wirklich mit den Prozessoren. Sollte leicht zu fixen sein und wird im Zuge des Fixes keine Leistungseinbußen mit sich bringen.
1. AMD ist von Spectre betroffen, Meltdown ist nur Intel
2. Für die Lücke braucht es bereits Administratorrechte. Das bedeutet, man kann ein bereits übernommenes System noch ein bisschen mehr übernehmen. Ist immer noch eine Sicherheitslücke - aber verglichen mit so manch anderem nicht so kritisch.
3. Hat NICHTS mit Meltdown oder Spectre zu tun. Eigentlich nicht mal wirklich mit den Prozessoren. Sollte leicht zu fixen sein und wird im Zuge des Fixes keine Leistungseinbußen mit sich bringen.
L
lll
Guest
Das ist wohl die Zeit wo man Lücken entdeckt, prinzipiell eigentlich gut, jetzt sollten so viele wie nur möglich Lücken suchen, den alten Mist der schon lange untersucht gehört.
Das ist gar nicht so unwichtig, wer kennt diese Lücken, höchstwahrscheinlich die Geheimdienste und ein erlauchter Kreis von Hackern die echt gut sind, keines der beiden würde ich Lücken anvertrauen wollen.
Je länger eine Lücke vorhanden desto wahrscheinlich ist es das sie wer kennt, Geheimdienstchefs verkaufen doch lieber ihre Großmutter an den Feind als so gute Lücken stopfen zu lassen, denen ist egal wenn das Kriminelle auch wissen, Hauptsache sie kommen schneller an ihre geliebten Daten die sie klauen.
Gibt es überhaupt eine Statistik die zeigt, wie viele Prozent bei einer derartigen Sicherheitslücke ihr BIOS aktualisieren (können)?
Das hängt sicher auch damit zusammen wie viele dies überhaupt mitbekommen, wer kein "Nerd" ist beziehungsweise regelmäßig bei Seiten wie HWL liest, registriert dies nicht einmal.
Das ist gar nicht so unwichtig, wer kennt diese Lücken, höchstwahrscheinlich die Geheimdienste und ein erlauchter Kreis von Hackern die echt gut sind, keines der beiden würde ich Lücken anvertrauen wollen.
Je länger eine Lücke vorhanden desto wahrscheinlich ist es das sie wer kennt, Geheimdienstchefs verkaufen doch lieber ihre Großmutter an den Feind als so gute Lücken stopfen zu lassen, denen ist egal wenn das Kriminelle auch wissen, Hauptsache sie kommen schneller an ihre geliebten Daten die sie klauen.
Als ich BIOS Update gelesen hatte, habe ich sofort gedacht "Uff, das Sicherheitsrisiko bleibt bei den meisten bestehen".Artikel schrieb:
Gibt es überhaupt eine Statistik die zeigt, wie viele Prozent bei einer derartigen Sicherheitslücke ihr BIOS aktualisieren (können)?
Das hängt sicher auch damit zusammen wie viele dies überhaupt mitbekommen, wer kein "Nerd" ist beziehungsweise regelmäßig bei Seiten wie HWL liest, registriert dies nicht einmal.
DragonTear
Legende
Das halte ich dann doch ein wenig für Vorurteil >_>
In diesen Bereichen arbeiten auch nur Mesnchen. In aller regel wohl sehr patriotische Menschen, aber trotzdem.
Ja, da wärs schön wenn die Firmen mit Microsoft zusammenarbeiten würden, um ein Popup für diesen Zweck an zu zeigen.
Zuletzt bearbeitet:
Nimm es mir nicht übel, aber du hast du Ausmaße einer solchen Lücke nicht verstanden.
Der Code läuft dann innerhalb der PSP und ist für den Nutzer / das System _nie_ zu sehen oder zu erkennen. Eine Malware, die sich dort eingräbt, kann man nicht finden. Das ist der heilige Gral, quasi Ring -3.
Zuletzt bearbeitet:
Dann mal für dich ein kurzer Realitätsabgleich: Cyber-Waffen - NATO aktiv bei bislang verbotenen digitalen Angriffsarten
Was meinst du, werden die gekauften Lücken gemeldet und in Zusammenarbeit mit den Herstellern geschlossen? Oder um in Zukunft "digitale Waffen offensiv" einzusetzen?
Also Aluhut schön und gut, aber das ist Realität und es wird noch nicht einmal versucht, das irgendwie zu verschleiern.
Und zum Thema: https://www.heise.de/-3913635
Im Gegensatz zu Intel kann bei AMD deren Secure Blabla deaktiviert werden - also sind die Nerds hier im Forum damit deutlich besser beraten, wenn sie Wert auf die Sicherheit ihres Systems legen.
Zuletzt bearbeitet:
RoBBe07
Enthusiast
AMDs PSP kann eben weder bei jedem Mainboard, noch komplett deaktiviert werden. Gibt's nen schönen Bericht zu.
Gesendet von meinem G8341 mit Tapatalk
Gesendet von meinem G8341 mit Tapatalk
RAZ0RLIGHT
Enthusiast
Es benötigt PHYSISCHEN Zugriff auf den PC, da liegt die Sicherheitslücke eher beim Besitzer des PCs als bei der CPU...
Dennoch gut, dass es entdeckt wurde und man jetzt Gegenmaßnahmen erwarten kann.
Dennoch gut, dass es entdeckt wurde und man jetzt Gegenmaßnahmen erwarten kann.
Zuletzt bearbeitet:
Wenn es danach gehen würde, wäre ja auch Meldown kein Problem -> da brauchs auch den gleichen physischen Zugriff
Es reicht WENN du einfach mit entsprechenden Rechten den Spaß ausführst. Dafür musst du aber nicht zwangsweise physisch vor dem Gerät sitzen.
Das betrifft allen voran privat genutzte PCs -> da arbeitet sogut wie jeder als lokaler Admin und führt im Zweifel den untergejubelten Schadcode aus. Nichtmal bewusst...
Würde ich derlei Codezeilen abkippen wollen -> ich würde mir ne Windows 10 Cleanup Software suchen und die Zeilen dort unterjubeln
Gerade was solches Tuningzeug angeht, das führen wohl 90+% bedenkenlos aus, auch als Admin... Wäre ein leichtes sowas zu verteilen.Unsinn... Das ist hier schlicht Schlampigkeit.
Die News gibt nur nen Bruchteil der Wahrheit Preis. Schau dir bitte die Veröffentlichung zu diesem Thema vom 3.1. an.
Da haben sich Leute nen ARM Emulator aus Mangel an AMD Hardware geschnappt, weil sie in public im INet verfügbaren Code die potentielle Lücke sahen -> probiert und es fruchtete auch im Emulator. Und noch witziger, auch in Hardware von AMD. Und warum? Weil man gängige Maßnahmen zur Vermeidung solcher Umstände gar nicht implementiert hat...
Dazu kommt (auch das fehlt hier leider), es ist möglich (bestätigt durch einen AMDler), dass über diese Lücke Cryptokeys aus dem TPM Modul ausgelesen werden können.
Was bspw. bei HDD Vollverschlüssung mit TPM Hilfe die Verschlüsslung bricht -> ganz ohne, dass da wer die Keys kennt. Ggf. auch die Hardware-Memory Verschlüsslung bei Epyc Systemen bricht -> weil dafür der PSP nach Angabe AMDs auch zuständig sein soll und die Keys wohl im TPM Store stehen.
Warum man das hier mit Spectre und Meltdown in Verbindung bringt, ist mir Rätzelhaft. Hier Verbindungen zu sehen ist der falsche Weg. Lücke ist aber Lücke... Und gerade sowas ist ein absolutes NoGo, da es ähnlich der IME Scheiße im Zweifel gar nicht sichtbar für den User ist. Dazu kommt, die News zeigt, auch AMD kocht mit dem selben (dreckigen) Wasser wie Intel. Propritärer Mist, schlechte Doku, "Keiner" weis was -> und dann noch Blödheit bei der Implementierung. Sowas gehört sich nicht für Security relevanten Stuff... Hoffentlich wachen endlich mal die ganzen Leute auf, die bei den IME Lücken groß mit der AMD Fahne im Wind gewunken haben... Aktuell läuft in der IT soviel Unsinn, da kannste effektiv nur Stecker ziehen und hoffen, dass das in Zukunft besser wird.
PS: hier der Link
Full Disclosure: AMD-PSP: fTPM Remote Code Execution via crafted EK certificate
"Proof Of Concept
================
Without access to a real AMD hardware, we used an ARM emulator [7] to
emulate a call to EkCheckCurrentCert with the CERT_DATA listed above. We
verified that full control on the program counter is possible:
...
As far as we know, general exploit mitigation technologies (stack cookies,
NX stack, ASLR) are not implemented in the PSP environment.
Credits
===========
This vulnerability was discovered and reported to AMD by Cfir Cohen of the
Google Cloud Security Team.
...
12-07-17 - Fix is ready. Vendor works on a rollout to affected partners."
Security hole in AMD CPUs' hidden secure processor code revealed ahead of patches • The Register
"An AMD spokesperson told The Register that an attacker would first have to gain access to the motherboard and then modify SPI-Flash before the issue could be exploited. But given those conditions, the attacker would have access to the information protected by the TPM, such as cryptographic keys."
Wieso?
Weil es Spectre und Meltdown gibt, gibts ab sofort keine anderen Lücken mehr?
"ebenfalls von Lücke" bedeutet doch nur, es ist ebenfalls EINE Lücke vorhanden. Welche, beschreibt der Text... Die Überschrift passt schon.
Nein, im Moment nicht bekanntermaßen. Aber der Text passt trotzdem. AMD ist, ebenso wie Intel für Spectre v1 anfällig und für v2 zumindest mit zero risk anfällig. 2x sind nunmal Mehrzahl.
Deswegen auch "Sicherheitslücken (von denen auch AMD)" anstatt "Meltdown ... Lücke von der"...
RAZ0RLIGHT
Enthusiast
Wenn es danach gehen würde, wäre ja auch Meldown kein Problem -> da brauchs auch den gleichen physischen Zugriff
Es reicht WENN du einfach mit entsprechenden Rechten den Spaß ausführst. Dafür musst du aber nicht zwangsweise physisch vor dem Gerät sitzen.
Das betrifft allen voran privat genutzte PCs -> da arbeitet sogut wie jeder als lokaler Admin und führt im Zweifel den untergejubelten Schadcode aus. Nichtmal bewusst...
Würde ich derlei Codezeilen abkippen wollen -> ich würde mir ne Windows 10 Cleanup Software suchen und die Zeilen dort unterjubeln
Und wer wäre dabei Schuld?
Auch ohne diese CPU Hintertüren wäre es fahrlässig so eine Software runterzuladen, es gibt immernoch Viren und Malware
Ich versuche hier AMD nicht zu verteidigen, jede Firma spielt mit faulen Tricks, aber Intel ist nunmal unangefochten an der Spitze.
ps. es gibt kein zu 100% sicheres System auf der Welt, deshalb ist es gut, dass wir Menschen haben die den ganzen Tag damit beschäftigt sind solche Lücken zu finden und es den Herstellern (gegen Bares) mitzuteilen.
Zuletzt bearbeitet:
100% agree
Ich will hier keine Schuld zuweisen, weil das nicht zielführend ist. Schuld bei Lücken zuzuweisen halte ich generell für falsch, es sei denn, es ist absicht. Aber das wäre halt ne Unterstellung. Intel ist halt bei der Masse mit ganz vorn dabei, wenns um Dresche kassieren geht. Aus meiner Sicht _MUSS_ aber hier Umdenken stattfinden. Nur weil Andere etwas weniger Dreck am Stecken haben, ist das Security Sicht nicht besser. Leider interessiert (gerade hier in der Community) die allerwenigsten die Security, sondern es geht um Herstellerverbundenheit und besagte Schuldzuweisungen... Kein Plan was das bringen soll. Helfen tuts keinem. Besser wirds dadurch auch nicht.
Ich will hier keine Schuld zuweisen, weil das nicht zielführend ist. Schuld bei Lücken zuzuweisen halte ich generell für falsch, es sei denn, es ist absicht. Aber das wäre halt ne Unterstellung. Intel ist halt bei der Masse mit ganz vorn dabei, wenns um Dresche kassieren geht. Aus meiner Sicht _MUSS_ aber hier Umdenken stattfinden. Nur weil Andere etwas weniger Dreck am Stecken haben, ist das Security Sicht nicht besser. Leider interessiert (gerade hier in der Community) die allerwenigsten die Security, sondern es geht um Herstellerverbundenheit und besagte Schuldzuweisungen... Kein Plan was das bringen soll. Helfen tuts keinem. Besser wirds dadurch auch nicht.
DragonTear
Legende
@fdsonne
Naja.. Schlampigkeit. Okey, im Endefekt stimmt das natürlich, aber auch Programmierer sind nur Menschen und eben nicht perfekt.
Eine Sprache wie von mir erwähnt, würde das Risiko verringern!
Was ist wohl besser? Immer dran denken, keinen Fehler zu machen, oder mit etwas arbeiten womit man automatisch weniger oder zumindest bestimtme Fehler (Bufferoverflow Geshcichten gibt es ja immer wieder) nicht mehr machen kann?
Schlampigkeit war zu nem gewissen Grad wahrscheinlich auch die Ursache für Meltdown und Spectre. Sowas in Zukunft zu vermeiden wird/ist schwer, eben weil Menschen Fehler machen.
In Software hätte man heutzutage aber die Möglichkeit dazu, gewisse primitive Fehler unwahrscheinlicher zu machen und das ohne den Entwickler direkt mehr zu fordern!
Naja.. Schlampigkeit. Okey, im Endefekt stimmt das natürlich, aber auch Programmierer sind nur Menschen und eben nicht perfekt.
Eine Sprache wie von mir erwähnt, würde das Risiko verringern!
Was ist wohl besser? Immer dran denken, keinen Fehler zu machen, oder mit etwas arbeiten womit man automatisch weniger oder zumindest bestimtme Fehler (Bufferoverflow Geshcichten gibt es ja immer wieder) nicht mehr machen kann?
Schlampigkeit war zu nem gewissen Grad wahrscheinlich auch die Ursache für Meltdown und Spectre. Sowas in Zukunft zu vermeiden wird/ist schwer, eben weil Menschen Fehler machen.
In Software hätte man heutzutage aber die Möglichkeit dazu, gewisse primitive Fehler unwahrscheinlicher zu machen und das ohne den Entwickler direkt mehr zu fordern!
Zuletzt bearbeitet:
Phantomias88
Banned
@ DragonTear
Du forderst direkt, dass andere Sprachen genutzt werden. Ohne würde ich das also nicht nennen... Das hat alles sein Für- und Wieder. Auch das weiter nutzen vorhandenen Codes vs. das Neuschreiben in verschiedenen Sprachen. Aber darum gehts (mir) ja gar nicht. Vor allem hier nicht. Nimmt man es genau, die benannten Maßnahmen sind ja nichts Weltneues und eher gängige Praxis. Da nicht dran zu denken ist schon eher das komische...
Mein persönliches Problem ist hier, dass es (analog der Intel IME Kacke) eben eine Art Blackbox ist. Egal was die da machen, das Risiko besteht... Und eben WEIL du über diesen Weg potentiell sehr viel Schaden anrichten kannst, gehört so ein Konstrukt eben überhaupt gar nicht da rein. Theoretisch ist es eher verwunderlich, wieso es bei Intel für die beiden großen "Findungen" so ultra lange gedauert hat. Und theoretisch verwundert es bei AMD, dass der Code, der ja in Teilen eben sogar offen war, überhaupt nicht mal wen gestört hat bis eben zu dieser Sache hier.
Wenn ich das richtig sehe, der relevante Part dort ist mit Code von 2014-2015... Zumindest suggerieren das die Files im Github. Ob AMD diesen 1:1 übernommen hat oder nicht, kein Plan, aber der relevante Teil hat sich effektiv nicht geändert -> und zeigt/bestätigt, was OpenSource hier wirklich zur Sicherheit beiträgt -> nämlich nichts...
PS: unter Softwareentwicklungssicht ist der Ansatz -> wir nutzen was, wo Fehler vllt gar nicht passieren (und verlassen uns darauf!!) - für mich auch nicht der richtige weg. Warum? Weil der Entwickler verblödet. Wenn alle für dich mitdenken sollen und du nur stumpf Code hinzimmerst, wird das früher oder später ins Auge gehen. Denn du musst im Zweifel immernoch prüfen ob da der Bock drin ist. Oder auch, ob die Maßnahmen von "oben" überhaupt funktionieren/greifen. Tust du das nicht, merkst du es nicht... Und genau hier ist der Knackpunkt. Es spielt keine Rolle was du nutzt, wenn dein Prozess nicht sauber ist... Trifft im übrigen nicht nur auf Softwareentwicklung zu, sondern das findest du überall.
Ach und Meltdown und Spectre haben in dem Sinn nix mit Schlampigkeit zu tun. OK, vllt ein Stück weit, aber da muss man schon ziemlich naiv sein und unbedingt Schuldige suchen wollen um das dahin zu bringen. Man nutzt hier für zweifelhafte Zwecke das Funktionsprinzip der Technik, nur eben soweit mehr, wie es gar nicht vorgesehen war. Und vor allem soweit, wie gar keiner der Erfinder des Prinzips jemals dran gedacht hat (gleiche Geschichte wie oben -> wir verlassen uns drauf) Eben drum ist das Zudrehen von Spectre bspw. schwer und nicht mit paar Zeilen Code zu tun. Meltdown hingegen ja, das wäre verhinderbar. Den Schuh müssen sich die Betroffenen definitiv anziehen. Warum der Prozessor den Zugriff nicht instant dropt ist halt die Frage, die Intel beantworten müsste bzw. die Jungs von ARM für den A75. Ggf. gibts dafür aber auch mehr oder weniger gute Gründe genau so warum es bei AMD diese Gründe gab, es im Detail anders zu händeln.
@*******
nen Zusammenhang mit Win10 würde ich da nicht sehen... Das geht bis auf 2012 und sicher noch weiter zurück. Ist auch kein Desktop only Feature. Die Servermodelle haben das ja auch, alle samt.
Scheint mir eher in Zusammenhang mit UEFI zu stehen. Da war halt auch wieder Intel mehr oder weniger treibende Kraft gewesen. Aber scheinbar auch ein Stück weit durch Dritte getriggert mit dem Drang, entsprechend vom Nutzer unabhängige Infrastruktur zu integrieren um sowas wie Secureboot und dergleichen Stuff überhaupt fahren zu können.
Du forderst direkt, dass andere Sprachen genutzt werden.
Ohne würde ich das also nicht nennen... Das hat alles sein Für- und Wieder. Auch das weiter nutzen vorhandenen Codes vs. das Neuschreiben in verschiedenen Sprachen. Aber darum gehts (mir) ja gar nicht. Vor allem hier nicht. Nimmt man es genau, die benannten Maßnahmen sind ja nichts Weltneues und eher gängige Praxis. Da nicht dran zu denken ist schon eher das komische...Mein persönliches Problem ist hier, dass es (analog der Intel IME Kacke) eben eine Art Blackbox ist. Egal was die da machen, das Risiko besteht... Und eben WEIL du über diesen Weg potentiell sehr viel Schaden anrichten kannst, gehört so ein Konstrukt eben überhaupt gar nicht da rein. Theoretisch ist es eher verwunderlich, wieso es bei Intel für die beiden großen "Findungen" so ultra lange gedauert hat. Und theoretisch verwundert es bei AMD, dass der Code, der ja in Teilen eben sogar offen war, überhaupt nicht mal wen gestört hat bis eben zu dieser Sache hier.
Wenn ich das richtig sehe, der relevante Part dort ist mit Code von 2014-2015... Zumindest suggerieren das die Files im Github. Ob AMD diesen 1:1 übernommen hat oder nicht, kein Plan, aber der relevante Teil hat sich effektiv nicht geändert -> und zeigt/bestätigt, was OpenSource hier wirklich zur Sicherheit beiträgt -> nämlich nichts...
PS: unter Softwareentwicklungssicht ist der Ansatz -> wir nutzen was, wo Fehler vllt gar nicht passieren (und verlassen uns darauf!!) - für mich auch nicht der richtige weg. Warum? Weil der Entwickler verblödet. Wenn alle für dich mitdenken sollen und du nur stumpf Code hinzimmerst, wird das früher oder später ins Auge gehen. Denn du musst im Zweifel immernoch prüfen ob da der Bock drin ist. Oder auch, ob die Maßnahmen von "oben" überhaupt funktionieren/greifen. Tust du das nicht, merkst du es nicht... Und genau hier ist der Knackpunkt. Es spielt keine Rolle was du nutzt, wenn dein Prozess nicht sauber ist... Trifft im übrigen nicht nur auf Softwareentwicklung zu, sondern das findest du überall.
Ach und Meltdown und Spectre haben in dem Sinn nix mit Schlampigkeit zu tun. OK, vllt ein Stück weit, aber da muss man schon ziemlich naiv sein und unbedingt Schuldige suchen wollen um das dahin zu bringen. Man nutzt hier für zweifelhafte Zwecke das Funktionsprinzip der Technik, nur eben soweit mehr, wie es gar nicht vorgesehen war. Und vor allem soweit, wie gar keiner der Erfinder des Prinzips jemals dran gedacht hat (gleiche Geschichte wie oben -> wir verlassen uns drauf) Eben drum ist das Zudrehen von Spectre bspw. schwer und nicht mit paar Zeilen Code zu tun. Meltdown hingegen ja, das wäre verhinderbar. Den Schuh müssen sich die Betroffenen definitiv anziehen. Warum der Prozessor den Zugriff nicht instant dropt ist halt die Frage, die Intel beantworten müsste bzw. die Jungs von ARM für den A75. Ggf. gibts dafür aber auch mehr oder weniger gute Gründe genau so warum es bei AMD diese Gründe gab, es im Detail anders zu händeln.
@*******
nen Zusammenhang mit Win10 würde ich da nicht sehen... Das geht bis auf 2012 und sicher noch weiter zurück. Ist auch kein Desktop only Feature. Die Servermodelle haben das ja auch, alle samt.
Scheint mir eher in Zusammenhang mit UEFI zu stehen. Da war halt auch wieder Intel mehr oder weniger treibende Kraft gewesen. Aber scheinbar auch ein Stück weit durch Dritte getriggert mit dem Drang, entsprechend vom Nutzer unabhängige Infrastruktur zu integrieren um sowas wie Secureboot und dergleichen Stuff überhaupt fahren zu können.
oooverclocker
Semiprofi
- Mitglied seit
- 29.08.2012
- Beiträge
- 5.610
Einmal Libreboot-Support bitte! Und dann bin ich mit allen AMD-Produkten kritiklos zufrieden 
Zuletzt bearbeitet:
mr.dude
Urgestein
- Mitglied seit
- 12.04.2006
- Beiträge
- 6.420
RAZ0RLIGHT
Enthusiast
Man musste ja von sich (Intel) ablenken.
Ist dem so? Dachte unter Linux geht das problemlos.
Da gab es doch schon sogar richtig böse Fehler, weil z.B. Ubuntu 17.10 das UEFI/BIOS mancher Geräte zerlegt hat - über SPI. (Wobei das Intel Systeme betraf.)
Bei AMD ist das Problem also non existent, weil man physischen Zugriff auf den Rechner haben muss. Bei der IME wurde sich aber echauffiert und vollkommen ignoriert, dass man auch physischen Zugriff auf den Rechner brauchte. Ich glaube einige hier haben echt Probleme mit ihrer Doppelmoral...
Außerdem wer interessiert sich bei Sicherheitslücken dafür, wie schwer es ist diese ausnutzen zu können? Lücke ist Lücke und muss geschlossen werden. Egal wie schwer es ist diese ausnutzen zu können!
Außerdem wer interessiert sich bei Sicherheitslücken dafür, wie schwer es ist diese ausnutzen zu können? Lücke ist Lücke und muss geschlossen werden. Egal wie schwer es ist diese ausnutzen zu können!
unl34shed
Enthusiast
Nein, Intels ME war auch über das Netzwerk via vPro angreifbar
oooverclocker
Semiprofi
- Mitglied seit
- 29.08.2012
- Beiträge
- 5.610
Also es stimmt nicht so ganz. Wir haben in Linux tatsächlich mehrere SPI-Treiber, mit dem wir auch aus dem Betriebssystem ziemlich fehlerfrei flashen können. (Wie man sehen kann, ist da auch ein GPIO-Treibermodul, was beispielsweise den Header auf einem Raspberry-Pi ansteuern kann etc.)
Allerdings ist dieser "böse Fehler" dadurch entstanden, dass der Intel SPI-Treiber fehlerhaft war, und einige Haswell und Broadwell-Biosse dadurch teilweise defekt waren. Dass Ubuntu das Betriebssystem in Version 17.10 zeitweise heruntergenommen hat, sollte jetzt nicht als Schuldeingeständnis betrachtet werden - es ist die meistgenutzte Desktopdistribution und tatsächlich hat diesen Kernel-Fehler jede Linuxdistribution gehabt, die diese Kernelversionen im Einsatz hatte.
Zuletzt bearbeitet:
Nein, Intels ME war auch über das Netzwerk via vPro angreifbar
Da hast du Recht. Aber nicht bei der von mir verlinkten Lücke. Es ging mir nicht darum zu werten, ob nun die PSP oder IME schlechter sei, sondern um die Doppelmoral mancher Leute. Denn als die von mir verlinkte Lücke Thema war, meinten hier mache Leute, dass es vollkommen egal sei, dass man vorher physischen Zugriff brauch, um diese nutzen zu können. Aber jetzt auf einmal ist eine Lücke nicht wirklich ein Problem für diese Leute, da man zuvor physischen Zugriff benötige.
Wie kommt man jetzt zu so einem Schluss
Die Lücke ist doch mit deinem 2500k weitaus größer, besonders im Vergleich zu einem Ryzen ...
RAZ0RLIGHT
Enthusiast
Da hast du Recht. Aber nicht bei der von mir verlinkten Lücke. Es ging mir nicht darum zu werten, ob nun die PSP oder IME schlechter sei, sondern um die Doppelmoral mancher Leute. Denn als die von mir verlinkte Lücke Thema war, meinten hier mache Leute, dass es vollkommen egal sei, dass man vorher physischen Zugriff brauch, um diese nutzen zu können. Aber jetzt auf einmal ist eine Lücke nicht wirklich ein Problem für diese Leute, da man zuvor physischen Zugriff benötige.
Der Artikel hat "non existant" geschrieben, ja Lücke ist Lücke geb ich dir Recht, aber Intel hat soviele Lücken, die schon seit Jahren da sind.
Dass bei einem neuen Produkt (PSP) Fehler drin sind ist normal, nichts ist zu 100% sicher
Geschlossen gehört es dennoch, aber es ist nunmal was anderes ob man phyischen Zugriff auf den Rechner braucht oder eben nicht.
Denn wenn man physischen Zugriff hat kann man ganz andere Dinge machen, als die Sicherheitslücke der PSP auszunutzen, hier vergessen wohl einige unsere alten Freunde die Viren und Malware
Naja Intel oder auch AMD wirds freuen, die ganzen Serverbetreiber brauchen jetzt deutlich mehr CPUs.
Zuletzt bearbeitet:
RAZ0RLIGHT
Enthusiast
Windows Update, macht deinen PC etwas sicherer dafür auch deutlich langsamer, willkommen im Club.