Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Hardware>EFI-Sicherheitsupdate

EFI-Sicherheitsupdate

Hannes Gnad
Hannes Gnad02.07.1508:13
Es geht um:

https://support.apple.com/kb/DL1823
https://support.apple.com/de-de/HT204934

ebenso enthalten in 10.10.4. Dieses einzelne Installationspaket ist ca. 100 MB groß, und die Installation zieht ein typisches EFI-Update nach sich, also wohl ein Flashen des EFI. Ein Blick in die Systeminformationen zeigt keinen Unterschied in der Version des "Boot-ROM" auf einem MacBook Pro 13" (Early 2011). Apple dokumentiert zwar eine Verfügbarkeit dieses Updates für 10.8.5, 10.9.5 und eben 10.10.4, aber spannender ist die Frage, welche Hardware damit versorgt wird - und das dokumentiert Apple leider nicht.

Wären es alle Geräte, auf denen 10.8.5+ läuft, dann wäre das eine ziemlich große Flotte. Ein Versuch in das Installationspaket zu blicken war bisher nicht von Erfolg gekrönt, Pacifist ist gescheitert, das ist irgendwie seltsam codiert.

Info willkommen!
0

Kommentare

jogoto02.07.1508:23
Hannes Gnad
Ein Versuch in das Installationspaket zu blicken war bisher nicht von Erfolg gekrönt, Pacifist ist gescheitert, das ist irgendwie seltsam codiert.
Ein erster Schritt sich zu verteidigen kann sein sich nicht in die Karten schauen zu lassen. Wenn die Verteidigungsstrategie auf dem Silbertablett liegt, kann sich jeder mit Ahnung neue Angriffsstrategien ausdenken.
Und jetzt bin ich auch schon wieder raus aus der Diskussion, denn den 5000-Zeiler zur Verteidigung offenen Codes im Allgemeinen von sierkb tu ich mir nicht an ...
0
Dirk!02.07.1508:26
jogoto
Ein erster Schritt sich zu verteidigen kann sein sich nicht in die Karten schauen zu lassen. Wenn die Verteidigungsstrategie auf dem Silbertablett liegt, kann sich jeder mit Ahnung neue Angriffsstrategien ausdenken.

„Security through Obscurity“ war noch nie eine gute Idee!

Aber abgesehen davon, würde ich auch gerne wissen, wie man herausfinden kann, ob der eigene Rechner das Update installiert hat bzw. ob es dort nötig ist.
Bei mir ist das Flashen des EFI bei Upgrade auf 10.10.4 nur auf einem System passiert.
0
jogoto02.07.1508:31
Dirk!
Deinen Link kann ich Dir wärmstens empfehlen.
Sicherheit, die ausschließlich auf der Geheimhaltung oder Verschleierung von Verfahren beruht, hat sich oft als ungenügend herausgestellt. Als Ergänzung bestehender Sicherheitskonzepte kann sich Verschleierung jedoch als wirkungsvoll z. B. gegenüber automatisierten Angriffen erweisen.
Hab ich was anderes gesagt, wenn ich von einem ersten Schritt spreche?
0
john
john02.07.1508:36
ich hatte beim update auf 10.10.4 auch definitiv ein firmware update mit dabei (inklusive beep, neustart, ladebalken.. ihr wisst schon)

ob sich an der firmware version was geändert hat, weiss ich nicht. nicht drauf geachtet.
mbp early 2011 15"
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
Hannes Gnad
Hannes Gnad02.07.1508:42
Auf einem MacBook (Early 2009) mit 10.8.5 wurde das Update nicht angeboten, meine erste Vermutung ist, daß die Grenze irgendwo bei den 2010er, eher 2011er Modellen liegt.
0
Hannes Gnad
Hannes Gnad02.07.1508:47
Ah, schau, schau, Apple dokumentiert es doch!

https://support.apple.com/en-us/HT201518

Und siehe, der Zusatz "(2015-001)" geht runter bis zu den 2011er-Modellen.

Stellt sich nun die Frage: Sind die älteren Geräte nicht betroffen, oder werden die einfach nicht mehr mit dem Update versorgt?
0
rosss02.07.1510:00
Hannes Gnad
Ah, schau, schau, Apple dokumentiert es doch!

