Aktuelle PC und Internetsicherheit (2017-....)

  • Erste Proof of Concept Tools gibt's schon als Quellcode (kA auf welchen Betriebssystemen der Code rennt, ich vermute Mal nur Linux): [Hier].

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • @Bier: Hier gibt es ein Tool für Windows => https://ionescu007.github.io/SpecuCheck/ :)

    Zum Thema: Als Privatanwender sehe ich die Sache recht entspannt. Meltdown ist über OS Patches gegessen und der Leistungseinbruch gar nicht bis sehr gering vorhanden. Spectre... ist so extrem schwierig auszuführen, da mache ich mir recht wenig Gedanken. Die kritischen Schnittstellen in die Außenwelt (z.B. Browser) werden gefixt bzw. haben schon Patches erhalten und der Rest ist wie gehabt.

    Spannend wird die Thematik dann in der Arbeit... ich freue mich auf Montag.

    Edit:
    Und damit sich die AMDler genauso unsicher fühlen :P -> https://www.phoronix.com/scan.php?page=…8-Vulnerability

    Zitat

    AMD's Secure Processor / Platform Security Processor (PSP) that is akin to Intel's Management Engine (ME) is reportedly vulnerable to remote code execution.

    A member of Google's Cloud Security Team discovered through static analysis that a function in PSP's firmware TPM code is vulnerable to a stack-based overflow due to missing bounds checks. Submitting a specially-crafted certificate to the fTPM trustlet code can lead to an overflow and then full control on the program counter.

    Insofern, nichts ist sicher, also einfach entspannt durch die Hose atmen ^^

    Einmal editiert, zuletzt von Löschzwerg (6. Januar 2018 um 12:09)

  • @Bier Alle CPUs ab dem Pentium Pro (1995) sind betroffen. Die Core Architektur jedenfalls zu 100%, also auch der Ur Intel Core. Bei Netburst wäre es jedenfalls noch interessant zu wissen ob die auch betroffen sind, die haben ja eine ganz andere Architektur.

  • @Bier Alle CPUs ab dem Pentium Pro (1995) sind betroffen. Die Core Architektur jedenfalls zu 100%, also auch der Ur Intel Core. Bei Netburst wäre es jedenfalls noch interessant zu wissen ob die auch betroffen sind, die haben ja eine ganz andere Architektur.

    Laut Intel selbst stimmt das nicht.
    https://security-center.intel.com/advisory.aspx?…anguageid=en-fr

    @Bier:
    Zum Testen der letzten IME Sicherheitslücke:
    https://www.computerbase.de/2017-11/intel-…ool-ime-luecke/

  • Das Mücke-Elephant-Problem
    Nächste kauft AMD seinen Mitarbeitern neue Schuhe von adidas und das gibt Gelaber und Zank, weil die nicht von PUMA sind...

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • SpecuCheck gibt einen Abbruch weil irgendwas nicht installiert ist. Und sie sagen nicht was...


    Das intel IME tool gibt sowas raus:
    <System_Risk>Detection Error: This system may be vulnerable,
    either the Intel(R) MEI/TXEI driver is not installed
    (available from your system manufacturer)
    or the system manufacturer does not permit access
    to the ME/TXE from the host driver.</System_Risk>

    na danke?!? Kann das tool jetzt nicht auslesen weil ein Treiber fehlt oder ist da ein Fehler? ...

    GAT dein tool rennt. Leider hab ich da keine weitere doku zu gefunden wann ein system unsicher ist und wann nicht.... Hier mal ein test:

    das sieht relativ heile aus?!? oder defekt? ./poc_poison hatte ich abgebrochen... evlt findet der was wenn ich es heute nacht laufen lasse


    da muss ein Tool jeweils her das ein unbedarfter Anwender nutzen kann. Doppelklick ----> tests ----> Ergebnis.

  • "Ungültiger Maschinenbefehl"
    Sagt doch alles. Entweder es fehlt etwas, oder es ist einfach fehlerhaft übersetzt.

    "Du bist und bleibst a Mensch und du kannst eben net deine menschlichkeit überwinden."

    Dennis_50300

  • Jo, so eine Meldung kriegst nur wenn du z.B. SSE Code auf einer CPU aufrufst, die das gar nicht hat.

    Vom Windows Tool werd ich Mal Montags einen Build rauslassen, wenn ich wieder auf der Arbeit bin, solange sich die Bude nicht schon selbst im Paniktaumel zerhackt hat. ;)

    @Bier: So wie ich das Tool verstehe, zeigt der funktionierende Teil der Ausgabe bei dir, daß deine CPU verwundbar ist, weil Kernelspeicher hat ausgelesen werden können.

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • der hat AES CPU instructions im code handgeschrieben drin. das kann mein Xeon halt nicht :D

    Ich lasse das mal über Nacht laufen. Es sieht allerdings so aus als würde er nur 0en auslesen. Da passt etwas nicht ;)

  • so mein Xeon ist mit den Funktionierenden Teil durch.

    das sieht nicht nach Kernelspeicher aus nur Nullen :spitze:

  • Der Meltdown Code den ich dir gegeben habe hat aber gegriffen? Leider sind die ganzen Spectre Tools irgendwie auf moderne Befehlssätze und tlw. x86_64 angewiesen. Den Meltdown PoC versuche ich immer noch sauber auf 32-Bit gebaut zu bekommen (braucht soweit nur SSE2). Bier, wenn du noch ein 32-Bit Linux auf einer modernen CPU (Core 2 oder neuer) hast, würde ich dich bitten den Meltdown Code auch dort zu probieren.

    Auf meinem i7 in 64-Bit dumped er Kernelspeicher wie gedacht. Aber der 32-Bit Code will irgendwie ned so recht, bzw. ich trau dem noch nicht, weil von mir cross-compiled, und mit ein paar falschen Compileroptionen oder gewissen aktiven Optimierungen spuckt der auch flott nur mehr Nullen oder FF aus.

    Nächster Versuch: Ich übersetz den Code direkt auf der Zielmaschine neu (mit den selben Optionen zwar, aber jo). Muß nur etwas warten, weil noch kompiliere ich den GCC, braucht einen etwas neueren, damit die Makros da sind, die der Code braucht..

    Ziel: Ich will Netburst testen, was Meltdown angeht!

    Edit: Fertig. Also, das ist mit viel Vorsicht zu genießen, aber weder mein cross-compiled Binary noch mein lokal kompiliertes können Meltdown auf Netburst nachweisen (der Kernel ist noch ungepatched!). Issn Prestonia Xeon:

    Interessanterweise hatte ich vorher Scores >900 bekommen bei fast jeder Iteration, und er meinte dennoch NOT VULNERABLE. So ganz verstehe ich den PoC bzw. dessen Ausgaben nicht. Die Binärversion die vorher die 900er Scores ausgespuckt hat, gibt jetzt auch nur mehr die ff von da oben zurück. ?( Najo, ich brauch noch eine 32-Bit Kiste mit moderner CPU (oder einen 64-Bit Netburst), um das wirklich vergleichen zu können...

    Edit 2: Quellcode von [hier], und der supported 32-bit eigentlich offiziell. Vielleicht noch andere probieren..

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

    3 Mal editiert, zuletzt von GrandAdmiralThrawn (9. Januar 2018 um 20:19)

  • More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema

    https://eprint.iacr.org/2017/713.pdf

    Im Grunde nichts wirklich Wildes, nur, dass die Betreiber in die Gruppenchats Leute hinzufügen können und damit die Verschlüsselung zwar nicht brechen, aber den Inhalt heraustragen können, weil der Angreifer Mitglied der Gruppe ist.
    Hier müssen die Betreiber die Administration verbessern.

    Chats von nur zwei Personen gelten weiterhin als sicher.

  • Heute sind (nach der Linux Patcherei zu Meltdown und tlw. Spectre) Mal erste wenig erfreuliche Feedbacks etwas erzürnter Nutzer hereingekommen. Offensichtlich ist der Systemcall Count von GCC beim parallelisierten Kompilieren recht massiv hoch, hier scheinen sich die 30% (oder sogar mehr) Leistungsverlust durchaus zu bewahrheiten. Ärgerlich für Compiles, die so schon nur knapp in einen Arbeitstag gepaßt haben..

    Soll ich beim nächsten Meeting vorschlagen, alles wegzuwerfen, damit wir endlich EPYCs herschaffen können? :rolleyes:

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Keinen, der viele Syscalls erfordern sollte, also nur sehr wenige Userspace/Kernelspace Transitions. Das I/O ist minimal, und die rechenschweren Teile sollten sowieso von Systemcalls frei sein. Das ist allerdings nur theoretische Information auf Basis meiner persönlichen Einschätzung.

    Ich plane natürlich einen entsprechenden Gegentest auszuführen, aber die Maschine auf der ich das erledigen möchte hat grade eine hohe Arbeitslast, die noch für mehrere Tage alle 16 Kerne auslasten wird. Danach ist ein Timeslot für eine x264/x265 Reevaluierung frei, unter Linux.

    Unter Windows werde zumindest ich erst Mal keine vorher/nachher Tests nachliefern (können).

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"

  • Witzig find ich immer noch, daß man kolportiert, daß quasi alle CPUs mit Speculative Execution betroffen seien (IBM hat das für PowerPC ja auch schon bestätigt), aber bei Intel, wo es schon auf dem Pentium Pro losgeht... Ich hab noch immer kein PoC Tool gesehen, daß auf der Hardware überhaupt laufen würde. Ich würde das gerne Mal wirklich testen, aber dazu braucht's halt ein Binary, das nicht für Win7+ gebaut ist, sondern ein universelles. Eines, das simpelster x86 Code ist, der einfach überall rennt. Das braucht auch keine sexy GUI, Kommandozeile reicht.

    Auf Linux dasselbe. Bislang keinen Code gefunden, der mir zuverlässig und verläßlich eine Verwundbarkeit auf alten Maschinen nachweisen kann. Schert wohl keinen. Ob's tatsächliche Angreifer auch so wenig schert?

    PoC Code der tlw. sogar AES-NI voraussetzt ist schon etwas... uhm... dreist?

    Liegt das jetzt dran, daß der Angriff ohne Nutzung dieser Instruktionen schwerer wäre, oder was ist da der Grund?

    1-6000-banner-88x31-jpg

    Stolzer Besitzer eines 3dfx Voodoo5 6000 AGP Prototypen:

    • 3dfx Voodoo5 6000 AGP HiNT Rev.A-3700

    [//wp.xin.at] - No RISC, no fun!

    QotY: Girls Love, BEST Love; 2018 - Lo and behold, for it is the third Coming; The third great Year of Yuri, citric as it may be! Edit: 2019 wasn't too bad either... Edit: 2020... holy crap, we're on a roll here~♡!

    Quote Bier.jpg@IRC 2020: "Je schlimmer der Fetisch, desto besser!"