News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

cbtestarossa schrieb:
achso selber compilieren
Naja dazu müsste ich irgend einen C Compiler installieren und darauf habe ich keine Lust.

Und warum muss man den Quellcode anpassen?
Geht da kein INPUT? oder eventuell ein paar for/next Schleifen?

Bei Linux einfach den vorhandenen gcc verwenden.
Allerdings fehlt im Code noch ein Leerzeichen.
 
cbtestarossa schrieb:
Und warum muss man den Quellcode anpassen?

Manche Compiler arbeiten mit Klammern, andere verlangen den Wert direkt (Threshold-Zeile).
Manche CPUs brauchen einen hohen Threshold, andere einen niedrigen.
Das liegt an der Geschwindigkeit der spekulativen Ausführung, die je nach CPU-Modell verschieden ist.
Das befindet sich alles noch in der Testphase.

Geht da kein INPUT? oder eventuell ein paar for/next Schleifen?

Kommt vielleicht noch.
Ist noch alles mit der heißen Nadel gestrickt.

Gestern Nacht hieß es noch, Spectre sei nur sehr schwierig auszunutzen, falls das überhaupt gelingt und heute Nacht gibt es bereits funktionierenden Code.
Wer weiß, was aus diesem Code mit ein paar Tagen Arbeit werden kann?

Auf jeden Fall hat AMD gelogen, denn AMD ist anfällig und "near Zero chance" zur Ausnutzung trifft nicht zu wie man sieht.
 
Bolko schrieb:
Auf jeden Fall hat AMD gelogen, denn AMD ist anfällig und "near Zero chance" zur Ausnutzung trifft nicht zu wie man sieht.

AMD hat nicht gelogen. Denn die Aussage von "near zero Risk" kam von Google in ihrer Folie.

Zudem sind ALLE Architekturen von "Spectre" betroffen.

Es bleibt aber weiterhin dabei, dass die gefährliche Schwachstelle "Meltdown" ist, die in den Intel-CPU's zu finden ist (vor allem gefährlich für den Serverbereich).
 
Zuletzt bearbeitet:
Beir mir kam auf einem SandyBrige Celeron jetzt auch success.


Allerdings weiß ich nicht ganz, was mir das ganze sagen soll. Schließlich wird doch auf ein Array vom gleichen Programm zugegriffen. Das geht doch aus so?
Im Gegensatz zu Java gibt es bei C auch keine privaten Objekte.
 
TheLastHotfix schrieb:

Danke für den Hinweis, kam aber "The update is not applicable to your computer." .

Hab den 0x000000C4 BSOD mittlerweile mit
DISM /image:X:\ /cleanup-image /revertpendingactions
von einer repair disc aus gelöst und läuft alles wieder.
Warum auch immer waren bei der Installation keine system restore points aktiv... :freak:.
 
Zuletzt bearbeitet:
Warum auch immer waren bei der Installation keine system restore points aktiv..
Leg einfach per Patch im Autorstart oder täglich einen Wiederherstellungspunkt an.

Script:
SWP_Win7.vbs
Code:
set SRP = getobject("winmgmts:\\.\root\default:Systemrestore") 
CSRP = SRP.createrestorepoint ("VBS-Wiederherstellungspunkt", 0, 100) 
If CSRP <> 0 then 
    Msgbox "Error " & CSRP & ": Unable to create System Restore point" 
End if

Aufruf (Administrarorrechte erforderlich) mit
SWP_Win7.bat
Code:
C:\Windows\System32\wscript.exe SWP_Win7.vbs

Keine Ahnung ob das mit Win10 auch noch funktioniert
 
Zuletzt bearbeitet:
Hallo


Passiert numal, technick ist ist komplex heut zu tage!

Aber was ich los werden wollt ist: Dies wird der, wette ich, meist kommentierte und gelesene Threat 2018!!!!


und das so früh im jahr! ;)

grüße...
 
FreyFiremaid schrieb:
Passiert numal, technick ist ist komplex heut zu tage!
Finde ich auch. Dieser Tech-Nick ist ein komplexer Charakter.
--83806.jpeg


@darth_mickrig
Laut ARM sind nicht alle Architekturen betroffen. Mein Moto G3 mit Cortex-A53 bspw. ist vermeintlich nicht betroffen: https://developer.arm.com/support/security-update
 
Sun_set_1 schrieb:
Die Daten in Ap sind nicht verschlüsselt, da dies ja der Bereich ist der eigentlich verschlüsselt ist. Sobald die CPU hieraus aber Daten ausliest, muss das natürlich im Klartext geschehen. Wie sollten verschlüsselte Daten sonst jemals verarbeitet werden?

Wenn die Daten im Speicher verschlüsselt waren, sind die Daten auch im Ap weiterhin verschlüsselt. Windows
und viele andere Applikationen halten keine Klartextkennwörter im Speicher. Solche Informationen können nur abgegriffen werden, wenn zum Beispiel unverschlüsselt Kennwörter an eine Webseite übermittelt werden oder wenn man einen Kennwort Manager oder irgendwelche Tools verwendet, die solche Informationen im Klartext vorenthalten.