https://support.apple.com/en-us/HT201518

Und siehe, der Zusatz "(2015-001)" geht runter bis zu den 2011er-Modellen.

Stellt sich nun die Frage: Sind die älteren Geräte nicht betroffen, oder werden die einfach nicht mehr mit dem Update versorgt?

Interessant, dass das Modelljahr für die Sicherheit ausschlaggebend zu sein scheint. Der 5,1 Mac Pro wurde noch bis vor zwei Jahren neu verkauft, meiner ist von 2012 – aber vielleicht hatte er EFI schon als Kind und ist nun immun?

Konkrete Info seitens Apple ist wohl zuviel verlangt. Siehe auch fremd-SSD-TRIM support – nur eine allgemeine Warnung ohne Hintergrundinfo. (Anscheinend haben Samsung 8xx SSD einen üblen Firmware-Bug).
0
Dirk!02.07.1510:02
Hannes Gnad

Hey, danke für den Link. Jetzt kann ich überprüfen, ob das Update wenigstens auf allen Modellen, für die es angeboten wird, installiert wurde.

<PARANOIA>Der Vorsichtige würde jetzt natürlich einwenden, dass die von Mac angezeigte Versionsnummer von der (bisher zum Glück) hypothetischen Schadsoftware auch bereits manipuliert wäre, ohne dass man das feststellen könnte.</PARANOIA>
0
Tzunami
Tzunami03.07.1505:07
rosss
Interessant, dass das Modelljahr für die Sicherheit ausschlaggebend zu sein scheint. Der 5,1 Mac Pro wurde noch bis vor zwei Jahren neu verkauft, meiner ist von 2012 – aber vielleicht hatte er EFI schon als Kind und ist nun immun?

Der MacPro 4,1/5,1 ist in der Tat nicht von dem Bug betroffen

Mit Pacifist kann man im Paket gucken, welche Geräte gepatched werden.

IM121 ist z.B. iMac 12,1

IM121_0047_21B_LOCKED.scap
IM131_010A_B08_LOCKED.scap
IM141_0118_B11_LOCKED.scap
IM142_0118_B11_LOCKED.scap
IM143_0118_B11_LOCKED.scap
IM144_0179_B10_LOCKED.scap
IM151_0207_B03_LOCKED.scap
MB81_0164_B06_LOCKED.fd
MBA41_0077_B12_LOCKED.scap
MBA51_00EF_B03_LOCKED.scap
MBA61_0099_B19_LOCKED.scap
MBA71_0166_B06_LOCKED.fd
MBP81_0047_2AB_LOCKED.scap
MBP91_00D3_B0B_LOCKED.scap
MBP101_00EE_B09_LOCKED.scap
MBP102_0106_B08_LOCKED.scap
MBP111_0138_B15_LOCKED.scap
MBP112_0138_B15_LOCKED.scap
MBP114_0172_B04_LOCKED.fd
MBP121_0167_B07_LOCKED.fd
MM51_0077_B12_LOCKED.scap
MM61_0106_B08_LOCKED.scap
MM71_0220_B03_LOCKED.scap
MP61_0116_B15_LOCKED.scap
0
Hannes Gnad
Hannes Gnad03.07.1508:31
Tzunami
Der MacPro 4,1/5,1 ist in der Tat nicht von dem Bug betroffen

Mit Pacifist kann man im Paket gucken, welche Geräte gepatched werden.
Warum sind die älteren Modelle nicht betroffen?
0
john
john03.07.1508:33
Hannes Gnad
Tzunami
Der MacPro 4,1/5,1 ist in der Tat nicht von dem Bug betroffen

Mit Pacifist kann man im Paket gucken, welche Geräte gepatched werden.
Warum sind die älteren Modelle nicht betroffen?

weil sie kein update bekommen haben. ist doch logisch
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
Fard Dwalling03.07.1511:33
Mh. Ich bekomme bei meinem MBP 15" Early 2011 sowie beim Mac Mini 2011 kein Update angeboten. 10.10.4 ist bei beiden drauf. Boot-ROM scheint auch schon up-to-date zu sein. Und SMC ist sogar höher als in Apples Liste.

