debianforum.de

Verfasst: **05.01.2018 11:33:44**

sommerregen hat geschrieben:
04.01.2018 21:14:01
... Viel besser wäre es, Webseiten z.B. für Lynx zu optimieren ...

Das hört sich für manche sicher seltsam und für andere ziemlich extrem an, es ist aber absolut richtig.

Verfasst: **05.01.2018 12:07:26**

Man könnte auch, wie es seinerzeit der Transmeta Crusoe gemacht hat, den Prozessor emulieren. Das war nur damals (~ 2000) recht langsam, die Idee dahinter aber ist genial. Solche Bugs wie Meltdown/Spectre würden dann mit einem einfachen Firmwareupdate behoben.

Verfasst: **05.01.2018 12:09:42**

Kann mich erinnern. Für Transmeta hat Torvalds doch eine Zeit lang gearbeitet?

Verfasst: **05.01.2018 12:32:22**

Hallo

hier die betroffenen Intel-CPU

https://security-center.intel.com/advis ... geid=en-fr

mfg
schwedenmann

Verfasst: **05.01.2018 12:56:20**

Frage zum Thema "First Party Isolation" als Empfehlung zur Schadensbegrenzung.
Macht so etwas Sinn: https://www.ghacks.net/2017/11/22/how-t ... n-firefox/

Verfasst: **05.01.2018 12:58:13**

Wenigstens habe ich in meinem Netbook den Atom N270, der ist scheinbar nicht betroffen.

Verfasst: **05.01.2018 13:05:59**

schwedenmann hat geschrieben:
05.01.2018 12:32:22
hier die betroffenen Intel-CPU
https://security-center.intel.com/advis ... geid=en-fr

Mmmh, bin mir da nicht so sicher,
scheinbar zeigt Intel nur die Prozessoren-Reihen auf, welche aktuell von Intel noch unterstützt werden,
also noch nicht unter End Of Life stehen.
jue's N270 dürfte schon EoL sein, von den CPUs aus den 90er ganz zu schweigen ...

Verfasst: **05.01.2018 13:32:50**

Heute gab es für Sid ein Inte-Microcode-Update. Soweit ich das überblicken kann, beziehen sich die Änderungen im Wesentlichen auf Schadensbegrenzung bei Spectre:

intel-microcode (3.20171215.1) unstable; urgency=high

