Immer wieder Intel Lücken...

[lenny]

Guten Morgen zusammen,

als Frischling bei OPN Sense würde ich gerne einmal wissen, wie OPNsense mit den immer wieder mal auftauchenden Intel Lücken umgeht.
Bei meiner bisherigen Distribution erreichen mich dann sehr schnell neue Updates mit dem neuesten Microcode.
Passiert das hier auch?

[chemlud]

...interessehalber: Was ist deine "bisherige Distribution"? :-)

[franco]

Hi lenny,

Also https://www.freebsd.org/security/advisories/FreeBSD-SA-19:25.mcepsc.asc kommt morgen mit 19.7.7. Das geht schon immer fix. :)

Für https://www.freebsd.org/security/advisories/FreeBSD-SA-19:26.mcu.asc und anderes gibt es das devcpu-data Paket was aktuell gehalten wird mit FreeBSD (jeweils zum Zeitpunkt des OPNsense Releases). D.h. für die Mikrocode-Updates haben wir uns entschieden das Paket zur Verfügung zu stellen aber nicht zu integrieren. Es muss manuell installiert und in rc.conf eingefügt werden.

Der Aufwand für die Integration ist aber minimal. Ein Plugin das das automatisiert soll es geben, aber im Moment wird daran nicht gearbeitet weil die Notwendigkeit nicht im Verhältnis zur manuellen Konfiguration steht aus Core Team Sicht und sich auch kein anderer an das Thema gewagt hat.

Auch interessant ist das How-To von Thomas-Krenn: https://www.thomas-krenn.com/en/wiki/Update_Intel_Microcode_on_FreeBSD


Grüsse
Franco

[lenny]

Bisher laufe ich auf Ipfire...


Oh Super, das ist eine ausgiebige Antwort! Vielen Dank dafür :) Damit sollte ich das hinbekommen

[franco]

Dann viel Spaß mit dem Update heute :)

[JeGr]

Der andere Punkt ist natürlich auch: Wer darf auf deine Firewall und brauche ich für meinen Use-Case überhaupt Updates für die CPU, welche sie immer mehr verlangsamt (weil die "Abkürzungen" rausgepatcht und umbaut werden). Wenn ich/meine Admins die Einzigen sind mit lokalem Zugriff und ich noch dazu nicht Software mit MultiUser Aspekt darauf laufen lasse - interessiert mich dann die entsprechende Lücke im Einzelnen oder tangiert sie mich in meinem Use-Case gar nicht?

[banym]

Da wir mit OPNsense schon einige Dienste anbieten die auch Usern die direkte Interaktion mit der Firewall erlauben, besteht aus meiner Sicht kein Zweifel daran, dass die Patches notwendig sind.

Wenn auch bisher wenige der CPU Lücken remote praktisch ausnutzbar waren, so ist die Informationspolitik von Intel auch nicht vertrauenswürdig. Nur weil wir nicht davon wissen, bedeutet es nicht, dass mit den Patches nicht auch andere Lücken oder schwerwiegendere Auswirkungen der Lücken gefixt werden.

Unsere Hardware wird nunmal mittlerweile von viel Software angetrieben, die wir nicht direkt im Einfluss haben. Bis andere Systeme mit offener Firmware dieses Problem evtl. verbessern, sollte man zumindest Firmware / UEFI oder BIOS auch aktuell halten.

Das ist aber nur meine persönliche Meinung.

[JeGr]

>  die direkte Interaktion mit der Firewall erlauben, besteht aus meiner Sicht kein Zweifel daran, dass die Patches notwendig sind.