Boot-ROM-Version: MBP81.0047.B2A
SMC-Version (System): 1.69f4
0
Dirk!03.07.1511:37
Fard Dwalling

Wo ist Dein Problem?

Das Update ist in 10.10.4 enthalten und wie Du selbst nachgesehen hast, ist Dein EFI auch schon aktuell, also wurde es offenbar korrekt installiert.
0
Fard Dwalling03.07.1511:45
Ach so. Sorry. Ich dachte das wird mit dem 10.10.4 separat angeboten. Hab ich wohl überlesen.
0
Hannes Gnad
Hannes Gnad03.07.1512:05
Separat bei 10.8.5 und 10.9.5, inklusive bei 10.10.4.
0
john
john03.07.1512:32
Fard Dwalling
Ach so. Sorry. Ich dachte das wird mit dem 10.10.4 separat angeboten. Hab ich wohl überlesen.

dein mac hat fies gepiept und sich auch mehrmals neugestartet bei dem update. das war ein firmware update.
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
PaulMuadDib03.07.1512:41
Es hat doch hier jemand so eine URL zu einem Programm gepostet, mildem man das EFI auf diesen Fehler hin überprüfen kann. DarwinDumper hieß das oder so.
0
Fard Dwalling03.07.1512:47
Nö könnte ich jetzt nicht so sagen. Gefiept hat da nix. Auch auf dem Air und dem Mini hat nix gefiept.
Ladebalken lief, ist aber ja häufiger bei den großen Updates.
Also eigentlich nix ungewöhnliches.
john
dein mac hat fies gepiept und sich auch mehrmals neugestartet bei dem update. das war ein firmware update.
0
john
john03.07.1512:58
doch hat er. 100%ig
„biete support. kostenlos, kompetent und freundlich. wähle zwei.“
0
Fard Dwalling03.07.1513:04
Auch wenn die Lautstärke runtergefahren ist? Den Startgong höre ich ja auch nicht.
0
MikeMuc03.07.1516:55
Das mit dem Fiepen / piepen mag ich auch nicht unterschreiben. Kann aber schon so gewesen sein. Mir ist bei meinem 15" late 2011 auf gegen Fall der 2. Neustart und davor der "dicke" Ladebalken aufgefallen. Wenn man nun nicht die ganze Zeit draufsteht dann einfach Tee / Kaffe trinken gegangen ist dann kann einem das natürlich entgangen sein
0
Larsen2k4
Larsen2k403.07.1517:03
john
doch hat er. 100%ig

Nein, nicht unbedingt. Mein 2012er mini hat die Firmware auch ohne lauten Piepton aktualisiert - lediglich die Power-LED blinkte kurz. Beim iMac meiner Frau kam aber eben auch das übliche Piepen (bzw. eher mächtiges Tuten) gefolgt von dem Einspielen des Updates.
0
dom_beta05.07.1500:33
Hannes Gnad
Stellt sich nun die Frage: Sind die älteren Geräte nicht betroffen, oder werden die einfach nicht mehr mit dem Update versorgt?
Hannes Gnad
Warum sind die älteren Modelle nicht betroffen?


weil:

kein Thunderbolt
„...“
0
pb_user
pb_user05.07.1514:42
hier hat auch nichts getutet, aber vielleicht kann man den prozess (firmware-update) irgendwo auslesen?
geht das?
0
pb_user
pb_user05.07.1514:55
Fard Dwalling
Mh. Ich bekomme bei meinem MBP 15" Early 2011 sowie beim Mac Mini 2011 kein Update angeboten. 10.10.4 ist bei beiden drauf. Boot-ROM scheint auch schon up-to-date zu sein. Und SMC ist sogar höher als in Apples Liste.
Boot-ROM-Version: MBP81.0047.B2A
SMC-Version (System): 1.69f4
sorry, wenn ich hier noch mal nachhake: hier steht doch MBP81.0047.B2A, aber in der liste weiter oben von Tzunami MBP81_0047_2AB – das ist doch nicht dasselbe; was ist den nun vorher / nachher?

mit der aufrichtigen bitte um aufklärung ...
0
Dirk!05.07.1515:17
pb_user