* Add supplementary-ucode-CVE-2017-5715.d/: (closes: #886367)
New upstream microcodes to partially address CVE-2017-5715
+ Updated Microcodes:
sig 0x000306c3, pf_mask 0x32, 2017-11-20, rev 0x0023, size 23552
sig 0x000306d4, pf_mask 0xc0, 2017-11-17, rev 0x0028, size 18432
sig 0x000306f2, pf_mask 0x6f, 2017-11-17, rev 0x003b, size 33792
sig 0x00040651, pf_mask 0x72, 2017-11-20, rev 0x0021, size 22528
sig 0x000406e3, pf_mask 0xc0, 2017-11-16, rev 0x00c2, size 99328
sig 0x000406f1, pf_mask 0xef, 2017-11-18, rev 0xb000025, size 27648
sig 0x00050654, pf_mask 0xb7, 2017-11-21, rev 0x200003a, size 27648
sig 0x000506c9, pf_mask 0x03, 2017-11-22, rev 0x002e, size 16384
sig 0x000806e9, pf_mask 0xc0, 2017-12-03, rev 0x007c, size 98304
sig 0x000906e9, pf_mask 0x2a, 2017-12-03, rev 0x007c, size 98304
* Implements IBRS and IBPB support via new MSR (Spectre variant 2
mitigation, indirect branches). Support is exposed through cpuid(7).EDX.
* LFENCE terminates all previous instructions (Spectre variant 2
mitigation, conditional branches).

Verfasst: **05.01.2018 13:52:41**

schwedenmann hat geschrieben:
05.01.2018 12:32:22
Hallo

hier die betroffenen Intel-CPU

https://security-center.intel.com/advis ... geid=en-fr

Die Meldung bezieht sich nur auf Spectre und die Liste der betroffenen CPUs dürfte wirklich unvollständig sein.

jue hat geschrieben:
05.01.2018 12:58:13
Wenigstens habe ich in meinem Netbook den Atom N270, der ist scheinbar nicht betroffen.

Bezüglich Meltdown hast du recht. Bei Spectre bin ich mir unsicher.

Es gibt eine "Spectre Attack Demo" auf Gthub. [1] Das dort bereitgestellte Binary ist für x86_64 compiliert, läuft also auf dem N270 nicht. Ich kriege außerdem den Code nicht compiliert: NoPaste-Eintrag

40117
Unsere tschechischen Nachbarn testen aber gerade ein ganz ähnliches Exploit. [2] Das kriege ich compiliert, es kommt aber auf dem N270 unter Stretch offenbar nur Müll raus: NoPaste-Eintrag

40118

Ich werde nach Möglichkeit am Wochenende Tests auf einem Merom und einem Penryn machen.

[1] https://github.com/Pl4gue/spectre-attack-demo
[2] http://www.abclinuxu.cz/blog/programy/2 ... tre-na-amd

Verfasst: **05.01.2018 14:55:06**

Heute morgen befand sich auf der Titelseite unserer Dorfzeitung aus dem Hause Lensing-Wolff der wissende Kommentar einer Journalistin zu diesem Intel-Bug. Das spannende daran ist, dass dieser Kommentar doch mehr oder weniger die Wirklichkeit außerhalb des inneren Kreises von Hardware-Spezialisten wiederspiegelt. Der Titel des Kommentars lautet "Aussehen vor Sicherheit". Sie hat sich darüber beklagt, dass die Industrie anscheinend nicht bereit ist, diesen Design-Fehler auf ihre Kosten zu beheben und das nun Softwarehersteller diese Suppe auslöffen müssen. Sie sagt wörtlich: "Das Design der Chips müsste für die Behebung verändert werden. Für den Designer undenkbar. Das Aussehen geht scheinbar vor Sicherheit."

Tja, zuerst war ich amüsiert, und nach einem Blick in den Spiegel hatte ich dann die Erkenntnis, die ist ja gar nicht alleine... eigentlich stehe ich fast direkt neben ihr. Und ich glaube, neben mir stehen noch etliche andere... auch hier aus dem Forum. Ich versuche die ganze Zeit dem Gespräch hier zu folgen und etwas daraus abzuleiten. Aber es ist definitiv das gleiche, als würde ich mit meinen Beipackzettel-Kenntnissen zu Medinait und Aspirin einem Medizinerkongress beiwohnen, auf dem die Symptome und Behandlungsmethoden einer Ebola-Epidemie in Afrika diskutiert wird. Ich kann einfach keine persönliche praktische Betroffenheit ableiten oder einschätzen. Bei Ebola wüsste ich, wenn ich jetzt dort in der Region eine Reise geplant hätte, gäbs ein hohes Risiko für mich. Ich weiss, wenn jemand aus meiner Familie oder dem direkten Arbeitskollegenkreis die nachsten Tage von dort zurückkäme, gäbs ein hohes Risiko für mich. Ich weiss, es gibt ein zufälliges Restrisiko, wenn mich bei Mäcces an der Theke stehend der Nachbar anhustet und weil der gerade von dort gekommen ist... oder das in der Anprobe der Jeans im Jeansshop kurz zuvor einer gesteckt hat, der gerade von dort und infiziert zurückgekommen ist.

Aber all das würde mich jetzt nicht so wirklich beunruhigen, weil ich denke, dass mich das nicht in größeren Maße betrifft, als die Gefahr beim Ka***n vom Blitz getroffen zu werden. Was braucht es also, damit dieser Bug tatsächlich zu einer echten und persönlichen Bedrohung der eigenen Datenintegrität wird? Reicht es allein, das eine solche CPU installiert ist, oder brauchts zusätzlich und zwingend den Schaden ermöglichende Rahmenbedingungen? Die theoretische Auswirkung steht ausser Frage, aber wie kann man die praktische Auswirkung der Gefahr auf einen selber einschätzen? In Worten, die auch die o.g. Journalistin versteht?

Ich habe verstanden, dass Java-Script ein Problem ist.... gut, ist es für mich nicht, weil ich Java nicht erlaube. Kritische Software aus subversiven Repos nutze ich auch nicht. Für mich wäre also weitaus signifikanter die Frage, ob ein "unterwanderter" Browser nicht eine viel größere Gefahr darstellt. Mit unterwandert meine ich nicht einen mit Malware infizierten Browser, sondern Bestandteile der Grundfunktionalität des Browser, der genau für diese Attacke Routinen enthält. Im Moment nutze ich wieder Firefox, wegen Radfahrers hartnäckiger und teilweise auch überzeugender Meinung... aber ist nicht gerade FF selber (oder andere quasi-kommerzielle Browse) die weit offene Tür in den eigenen Rechner? Und ganz ehrlich, die Nähe von Mozilla zu Google finde ich nicht toll.

Gibts noch andere hier im Forum interessiert mitlesende User, die dem Thema zwar folgen, die aber ebenfalls nicht einschätzen können, ob sie aufgrund ihrer eigenen und persönlich nur für sie geltenden IT-Nutzungs-Rahmenbedingungen überhaupt betroffen sind?

Verfasst: **05.01.2018 15:13:36**

TomL hat geschrieben:
05.01.2018 14:55:06
Für mich wäre also weitaus signifikanter die Frage, ob ein "unterwanderter" Browser nicht eine viel größere Gefahr darstellt.[...] Grundfunktionalität des Browser, der genau für diese Attacke Routinen enthält.

Ja, ich vermute das waere eine groessere Gefahr wenn einer der grossen Browserhersteller das machen wuerde.
Wenn Mercedes in allen seinen Autos den Airbag heimlich deaktiviert besteht auch eine viel größere Gefahr um zu kommen.

Browser ist heutzutage ein wichtiger Bestandteil durch dem viele Informationen fliesen. Dazu eher wenig Konkurrenz. Zu diesen Zeitpunkt kann ich mir nicht vorstellen das Mozilla, Google, MS oder Apple damit fremde Rechner uebnernehmen wollen.

Oder war die Frage ob die Wahrscheinlichkeit hoeher ist von Spectre getroffen zu werden als von einem Boesen Browser?

Verfasst: **05.01.2018 15:30:08**

dufty2 hat geschrieben:
05.01.2018 13:05:59
... jue's N270 dürfte schon EoL sein, von den CPUs aus den 90er ganz zu schweigen ...

Ich bin mir nicht nur nicht sicher, ich habe absolut keine Ahnung. Aber hier https://www.heise.de/newsticker/meldung ... 34667.html steht:

Bezüglich Spectre und Meltdown offenbar bombensicher: der alte Nettop-PC Asus EeeBox B202 mit Atom N270

Ich habe zwar ein Ideapad S10e, es hat aber auch den selben Atom.

Verfasst: **05.01.2018 15:39:07**

hikaru hat geschrieben:
05.01.2018 13:52:41
Es gibt eine "Spectre Attack Demo" auf Gthub. [1] Das dort bereitgestellte Binary ist für x86_64 compiliert, läuft also auf dem N270 nicht. Ich kriege außerdem den Code nicht compiliert: 40117
Unsere tschechischen Nachbarn testen aber gerade ein ganz ähnliches Exploit. [2] Das kriege ich compiliert, es kommt aber auf dem N270 unter Stretch offenbar nur Müll raus: 40118

Letztendlich beruhen die beiden erwähnten proggies auf dem im
https://spectreattack.com/spectre.pdf
angegebenen Programm im Anhang "A Spectre Example Implementation".
Das habe ich mal sauber raus-kopiert aus dem PDF und lässt sich auf einen Atom N450 auch sauber kompilieren:

Code: Alles auswählen

$ gcc -std=c99 -O0 spectre.c -o spectre
$ ./spectre 
Reading 40 bytes:
Ungültiger Maschinenbefehl

Das Problem ist 'rdtscp', das es erst ab Nehalem-CPUs gibt (glaube ich).
In den Beispielen wird das durch 'rdtsc' ersetzt und nun geht die Ausführung.
Brauchbare Ergebnisse erhalte ich dann aber auch nicht,
bin aber viel zuwenig in der Thematik drin, ob die "rdtscp=>rdtsc"-Ersetzung noch den "korrekten" Exploit für Atom-CPUs (und älter) darstellt resp. - wie von jue erwähnt - auf Atoms gar nicht gehen würde.

Verfasst: **05.01.2018 16:30:47**

TomL hat geschrieben:
05.01.2018 14:55:06
Der Titel des Kommentars lautet "Aussehen vor Sicherheit". Sie hat sich darüber beklagt, dass die Industrie anscheinend nicht bereit ist, diesen Design-Fehler auf ihre Kosten zu beheben und das nun Softwarehersteller diese Suppe auslöffen müssen. Sie sagt wörtlich: "Das Design der Chips müsste für die Behebung verändert werden. Für den Designer undenkbar. Das Aussehen geht scheinbar vor Sicherheit."

Abgesehen davon, dass die zitierte Journalistin kein Deutsch kann (TomL aber schon, "anscheinend" <> "scheinbar"), hat sie schon recht. Denn eigentlich müssten die Chip-Hersteller ja jetzt für Alle nachbessern, nicht wahr?
Wäre ich ein betroffener Soft-Worker, würde es mir gewaltig stinken, jetzt für die andere Fraktion die Kastanien aus dem Feuer holen zu müssen.

Aber das eigentlich Bemerkenswerte an der ganzen Geschichte ist doch, dass wir kleinen End-User mal wieder vorgeführt bekommen, was für hilflose Dummies wir doch sind, die wir in irgendeiner Weise Dingen und vor allem Institutionen, die wir nie ganz durchschauen können, vertrauen.

Na, das ist jetzt reichlich OT, sorry.

Verfasst: **05.01.2018 17:44:05**

Auch OT, aber wenn man’s so stehen lässt, verbreitet’s sich nur noch weiter:

TomL hat geschrieben:
05.01.2018 14:55:06
Ich habe verstanden, dass Java-Script ein Problem ist.... gut, ist es für mich nicht, weil ich Java nicht erlaube.

Java hat mit Javascript nix zu tun. Und ein Problem mit JS ist’s zwar auch, allerdings genauso wie mit allen anderen Sprachen.

Verfasst: **05.01.2018 18:39:02**

Fand ich nett zum lesen:
https://www.raspberrypi.org/blog/why-ra ... -meltdown/

Verfasst: **05.01.2018 19:40:00**

Eben gerade den 4.14.11er ausprobiert. Angezeigt wird unter anderem
cat /proc/cpuinfo model name : Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz . bugs : cpu_insecure
Und sogleich entdeckt, der 4.14.12 ist raus. Enthält zum Beispiel

commit 151d7039757b71ebd9d170af0944562f51149372
Author: Tom Lendacky <thomas.lendacky@amd.com>
Date: Tue Dec 26 23:43:54 2017 -0600

x86/cpu, x86/pti: Do not enable PTI on AMD processors

commit 694d99d40972f12e59a3696effee8a376b79d7c8 upstream.

AMD processors are not subject to the types of attacks that the kernel
page table isolation feature protects against. The AMD microarchitecture
does not allow memory references, including speculative references, that
access higher privileged data when running in a lesser privileged mode
when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting
the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI
is set.

Wobei ich mich frage, welchen Einfluss eine nicht deaktivierte PTI auf den AMD haben sollte, obwohl dieser gar keine Kernel-Page-Table besitzt.

Verfasst: **05.01.2018 20:00:19**

Auf meinem Tp T410 und 4.14.0-2-amd64:

Code: Alles auswählen

cat /proc/cpuinfo
model name	: Intel(R) Core(TM) i5 CPU       M 480  @ 2.67GHz
bugs		:

und bei 4.14.0-3-amd64:

Code: Alles auswählen

cat /proc/cpuinfo | grep bugs
bugs		: cpu_insecure
bugs		: cpu_insecure
bugs		: cpu_insecure
bugs		: cpu_insecure

Verfasst: **05.01.2018 20:04:18**

niemand hat geschrieben:
05.01.2018 17:44:05
Auch OT, aber wenn man’s so stehen lässt, verbreitet’s sich nur noch weiter:
TomL hat geschrieben:
05.01.2018 14:55:06
Ich habe verstanden, dass Java-Script ein Problem ist.... gut, ist es für mich nicht, weil ich Java nicht erlaube.
Java hat mit Javascript nix zu tun. Und ein Problem mit JS ist’s zwar auch, allerdings genauso wie mit allen anderen Sprachen.

Richtig, aber ich habe geglaubt, dass ergibt sich zwangsläufig aus dem Wort "erlaube"... womit natürlich der Script-Blocker gemeint ist. Ob man echte Java-Programme erlauben kann, im Sinne einer Whitelist ...?... ich denke ebensowenig grundsätzlich oder exklusiv oder situativ, wie das auch für mit anderen Programmiersprachen geschriebene und kompilierte Programme gilt.

Verfasst: **05.01.2018 20:06:26**

Bei mir kernel 4.13

Code: Alles auswählen

model name      : AMD Athlon(tm) II X2 245 Processor
bugs            : tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs null_seg amd_e400

Verfasst: **05.01.2018 20:09:06**

Code: Alles auswählen

# cat /proc/cpuinfo
processor	: 0
vendor_id	: GenuineIntel
cpu family	: 6
model		: 158
model name	: Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
stepping	: 9
microcode	: 0x5e
cpu MHz		: 799.987
cache size	: 6144 KB
bugs		:
bogomips	: 6816.00

Habe ich jetzt Glück gehabt?

Verfasst: **05.01.2018 20:14:43**

TomL hat geschrieben:
05.01.2018 20:04:18
Ob man echte Java-Programme erlauben kann, im Sinne einer Whitelist ...?

Ja, natürlich kann man auch Java-Applets via z.B. NoScript managen. Zumindest konnte man es bei den Prä-FF57-Versionen. Ob das heute noch so ist, weiß ich nicht. Aber ist eh OT.

Verfasst: **05.01.2018 20:27:36**

@niemand, danke für die Hinweise....

Zum Thema, den folgenden Link habe ich gerade im Raspberry Forum zum gleichen Thema gefunden:
https://entwickler.de/online/security/c ... 25774.html

Die für mich wichtigste Aussage lautet
Wie gefährlich ist das?
Das kommt ganz darauf an, worum es geht. Sowohl Meltdown als auch Spectre lassen sich nur ausnutzen, wenn der Angreifer Code auf dem angegriffenen Rechnern ausführen kann. Was dann passieren kann, zeigt das Video eines Meltdown-Angriffs eindrucksvoll. Gefährdet sind also alle Rechner, auf denen ein Angreifer Code ausführen kann. Und das sind eigentlich alle.

Ich interpretiere das so, dass ich bereits Schadsoftware auf meinem Rechner laufen haben muss, um zu Schaden zu kommen. Oder anders rum gesagt, wer sehr gewissenhat seine Software pflegt und darauf verzichtet, Fremdquellen in die sources-liste einzutragen und kein leichtsinniger Surfer ist, hat gute Chancen, dass dieser Bug ohne Auswirkung an ihm vorübergeht.

Verfasst: **05.01.2018 20:55:30**

TomL hat geschrieben:
05.01.2018 20:09:06

Habe ich jetzt Glück gehabt?

Leider nein, es sind alle Intel betroffen. Hinzugekommen ist, dass seit den letzten Kernelneuerungen diese CPU`s neuerdings als "insecure" eingestuft werden.

Verfasst: **06.01.2018 04:40:17**

Harakiri hat geschrieben:
05.01.2018 19:40:00
Eben gerade den 4.14.11er ausprobiert. Angezeigt wird unter anderem
cat /proc/cpuinfo model name : Intel(R) Core(TM) i3-2370M CPU @ 2.40GHz . bugs : cpu_insecure

In dem um Mitternacht erschienenen 4.14.13-rc1 wurde das geändert:
Statt "cpu_insecure" heisst es jetzt "cpu_meltdown",
was - denke ich - auch die bessere sprich genauere Bezeichnung ist.

Yo, wir leben in einer schnelllebigen Zeit.

debianforum.de

Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug

Re: Hardware-Sicherheitslücken: Meltdown und Spectre: ehem. Intel-Bug