Was heißt an der Stelle Interkation mit der Firewall? Proxy o.ä. ist mir da zu schwammig. Bei den meisten Intel-Bug-Lücken geht es um Dinge wie shared memory oder anderes, was im aktiven System durch User o.ä. ausgelesen werden muss. Da gilt dann wieder das Prinzip "Wer den Schlüssel zum Schloß hat..". Sprich wenn eh nur Admins Login-Access auf die Firewall haben um irgendwelche Attacken auszuführen - und die meisten Sachen haben keinen Remote Attack Vector der mir bekannt wäre - dann sehe ich da herzlich wenig Problem. Denn wenn mein Admin gegen mich arbeitet habe ich eh größere Probleme. Genauso beim Loadbalancing, egal wie viel darüber läuft, es braucht keinen Login auf die Firewall mit dem man lokale Userrechte hätte und überhaupt anfangen könnte, irgendwas auszulesen. Nur "Interaktion" mit der Firewall ist da nicht genug.

> Nur weil wir nicht davon wissen, bedeutet es nicht, dass mit den Patches nicht auch andere Lücken oder schwerwiegendere Auswirkungen der Lücken gefixt werden.

Nur wenn die Lücken selbst von Intel gefunden worden wären. Dann könnten Sie den Deckel drauf halten. Die meisten Sachen kamen/kommen aber von externen Researchern und die gehen fast alle nach den gleiche Disclosure Regeln vor, legen also nach einer grace period die Sachen offen. Und es ist klar, da gibts natürlich auch keine 100% Sicherheit, dass da nichts bei ist. Aber die Angriffsfläche bei einer Firewall / Appliance ohne/mit wenig lokalen Usern ist eben recht moderat bis gering gegenüber bspw. einem Virtualisierungshost mit VMs bei denen potentiell die VM Isolation davon betroffen ist.

> Das ist aber nur meine persönliche Meinung.

Ist auch völlig in Ordnung :) Ich sehe das aber an der Stelle als Gefahrenanalyse und Abschätzung. 100% habe ich sowieso nicht - wie hoch ist also eine Gefährdung bei X, Y oder Z. Und wenngleich ich dir absolut recht gebe, dass da bei Intel viel im Argen liegt und mich das auch tierisch ankiekst, sehe ich die tatsächlich nutzbare Angriffsfläche bei Appliance Einsatz à la Firewall oder Loadbalancer eher gering(er) als bei anderen Nutzungsszenarien. Zumal man ja auch mit Einberechnen muss, wie viel einen das ggf. Performance kostet und ob das noch vertretbar ist (bzw. man da entsprechend Puffer eingeplant hat in seiner Hardware).

Grüße

[banym]

Sprich wenn eh nur Admins Login-Access auf die Firewall haben um irgendwelche Attacken auszuführen - und die meisten Sachen haben keinen Remote Attack Vector der mir bekannt wäre - dann sehe ich da herzlich wenig Problem. Denn wenn mein Admin gegen mich arbeitet habe ich eh größere Probleme. Genauso beim Loadbalancing, egal wie viel darüber läuft, es braucht keinen Login auf die Firewall mit dem man lokale Userrechte hätte und überhaupt anfangen könnte, irgendwas auszulesen. Nur "Interaktion" mit der Firewall ist da nicht genug.

Mit Interaktion meine ich alles was ein User direkt mit der Firewall tun kann oder was die Firewall für den User tut außer Pakete zu schubsen oder zu blocken:
Captive Portale, Proxy, Virenscanning oder Emails scannen.

Zumindest eine Lücke mit NetSprectre hat sich hier ja schon als gefährlich herausgestellt, ohne das Schadcode auf dem System ausgeführt werden musste. Je mehr Dienste dem Benutzer also zur Verfügung stehen mit denen er "reden" kann, um so größer die Angriffsfläche für eben auch diese Art von Problemen.

Da die meisten größeren Büchsen nunmal eine Intel-CPU haben, muss mann dann auch nicht lange nach großen Problemen in der Software suchen wenn eine CPU ohne aktuellen Microcode der einfachere Angriffsvektor ist.

Die Situation bessert sich aber nun ja langsam. ARM, x86 von AMD und RISC-V können hier evtl. in Zukunft einfach wieder mehr punkten und Vielfalt belebt das Geschäft.