Ich kann nur nochmal den Link von Hannes wiederholen:

Da steht alles drin.
0
pb_user
pb_user05.07.1519:33
sorry, ja – hatte ich inzwischen auch gelesen.
trotzdem danke und einen schönen sonntag ...
0
Hannes Gnad
Hannes Gnad05.07.1520:49
dom_beta
Hannes Gnad
Warum sind die älteren Modelle nicht betroffen?
weil: kein Thunderbolt
Ist das sicher? Quellen?
0
gfhfkgfhfk06.07.1509:21
Diese Angriffsvektoren wurden durch die Umstellung auf PCHs eingeführt, d.h. alle Core i Systeme sollten prinzipiell davon betroffen sein. Die älteren Macs mit Core bzw. Core2 sind davon wohl noch nicht betroffen.
0
Tzunami
Tzunami06.07.1522:00
gfhfkgfhfk
Diese Angriffsvektoren wurden durch die Umstellung auf PCHs eingeführt, d.h. alle Core i Systeme sollten prinzipiell davon betroffen sein. Die älteren Macs mit Core bzw. Core2 sind davon wohl noch nicht betroffen.

Soviel ich mitbekommen habe soll es was mit Thunderbolt zu tun haben. Da der MacPro 4,1 und 5,1 nicht betroffen sind, der 6,1 schon, wird diese Aussage bestärkt.

Der Nehalem Xeon basiert auf der selben Technologie wie der Nehalem Core i und müsste nach der PCH Theorie ebenfalls betroffen sein, das ist aber nicht der Fall (selber getestet).
0
Tzunami
Tzunami06.07.1522:15
Oder wurde PCH erst mit Sandy-Bridge eingeführt? Dann könnte es doch am PCH liegen.
0
gfhfkgfhfk07.07.1509:45
Du vergißt, daß es verschiedene CPU Familien bei Intel gibt. Die Desktop CPUs und die Xeon für die älteren MacPros (3,1 und älter) wurden mit der Einführung der ersten Core i CPUs getrennt. Seitdem gibt es komplett unterschiedliche Dies und PCHs/Chipsätze. Passend zur ersten Core i Serie gab es auch Xeon die 3400er Serie. Ab der zweiten Core i Serie wurden die Xeons umbenannt in Xeon E3. Apple hat bisher keinen Xeon 3400, E3, E3v2, E3v3 oder E3v4 verbaut.

In den MacPros 4,1 und 5,1 wurden Xeons der Serien 3500, 3600, 5500 oder 5600 verbaut, dazu wurde der Chipsatz X58 genutzt. Hier werden alle PCIe Slots noch über den Chipsatz angesteuert. D.h. intern ist das noch ein Chipsatz und erst mit den Xeon E5 (SandyBridge-EN bzw. -EP) wurden diese Xeon Familie auf PCHs umgestellt. Im MacPro 6,1 ist ein Xeon E5v2 mit einem PCH 602J verbaut. Die Xeon E5 wurden von Apple nicht genutzt, genauso wie die Xeon E5v3, die es schon seit längerem gibt.

Etwas zum Thema Codenamen der CPU Familien. Intel hat für die Core i CPUs bisher die folgenden Namen verwandt: Nehalem, SandyBridge, IvyBridge, Haswell, Broadwell und Skylake. Dazu verwendet Intel immer wieder Buchstabenzusätze, um die verschiedenen Familien zu unterscheide: E, EN, EP, EX. Wenn man also den Codenamen mit Anhängsel liest handelt es sich nicht mehr um eine einfache Desktop/Mobile CPU sondern um etwas anderes, was einen komplett anderen Die mit einem komplett anderem Chipsatz/PCH nutzt. -E sind die Core i7 für Sockel 2011 (hat Apple nie genutzt), EN und EP sind Xeon E5 und die EX sind Xeon E7.