Anders ausgedrückt - wenn du KeePass mit deinen Kennwörtern offen hast und jemand einen Meltdown Angriff auf deinem PC macht, bekommt er bestenfalls die Kennwörter in verschlüsselter Form zu sehen. Nur wenn KeePass gerade dabei ist dieses Kennwort an eine Seite zu übermitteln und dieses entschlüsselt, ist es für diesen Moment im Speicher in einer solchen Form abgelegt. Dann müsstest du eben genau diesen Moment erwischen und die richtige Speicheradresse noch dazu.

Berücksichtigen sollte man auch die Geschwindigkeit mit der sich Daten aus dem Speicher anfordern lassen.

To evaluate the performance of Meltdown, we leaked known values from kernel memory. This allows us to not only determine how fast an attacker can leak memory, but also the error rate, i.e., how many byte errors to expect. We achieved average reading rates of up to 503 KB/s with an error rate as low as 0.02% when using exception suppression. For the performance evaluation, we focused on the Intel Core i7-6700K as it supports Intel TSX, to get a fair performance comparison between exception handling and exception suppression.

Das macht solche Angriffe sehr gefährlich, wenn man eine gut optimierte Software in einer VM einsetzt um Daten abzugreifen, die irgendwo auf dem Host oder anderen VMs gespeichert sind. Es erschwert aber einen sinnvollen Angriff durch irgendwo eingeschleusten Code in einem Browserfenster, erst recht wenn alle Hersteller ihre Browser gegen genau solche Attacken weiter absichern.

Initially, we are removing support for SharedArrayBuffer from Microsoft Edge (originally introduced in the Windows 10 Fall Creators Update), and reducing the resolution of performance.now() in Microsoft Edge and Internet Explorer from 5 microseconds to 20 microseconds, with variable jitter of up to an additional 20 microseconds. These two changes substantially increase the difficulty of successfully inferring the content of the CPU cache from a browser process.

Simpel ausgedrückt ist der Angriff für Hoster sehr gefährlich, auf der anderen Seite ist es aber nicht so als würde man irgendwo auf eine Webseite klicken und Zack alle Kennwörter, Kreditkarteninformationen und die persönliche Porno Sammlung landet im Netz. Dafür müssten die Informationen ja bereits im Klartext oder mit einer knackbaren Verschlüsselung im Speicher vorliegen und es bräuchte Zeit, einige Ressourcen und/oder Glück um an sie ranzukommen.

Das ganze Thema wird dafür nicht ungefährlich und ich möchte es keineswegs herunterspielen. Trotzdem sollte man anstatt nur Angst zu schnüren, das Gefahrpotenzial auch richtig einschätzen. Nicht umsonst haben sich einige Forscher wochenlang mit diesem Thema beschäftigt.

Wer seine Kennwörter in einer Textdatei speichert, ständig auf irgendwelchen dubiosen Webseiten unterwegs ist und Anmeldeinformationen über unverschlüsselte Protokolle übermittelt, der hat ja nicht erst seit Meltdown ein Problem. Für Hoster die eigene Hardware und/oder bestimmte Software anderen zur (mit)Nutzung überlassen, ist Meltdown hingegen ein ganz anderes Kaliber mit einem riesigen Angriffspotential.

Microsoft aktiviert übrigens auf Serversystemen trotz Patch den Schutz nicht selbsttätig (empfiehlt es allerdings auf RDSH Hosts und Hyper-V Maschinen) und hat für SQL Server ein Dokument veröffentlicht, in welchen Einsatzszenarien sie die Aktivierung der Schutzfunktionen als sinnvoll erachten.
https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server

Der Schutz lässt sich auch mit den beschriebenen Mitteln auf Client-PCs abschalten falls man sich Sorgen wegen dem 0-2% Leistungsnachteil machen sollte.

To enable the mitigations

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 0 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

To disable the mitigations

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 3 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
 
Zuletzt bearbeitet:
Oh,oh,oh hab noch ne Idee für die AMD PR-Abteilung: "Erwerben Sie jetzt einen AMD Ryzen,Threadripper & Epyc die sichersten CPU´s der Welt" :evillol: :king: :evillol:
 
Alleine, dass es im Sommer schon ans Licht kam und wir erst heute davon erfahren...BETRUG!!
 
Ja nicht schlecht wie gesagt AMD wird's freuen.
 
man man wenn ich sowas lese „patch bringt ab cpu xy nichts“ , wenn dem so ist meinst du die stacken unnütze patches über patches oder wie?
die werden entfernt und fertig
 
get schrieb:
Alleine, dass es im Sommer schon ans Licht kam und wir erst heute davon erfahren...BETRUG!!

und was hätte es dir genützt wenn du es im Sommer gleich erfahren hättest? Mal abgesehen davon das die Hacker mehr zeit gehabt hätten um schadcode zu entwickeln. Die Fixes sind nicht von Heute auf Morgen entstanden sondern sind schon einige Monate in Entwicklung.
 
Ja trotzdem dürfte es einen ordentlichen Wirtschaftlichenschaden geben dadurch und was Smartphones angeht nur Apple ein Update bringen und MS vielleicht.

Ja ja drei große Lücken als ein Android wurde ich erst kaufen wenn sicher ist dass es ein Patch bekommt.
 
Zurück
Oben