Sicherheit gegenüber Spectre & co. bei bei offiziellen Quellen

Hinweis: In dem Thema Sicherheit gegenüber Spectre & co. bei bei offiziellen Quellen gibt es 10 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Wie sieht es eigentlich mit der Sicherheit aus, wenn ich ausschließlich binaries aus vertrauenswürdigen Quellen nutze?
    Also nur OpenSuse-repositories, vll. noch packman. Da sollte doch Spectre & co kein Problem sein oder?


    Danke für Kommentare
    Angie


    ------BEGIN H*KEY BLOCK-----
    v4sw6CPUhw5pr5FPck2ma8u7Lw3XGm1l7ELi3JNTe7t4TNDVb5Oen5g3/2ZMa5XsSr1p
    md5c03672c748a6c177669193688d70bd54
    -------END H*KEY BLOCK------

    Für den Inhalt des Beitrages 117471 haftet ausdrücklich der jeweilige Autor: Angie

  • Spectre und Melton haben nichts damit zu tun, ist ein falsches Layout bei der Hardwareerstellung von Prozessoren.


    Und das muss jetzt Softwaremässig gepatched werden.


    Und ob alles, was es bei software.opensuse.org gibt sicher ist, darf auch bezweifelt werden (Stichwort /home Repos).

    Für den Inhalt des Beitrages 117476 haftet ausdrücklich der jeweilige Autor: Sauerland

  • Wenn du bislang schön brav warst, kannst du das vergessen.


    Zum einen gab es (angeblich) bis zur Veröffentlichung noch keine Malware dafür.
    Zum anderen sind die Leseraten sehr, sehr niedrig.


    Du kannst also getrost warten, bis das wirklich erledigt ist.
    Leute, die jetzt gleich in Panik alle erscheinenden Patches einspielen, konnten oft nicht mehr booten.


    Ich mach da gar nix. (Hab abba auch AMD) und warte getrost ab.
    Mit genau dem Argument: Ich war bisher brav, mein Linux bleibt brav.



    Zudem eine Lücke mit nur einem Patch eben NICHT behoben werde kann.
    Da muss JEDE davon betroffene Software umgeschrieben werden.
    Heute weiß man noch nicht einmal so genau, welche das alles ist

  • Wenn du bislang schön brav warst, kannst du das vergessen.


    Ich vermute eher, er hat eine Intel-CPU und will die Kernel Page-Table Isolation dauerhaft abschalten (per Kerneloption nopti), um keine Leistungseinbußen hinnehmen zu müssen.

    Für den Inhalt des Beitrages 117480 haftet ausdrücklich der jeweilige Autor: Agnes

  • Ich denke, das einzige, worauf man achten sollte, sind, wie immer Websites.
    Spectre kann via JIT (JavaScript JustInTime Compiler) "leicht" ausgenutzt werden.


    Das hängt wieder vom jeweiligen Browser ab.
    Schwierig (derzeit') bei FireFox, leichter bei Chromium.
    Bei Chromium kann man dazu chrome://flags#enable-site-per-process einschalten.


    Und für den Rest würde ich wirklich warten.
    Es wurde ja geschrieben, dass die Kiste nur mit "sicheren Repos" (also offizielle und Packman) betrieben wird.

  • Spectre und Spectre und Meltdown sind drei verschiedene Angriffszenarien. @Angie sollte mal schreiben, wie er die Frage gemeint hat.


    Red Hat, openSUSE und auch Ubuntu haben anscheinend den aktuellen Intel-CPU-Microcode von Anfang Januar wieder zurückgezogen.
    Ich kann das aber nicht nachprüfen, weil ich einen AMD habe. https://software.opensuse.org/package/ucode-intel

    Für den Inhalt des Beitrages 117484 haftet ausdrücklich der jeweilige Autor: Agnes

  • Das war eher eine generelle Verständnisfrage.
    Ich glaube auch nicht, dass die bisher gemachte Panik, zumal das Problem eigentlich seit Pentium Pro (also ca. 20 Jahre) besteht, berechtigt ist.


    Ich nutze seit einigen Jahren einen AMD Phenom(tm) II X6 1090T Processor, der ist ja eher weniger betroffen


    Es interessiert mich vor allem auch, weil Bekannte danach fragten, die ebenfalls ausschließlich offizielle Quellen für Binaries nutzen.


    MfG Angie


    ------BEGIN H*KEY BLOCK-----
    v4sw6CPUhw5pr5FPck2ma8u7Lw3XGm1l7ELi3JNTe7t4TNDVb5Oen5g3/2ZMa5XsSr1p
    md5c03672c748a6c177669193688d70bd54
    -------END H*KEY BLOCK------

    Für den Inhalt des Beitrages 117505 haftet ausdrücklich der jeweilige Autor: Angie

  • Das war eher eine generelle Verständnisfrage.
    Ich glaube auch nicht, dass die bisher gemachte Panik, zumal das Problem eigentlich seit Pentium Pro (also ca. 20 Jahre) besteht, berechtigt ist.

    Die Sicherheitslücken sind eben erst 20 Jahre später entdeckt worden. Aber ein Virus nach dem Schema Spectre oder Meltdown wurde noch nicht entdeckt.

    Ich nutze seit einigen Jahren einen AMD Phenom(tm) II X6 1090T Processor, der ist ja eher weniger betroffen

    Willkommen im Club! :) AMD ist viel weniger betroffen. https://www.amd.com/en/corporate/speculative-execution

    Es interessiert mich vor allem auch, weil Bekannte danach fragten, die ebenfalls ausschließlich offizielle Quellen für Binaries nutzen.

    Das haben dir @Sauerland und @Berichtigung eigentlich schon beantwortet.

    Für den Inhalt des Beitrages 117507 haftet ausdrücklich der jeweilige Autor: Agnes

  • Ich mach da gar nix. (Hab abba auch AMD) und warte getrost ab.
    Mit genau dem Argument: Ich war bisher brav, mein Linux bleibt brav

    Ich auch.


    In der ct 3/18 Seite 58 - 75 steht eine ganze Menge dazu.
    Wenn man alles gelesen hat, ist die Lösung von Berichtigung die richtige.


    Alles habe ich aber nicht verstanden, weil mir für das innere von Cpu`s das Wissen fehlt.

    Für den Inhalt des Beitrages 117511 haftet ausdrücklich der jeweilige Autor: Kanonentux

  • Man mag noch nach eingehendem Studium einen 386er verstehen können.
    Spätestens beim ersten Pentium ist Ende der Fahnenstange.


    Da braucht es mindestens ein gut abgehangenes Studium E-Technik und drei Jahre direkt beim Hersteller in genau dieser Abteilung.


    Einen modernen i7 kann man unter diesen Voraussetzungen schon nach 10 Jahren verstehen.
    Stellenweise.
    Aber sicher nicht komplett.


    Das ist der Grund, warum sich viele sicherheitsbesorgte Bürger um die Sicherheit sorgen,
    wenn längst bekannte Lücken Jahre später in den einschlägigen Käseblättern breitgetreten werden.
    Das hat immerhin den nicht zu unterschätzenden Vorteil, dass deren Kisten dann nicht mehr booten,
    und das sicherheitsbewußte Rumschwätzen ein wenig hemmen.
    Kurzzeitig zumindest.