Nein, AMD und Intel veröffentlichen traditionell keine Changelogs. Und man kann da auch recht wenig durch Vergleiche der Images rausfinden, weil sie verschlüsselt sind.
Intel - Hardwarebug
- Ersteller mogbo
- Erstellt am
midnight
OpenBSD & FreeBSD
OpenBSD -current hat schon Firefox 57.0.4 in den ports, welcher die Meltdown und Spectre Migrationen beinhaltet. Packages befinden sich im Bau und sollten in Kuerze auf den mirrors zur Verfuegung stehen.
https://marc.info/?l=openbsd-ports-cvs&m=151513081500576&w=2
Chromium ist allerdings noch bei 63.0.3239.132. Die Migrationen werden erst in Version 64 beinhaltet sein. Soweit ich weiss, hat Google die Version 64 bis dato aber noch nicht veroeffentlicht.
https://marc.info/?l=openbsd-ports-cvs&m=151513081500576&w=2
Chromium ist allerdings noch bei 63.0.3239.132. Die Migrationen werden erst in Version 64 beinhaltet sein. Soweit ich weiss, hat Google die Version 64 bis dato aber noch nicht veroeffentlicht.
pit234a
Well-Known Member
ich werde darin bestärkt, dass ich all diese Dinge in der Vergangenheit schon sehr restriktiv nutzte. Also gar kein aktives Online-Banking und keine wichtigen Sachen auf einem PC und so weiter.
Ich bin noch unsicher, ob ich auf JS im Browser wieder verzichten will, lange Zeit nutzte ich das ja gar nicht.
Ohne PC will ich auch nicht mehr sein, aber im privaten Umfeld bin ich nicht sehr gefährdet. Es kann niemand etwas auf meinen PCs finden, das ich nicht möchte und das mich irgendwie kompromittieren oder mir schaden könnte.
midnight
OpenBSD & FreeBSD
Ich lass mich davon nicht allzusehr beeindrucken. Installiert werden nur signierte packages von den offiziellen OpenBSD mirrors. Zum blocken von JS nutze ich schon immer noscript bzw. uMatrix und lasse nur notwendige und (hoffentlich) vertraenswuerdige JS zu.
Ich nutze zum Surfen im Moment nur das gegen Meltdown gepatchte Linux-Laptop und nicht den noch ungepatchten FreeBSD-Desktop. Außerdem habe ich erst einmal die Passwortdatenbank aus Firefox herausgenommen.
D
das.chaos
Guest
FritzBox integriert ein MIPS basiertes SoC, wobei mir jetzt detaillierte Informationen ueber das SoC nicht wirklich bekannt sind, da ich dieses "Ding" meide, wie der Teufel das Weihwasser [nicht wirklich mit einem BSD "flashbar" bzw. "Homebrew" installierbar].
Die Router bzpw "Appliances" von TP-Link integrieren MIPS basierte SoC aus dem Hause https://www.qualcomm.com/ [die nannten sich vorher Atheros oder so aehnlich], wobei SoC der Serie QCA955X bspw. von FreeBSD unterstuetzt werden, aber das fuehrt jetzt vom Thema ab, da ich nicht geboxxt werden moechte.
MIPS basierte Systeme sind mMn aufgrund Architektur "immun" gegenueber diesen Schwachsinn, den mMn Intel sowie AMD "verbrochen" hatten. Wobei ich mich jetzt nicht zu sehr wage aus dem Fenster zu lehnen.
edit: url bei "immun" veraendert..
-Nuke-
Well-Known Member
Das Ganze ist nicht auf Intels oder AMDs "Mist" gewachsen. Spectre und Meltdown betrifft mit Ausnahmen und Sonderregeln so ziemlich jeden Prozessorhersteller auf dem Markt.
Die einzigen CPUs die 100%ig immun dagegen sind sind CPUs die In-Order arbeiten und keine (großartige) spekulative Ausführung machen. Das ist ein großer Teil der älteren ARM CPUs (Raspberry Pi z.B.), ein paar alte Intel Atoms und diverse andere ältere/billige SoCs.
Ansonsten ist durch die Bank weg alles betroffen. x86, ARM, SPARC, POWER und wie sie nicht alle heißen. Kein "Fehler" ist exklusiv nur auf einem Hersteller zu finden. Es gibt nur Unterschiede im Grad der Betroffenheit.
Der Angriff ist ein allgemeiner Angriff auf Out-of-Order Execution und Speculative Execution allgemein und basiert nicht grundlegend auf "Fehlern" einzelner Hersteller.
Die einzigen CPUs die 100%ig immun dagegen sind sind CPUs die In-Order arbeiten und keine (großartige) spekulative Ausführung machen. Das ist ein großer Teil der älteren ARM CPUs (Raspberry Pi z.B.), ein paar alte Intel Atoms und diverse andere ältere/billige SoCs.
Ansonsten ist durch die Bank weg alles betroffen. x86, ARM, SPARC, POWER und wie sie nicht alle heißen. Kein "Fehler" ist exklusiv nur auf einem Hersteller zu finden. Es gibt nur Unterschiede im Grad der Betroffenheit.
Der Angriff ist ein allgemeiner Angriff auf Out-of-Order Execution und Speculative Execution allgemein und basiert nicht grundlegend auf "Fehlern" einzelner Hersteller.
Fusselbär
Makefile Voyeur
Der FreeBSD Firefox Port hat gestern ein Update erhalten:
https://svnweb.freebsd.org/ports?view=revision&revision=458152
Ich frage mich aber immer noch wegen dem Berkeley Paket Filter (BPF). Auf Projekt Zero wird ja beim Bounds check bypass darauf hingewiesen
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
Auf Ubuntu 17.10 ist das per per default abgeschaltet:
http://manpages.ubuntu.com/manpages/artful/man8/tc-bpf.8.html
https://lwn.net/Articles/437981/
FreeBSD nutzt bpf für DHCP:
Daher werfe ich nochmals die Frage in den Raum, ob es Sinn machen könnte den syctl auf 0 zu setzen:
Bislang habe ich, so weit ich mich erinnern kann, noch nicht an diesem sysctl herumgefummelt. Da ist mein Gewissen, Gedächtnis und auch /etc/sysctl.conf rein. Das net.bpf.zerocopy_enable habe ich aber mal eingeschaltet, da sehe ich auch meine Spuren noch in der Konfigurationsdatei.
https://svnweb.freebsd.org/ports?view=revision&revision=458152
Ich frage mich aber immer noch wegen dem Berkeley Paket Filter (BPF). Auf Projekt Zero wird ja beim Bounds check bypass darauf hingewiesen
https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html
Auf Ubuntu 17.10 ist das per per default abgeschaltet:
Code:
sysctl kernel.unprivileged_bpf_disabled = 0
sysctl net.core.bpf_jit_enable = 0
sysctl net.core.bpf_jit_harden = 0
sysctl net.core.bpf_jit_kallsyms = 0https://lwn.net/Articles/437981/
FreeBSD nutzt bpf für DHCP:
Code:
grep bpf /usr/src/sys/`uname -m`/conf/`uname -i` | grep bpf
# The `bpf' device enables the Berkeley Packet Filter.
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filterDaher werfe ich nochmals die Frage in den Raum, ob es Sinn machen könnte den syctl auf 0 zu setzen:
Code:
net.bpf_jitter.enable
R
ralli
Guest
Nicht nur hier wurde bereits der Untergang von Intel prophezeit. Ich halte dagegen und prophezeie, das das Gegenteil passiert. Intel hat längst eine neue Prozessor Generation in der Pipeline und auf diese werden sich alle besorgten User stürzen. Der Aktienkurs wird sich erholen und am Ende wird Intel glänzend da stehen. Selber werde ich die Designfehler ignorieren und abwarten, was so weiter von der Softwareseite passiert, einschließlich der OS Distris oder Firefox oder oder oder. Also entspannt zurück lehnen und Gelassenheit üben.
Fusselbär
Makefile Voyeur
Kurze Nebenanmerkung wegen Passwort im Firefox:
Wegen Passwortklau:
https://senglehardt.com/demo/no_boundaries/loginmanager/
Könnte das hier im Firefox setzen helfen:
Code:
signon.autofillForms;falseDer Passwortklau funktionierte aber ohnehin schon jahrelang, auch ohne Meltdown & Co.
Wieso hast du das überhaupt? Ich habe nun auf 3 Maschinen geschaut und keine hat das sysctl. Hängt das vielleicht an einer Kerneloption?
Ich weiß. Das ist auch eher meine Paranoia als sinnvoll.
Fusselbär
Makefile Voyeur
Gute Frage.
Aber ich glaube ich habe es gefunden, dort, damals bei den FreeBSD 7.0 Releasenotes:https://www.freebsd.org/releases/7.0R/relnotes.html#NET-PROTO
Und wenn ich nicht so ein Schussel wäre, dann hätte ich es auch gleich mal mit dem -i Schalter beim grep versucht:
Code:
grep -i bpf /usr/src/sys/`uname -m`/conf/`uname -i`
# The `bpf' device enables the Berkeley Packet Filter.
# Note that 'bpf' is required for DHCP.
device bpf # Berkeley packet filter
options BPF_JITTER # BPF_JITTER adds support for BPF just-in-time compiler.
mogbo
Banned
Nachrichten aus dem OpenBSD-Lager:
https://marc.info/?l=openbsd-tech&m=151521435721902
https://marc.info/?l=openbsd-tech&m=151521435721902
Ich würde sagen ja, denn:
- JITs sind generell problematisch, da man sie vergleichsweise einfach dazu bringen kann Dinge zu tun, die sie nicht tun sollen. FreeBSDs BPF JIT dürfte relativ wenig Reviews bekommen haben, schon da FreeBSD eine Nische ist und dazu ist es noch ein optionales Feature. Außerdem läuft der JIT noch im Kernel Mode, also ist da generell offene Hose.
- Die meisten CPUs sind nur deshalb gegen Meltdown immun, da sie Instruktionen schon beim Pipeline Entry auf Zulässigkeit prüfen und sofort verwerfen. Werden sie aus dem Kernelmode abgefeuert, gilt das nicht mehr. Die Instruktionen werden dann ausgeführt und Pech gehabt. Die Paper sagen explizit, dass Linux eBPF JIT für sowas missbraucht werden kann. FreeBSDs BPF JIT ist zwar eingeschränkter, aber mir würde das reichen um mich von dem Ding zu trennen.
H
holgerw
Guest
Hallo,
mal eine Frage eines Anwenders:
Wie sieht es generell mit dem Zweig 11.1-RELEASE aus? Werden da zeitnah Schutzmechanismen einfließen, die per freebsd-update dann einspielbar sind? Oder ist das in 12-current zeitnäher?
mal eine Frage eines Anwenders:
Wie sieht es generell mit dem Zweig 11.1-RELEASE aus? Werden da zeitnah Schutzmechanismen einfließen, die per freebsd-update dann einspielbar sind? Oder ist das in 12-current zeitnäher?
-Nuke-
Well-Known Member
Das Ganze wurde eh zu früh geleakt. Eigentlich sollte das Ganze Zeug erst nächste Woche öffentlich werden. Ist halt doof gelaufen. Jetzt ist halt erst mal kurz Massenpanik und darum vermute ich, dass das Ganze jetzt noch eine Weile länger dauert. Gerade die Patches gegen Spectre sind nicht so "trivial". Soll natürlich nicht die heißen, dass der Meltdown Workaround einfach zu implementieren ist, aber es ist ein Patch rein am Kernel. Spectre betrifft den ganzen Software-Stack vom Kernel über die Bibliotheken bis hin zur Anwendung. Anfängliche Spectre-Fixes gibt es bisher nur in Windows im Mainline, aber auch nur im Kernel. In Linux ist davon noch nichts im Mainline-Kernel enthalten. Allen anderen Systemen fehlt es noch an allem.
Spectre ist aber schwer auszunutzen und aufgrund der Browser-Anpassungen ist das Risiko für den Normalanwender recht gering.
Die einzig 100%ig sichere Möglichkeit aktuell ist eine CPU zu benutzen die immun ist. So ein paar Intel Atom CPUs aus ihren Anfängen oder einfache ARM-CPUs wie die im Raspberry Pi 1-3.
Spectre ist aber schwer auszunutzen und aufgrund der Browser-Anpassungen ist das Risiko für den Normalanwender recht gering.
Die einzig 100%ig sichere Möglichkeit aktuell ist eine CPU zu benutzen die immun ist. So ein paar Intel Atom CPUs aus ihren Anfängen oder einfache ARM-CPUs wie die im Raspberry Pi 1-3.
Fusselbär
Makefile Voyeur
Danke Yamagi,
das BPF JIT ist auch erst mal per sysctl abgeschaltet Das wir auch nicht lange dauern bis ich den nächsten Kernel ohne den FreeBSD BPF JIT gebaut habe.
Bleibt noch die Frage ob das net.bpf.zerocopy_enable gefährlich ist?
Der Erläuterung nach aus der Manual Page, könnte das nicht auch Potential haben?
Zuletzt bearbeitet:
laenger
ACME Produkttester
Wenn ich das richtig verstanden habe, betrifft das Problem nicht nur mich, als Endkunden beim Onlinebanking. Es müssen auch die Server und Rechner der Banken gefixt werden.
So wirklich ohne PC oder Smartphone geht es heute nicht mehr – zumindest nicht mit dem gewohnten Komfort.
Meltdown und Spectre betreffen die Prozessoren.
Viel schlimmer wäre eine Lücke, wodurch der Netzwerkstack betroffen wäre.
Es ist meiner Meinung nach nicht die Frage nach dem OB, sondern WANN der Digitale-Super-GAU kommt.
Ich sehe das ähnlich wie @-Nuke-.
Wird es zu früh publiziert, haben die Firmen noch weniger Zeit die Probleme in den Griff zu bekommen. Verfrühte, halbfertige Lösungen sind da oft noch problematischer als verspätete Lösungen, welche das Problem dafür zufriedenstellend beseitigen.
Andererseits versuche die Situation positiv zu sehen.
Ich spekuliere darauf, dass mein Intel Atom N270 welcher als MPD-Server an der Stereoanlage hängt, eine exorbitant hohe Wertsteigerung erfährt, da ersten Einschätzungen nach zu urteilen dieser nicht betroffen ist.
Aktienspekulationen und Investitionen in Immobilien waren gestern – alter Hardware gehört die Zukunft
Beste Grüße,
Laenger
pit234a
Well-Known Member
wenn die Banken die selbst betreiben, kann ihnen ja eigentlich nicht viel passieren. Von selbst geht ja nix, es muss ja erst ein Code aufgespielt und zum Laufen gebracht werden. Wer bisher noch keinen entsprechenden Code auf seinem PC hat, braucht nur dafür zu sorgen, dass kein neuer dazu kommt, dann kann auch kein böser Code dazu kommen. Bei einem Standard-Anwender ist die Brücke eben der Browser mit seinem Java-Script. Ein Banken-Server wird sich wohl kaum einen JS rein ziehen. Damit dürften diese Rechner zunächst mal noch relativ sicher sein, also zumindest vor neu ausgedachten Angriffsprogrammen.
Ein Geldautomat, an dem ich eben war, war allerdings außer Betrieb....
Nebenbei:
In meinem Bekanntenkreis hat jeder natürlich von dem Skandal gehört und niemand fühlt sich betroffen. Das erinnert mich irgendwie an den Klimawandel und die Umweltzerstörung, davon haben auch alle schon mal gehört aber es geht niemanden etwas an. Böse Dinge sind eben immer nur für andere Leute bestimmt, einem selbst wird doch nichts passieren. Schon irgendwie leicht merkwürdig, wie wir Menschen so gestrickt sind.
R
ralli
Guest
Natürlich gibt es solche Benutzer, aber das das die Regel ist, denke ich nicht. Auch bei meinem letzten Beitrag könnte der Eindruck entstehen, das ich oberflächlich wäre oder ignorant. Das bin ich ganz und garnicht. Ich bin kein Pessimist, aber auch kein Optimist, sondern eher ein Realist. Das verdrängen der Wahrheit ist indessen ein populäres Gesellschaftsspiel. Selber habe ich gottwohl keine Begabung dafür. Im Klartext, ich habe als kleiner Privatuser keinerlei Einfluß darauf, wie es sich weiter entwickelt. Alles, was in meiner Macht steht, werde ich tun, aber das ist leider verdammt wenig. Und ob die Probleme mit ein paar Patches aus der Welt sind, kann ich auch mangels meines technischen Wissens nie und nimmer überprüfen. Aber Angst ist kein guter Ratgeber und ärgern werde ich mich erst, wenn es an der Zeit ist und ich ein Opfer geworden bin. Im übrigen wissen wir alle, das es keine fehlerhafte Software gibt, warum sollte das bei der Hardware oder Prozessoren anders sein? Das unreflektiert zu glauben, wäre doch extrem naiv, oder? Wenn wir wüßten, wieviele Designfehler es tatsächlich gibt oder wieviele Backdoors bei Software, würden wir tatsächlich unruhiger werden. Allerdings stimmt mich nachdenklich, wenn das die Vorläufer einer ach so tollen digitalen Zukunft mit einer totalen Vernetzung sind, deren Risiken wir niemals auch nur annähernd richtig einschätzen können.
Andererseits ist die Frage was die meisten User so tun sollen. Windows updated ja von allein, anders als bei Heartbleed ruft niemand zu Passwortänderungen auf und damit bleibt eben die Frage, was die angemessene Reaktion ist. Sich einstweilen von Computern fernhalten?
Vielleicht beim nächsten Mal bei der Konkurrenz einkaufen, aber man wird wohl nicht den Laptop, den man erst zu Weihnachten bekommen hat gleich wieder los werden und stattdessen ein AMD-Teil oder einen Raspberry Pi nehmen.
Und wenn man ohnehin unbedarft ist, dann ist die Chance, dass das nächste Spiel das man lädt eine größere Gefahr darstellt. Schaut da eigentlich jemand groß auf Lücken?
Vielleicht beim nächsten Mal bei der Konkurrenz einkaufen, aber man wird wohl nicht den Laptop, den man erst zu Weihnachten bekommen hat gleich wieder los werden und stattdessen ein AMD-Teil oder einen Raspberry Pi nehmen.
Und wenn man ohnehin unbedarft ist, dann ist die Chance, dass das nächste Spiel das man lädt eine größere Gefahr darstellt. Schaut da eigentlich jemand groß auf Lücken?
Illuminatus
in geheimer Mission
UEFI, Intel ME, kaputte TPM und RNG, WLAN und BT Chipsätze mit Lücken in Firmware/Treibern. Kann man AES-NI trauen? Würde ein HSM die aktuelle Lücke weniger schlimm machen?
Für solche Listen ist es leider wohl noch zu früh. Würde mich selber auch eher auf Proof-of-Concept Code verlassen, in der Hoffnung dass er mir de facto anzeigt dass die CPU zuviele Daten ausspuckt. Dann hätte man auch Gewissheit ob Patches/Microcode Updates greifen.