Zu den Exploits: Es gibt drei verschiedene Exploits. Einmal den Optionboot ROM Exploit. Dieser nutzt die Tatsache aus, daß Thunderbolt Devices ein Optionboot ROM haben dürfen. Logischerweise können nur Macs mit Thunderbolt betroffen sein.
Der S3 Sleep Exploit, davon sind soweit bekannt alle PCHs betroffen. Daher ist davon kein MacPro 4,1 oder 5,1 betroffen, weil diese keine PCHs haben. Da wurde der S3 Mode noch anders umgesetzt.
Der SpeedRacer Exploit. Hier wird ein Bug im PCH (Chipsatz?) ausgenutzt, der es auf einem Multicore System erlaubt das Flag für den Schreibschutz eines bestimmten RAM Bereiches aufzuheben, so daß man einen Handler installieren kann der ein verseuchtes (U)EFI flasht.
0
fronk
fronk07.07.1512:19
Hmm, seltsamerweise wird mein iMac (27", Mitte 2011, Modell 12,2) in der Liste gar nicht aufgeführt. Die Boot-ROM-Version stimmt aber mit der, desModells 12,1 überein …
„Haters, go away and hate yourself!“
0
Hannes Gnad
Hannes Gnad07.07.1513:08
Doch, wird er, bitte nochmals genau anschauen.
0
fronk
fronk07.07.1516:33
Wo bitte steht ein iMac mit Modell-Identifizierung 12,2?
„Haters, go away and hate yourself!“
0
Hannes Gnad
Hannes Gnad07.07.1516:47
IM121_0047_21B_LOCKED.scap
0
Dirk!07.07.1517:14
Hannes Gnad

Er sucht aber nach 12,2 und nicht nach 12,1. Keine Ahnung ob er nur nicht lesen kann oder es den 12,2 iMac wirklich gibt
0
Hannes Gnad
Hannes Gnad07.07.1518:00
Ah. Ja, den 12,2 gibt es auch, das ist halt die 27"-Version, und ich vermute, daß dieser Patch für die jeweiligen Modellreihen bei beiden Display-Größen angewendet wird - sonst würde das wenig Sinn machen...
0
sierkb13.08.1519:13
jogoto
Ein erster Schritt sich zu verteidigen kann sein sich nicht in die Karten schauen zu lassen. Wenn die Verteidigungsstrategie auf dem Silbertablett liegt, kann sich jeder mit Ahnung neue Angriffsstrategien ausdenken.
[…]
Und jetzt bin ich auch schon wieder raus aus der Diskussion

Jeder mit Ahnung kann sich aber ganz genauso neue Angriffsszenarien ausdenken oder entdecken und dadurch dann in ganz erheblichen Maße dazu beitragen, dass das Produkt vorher an der Stelle dann sicherer gemacht wird, bevor ein anderer, der weniger Gutes im Schilde führt, auf die gleiche Idee kommt und diese Schwachstelle dann gezielt missbraucht und ausnutzt. Darum geht's!

Mary Ann Davidson, Sicherheitschefin bei Oracle, ist, wie Du, ebenfalls grad' raus aus der Diskussion nach ihrem zweifelhaften Post, den Oracle innerhalb von 24 Stunden zurückgezogen, revidiert und dann das Gegenteil bekräftigt hat – nicht ohne sich von Mary Ann Davidson zu distanzieren:

heise (12.08.2015): l+f: Wenn Oracles Security-Chefin vom Leder zieht
Wer Lücken in Oracle-Software findet, sollte sie wohl lieber nicht dem Hersteller melden. Sonst droht Ärger mit Oracles Rechtsanwälten.

jax.de (12.08.2015): Rolle rückwärts, aber zu spät: Oracles Chief Security Officer brüskiert Bug Hunter
Vor allem im Internet gilt bekanntermaßen: Ist die Büchse der Pandora erstmal geöffnet, kriegt man sie so leicht nicht mehr zu. Diesen Umstand erlebt Mary Ann Davidson, Chief Security Officer bei Oracle, gerade am eigenen Leib. In einem rund 3000 Zeichen umfassenden Rant hatte sie klar gemacht, dass sie die Nase voll davon habe, dass Kunden und Security Researcher eigene Sicherheitstests mit Oracle-Software durchführen.

WSJ (12.08.2015): Oracle Deletes CSO’s Blog Post Critical of Customer Attempts to Find Bugs in its Software

Fortune (11.08.2015): Oracle's security chief posted a crazy ranting tirade. Then Oracle deleted it.
A top software executive vents her frustration–at those trying to help.


Und hierzu kann man wohl auch nur uneingeschränkt zustimmen:

hackerone (12.08.2015): Provocation From Oracle CSO Shows Security Can Sit At The Big Kids' Table

[…]
"Most (of her claims) seem to be around that she implies reported security bugs are annoying. Oracle is a very large and rich company, with products that are widely distributed and used for critical applications. Period," says Ira Winkler, president of Secure Mentem. "They have a responsibility to make their software as strong as possible."

Rather than being annoyed at bug reports, he says, Oracle should be taking them seriously and making it easier to submit them. What's more, says some researchers, Davidson should recognize that Oracle has missed some doozies over the years and that often they're found by barely scratching the surface of Oracle products, much less reverse engineering.

"I have been discovering vulnerabilities in Oracle applications since 2007 and just myself have found 30-plus issues, and my company's team probably has discovered twice more than that in total," says Alexander Polyakov, CTO of ERPScan, a firm focused on enterprise resource planning software security. "Do you think that you need to have advanced reverse engineering skills or be a nerd from Mr. Robot to find a vulnerability? Frankly speaking, no, you don't. For most I've found, I did not use any reverse engineering tools and just tried to enter data in a field where nobody expected this type of data."
[…]
"A critical vulnerability is a critical vulnerability and if one slips through Oracle's review processes, that is the one that they need to study the most, and concede that it is better reported to them first,"

At the end of the day, the provocation from Davidson proved to actually be a really great thing for the security world. It was a litmus test that showed that the overwhelming majority of the IT and security community have come to a realization that has been long in coming over the past decade. In the end, things like license agreements and DMCA don't matter one whit to the real bad guys here-the criminals who will monetize all of the vulnerabilities that exist whether or not security researchers find and disclose them.

"Oracle is not just a vendor, it's the vendor which software is installed in almost every Fortune 2000 company, and our lives depend on their solutions' security. Nuclear Power Plants, Manufacturing, Banking. Name anything," says Polyakov. "When this kind of vendor is telling that they don't need any help from external researchers, in terms of vulnerability findings, well, this world is too dangerous for that."


Und jetzt bin ich auch schon wieder raus aus der Diskussion

Wie Mary Ann Davidson, Chief Security Officer bei Oracle?
denn den 5000-Zeiler zur Verteidigung offenen Codes im Allgemeinen von sierkb tu ich mir nicht an ...

Ich hoffe, Dir ist es kurz genug, die Links bzw. deren Inhalt und zugrundeliegenden Ereignisse sprechen für sich.
jogoto
Hab ich was anderes gesagt, wenn ich von einem ersten Schritt spreche?

Sieh es ein, Du hast mindestens nicht genügend nachgedacht bzgl. dem, was Du da von Dir gegeben hast. Wie Oracles Sicherheitschefin Mary Ann Davidson auch grad'. Sie wurde von Oracle zurückgepfiffen, und Oracle distanziert sich von ihr. Niemand will es so sehen wie sie, alle schütteln nur den Kopf. Sogar Oracle.
Dirk!
„Security through Obscurity“ war noch nie eine gute Idee!

+1






On-Topic und zum Thread-Thema ("EFI-Sicherheitsupdate"):

Trammell Hudson hat, wie zuvor angekündigt, inzwischen Details veröffentlicht:

Trammell Hudson: Thunderstrike 2: Mac firmware worm details

Sehr lesenswert, wie ich finde. Auch die in Richtung Hersteller (in diesem konkreten Fall: Apple) gemeinten Zeilen, doch bitte ihre Hausaufgaben zu machen – erst recht, wenn gewisse Lücken seit Jahren bekannt sind und sogar Fixes vom Chip- und BIOS/EFI-Hersteller Intel schon lange zur Verfügung stehen, sie vom Hersteller (hier: Apple) nur genommen und umgesetzt werden müssten, er dies bisher aber, aus welchen Gründen auch immer (Nachlässigkeit, fehlender Prioritäten-Fokus in Bezug auf Sicherheit liegen nahe), unterlassen hat.
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.