Braucht aber physischen Zugriff, richtig?

Einen nicht behebbaren Fehler darf es nicht geben. Das würde ich als einen gravierenden konzeptionellen Fehler bezeichnen. "Fehler" gibt es immer, das Thema Sicherheit ist dermaßen komplex, dass man von der Prämisse ausgehen muss, dass immer eine Lücke vorhanden ist.

Natürlich muss man immer davon ausgehen, dass es Fehler geben kann. Aber manchmal lässt sich einfach Fehler einfach nicht beheben. Zum Beispiel, wenn es ein Hardwarefehler.

Einen nicht behebbaren Fehler darf es nicht geben. Das würde ich als einen gravierenden konzeptionellen Fehler bezeichnen. "Fehler" gibt es immer, das Thema Sicherheit ist dermaßen komplex, dass man von der Prämisse ausgehen muss, dass immer eine Lücke vorhanden ist.

Selbst die hier als völlig unfähig dargestellten Leute bei Intel haben es in der Vergangenheit immer wieder geschafft Fehler nachträglich zu beheben oder doch einen akzeptablen Weg gefunden wie man mit dem Fehler leben kann. Und ich meine nicht nur Spectre.

[…]

Intern nennt Apple die Secure Enclave "SEP" – kurz für "Secure Enclave Processor". Auf dem SEP läuft ein eigenes, von Apple entwickeltes Betriebssystem namens "sepOS".

[…]

L4 microkernel family

L4 is a family of second-generation microkernels, generally used to implement Unix-like operating systems, but also used in a variety of other systems.

L4, like its predecessor L3 microkernel, was created by German computer scientist Jochen Liedtke as a response to the poor performance of earlier microkernel-based operating systems. Liedtke felt that a system designed from the start for high performance, rather than other goals, could produce a microkernel of practical use. His original implementation in hand-coded Intel i386-specific assembly language code in 1993 sparked intense interest in the computer industry.[citation needed] Since its introduction, L4 has been developed for platform independence and also in improving security, isolation, and robustness.

There have been various re-implementations of the original binary L4 kernel interface (ABI) and its successors, including L4Ka::Pistachio (Uni Karlsruhe), L4/MIPS (UNSW), Fiasco (TU Dresden). For this reason, the name L4 has been generalized and no longer only refers to Liedtke's original implementation. It now applies to the whole microkernel family including the L4 kernel interface and its different versions.

L4 is widely deployed. One variant, OKL4 from Open Kernel Labs, shipped in billions of mobile devices.[1][2]

[…]

History

The poor performance of first-generation microkernels, such as Mach, led a number of developers to re-examine the entire microkernel concept in the mid-1990s. The asynchronous in-kernel-buffering process communication concept used in Mach turned out to be one of the main reasons for its poor performance. This induced developers of Mach-based operating systems to move some time-critical components, like file systems or drivers, back inside the kernel.[citation needed] While this somewhat ameliorated the performance issues, it plainly violates the minimality concept of a true microkernel (and squanders their major advantages).

Detailed analysis of the Mach bottleneck indicated that, among other things, its working set is too large: the IPC code expresses poor spatial locality; that is, it results in too many cache misses, of which most are in-kernel.[3] This analysis gave rise to the principle that an efficient microkernel should be small enough that the majority of performance-critical code fits into the (first-level) cache (preferably a small fraction of said cache).

[…]

Commercial deployment

In November 2005, NICTA announced[11] that Qualcomm was deploying NICTA's L4 version on their Mobile Station Modem chipsets. This led to the use of L4 in mobile phone handsets on sale from late 2006. In August 2006, ERTOS leader and UNSW professor Gernot Heiser spun out a company called Open Kernel Labs (OK Labs) to support commercial L4 users and further develop L4 for commercial use under the brand name OKL4, in close collaboration with NICTA. OKL4 Version 2.1, released in April 2008, was the first generally available version of L4 which featured capability-based security. OKL4 3.0, released in October 2008, was the last open-source version of OKL4. More recent versions are closed source and based on a rewrite to support a native hypervisor variant called the OKL4 Microvisor. OK Labs also distributed a paravirtualized Linux called OK:Linux, a descendant of Wombat, as well as paravirtualized versions of SymbianOS and Android. OK Labs also acquired the rights to seL4 from NICTA.

OKL4 shipments exceeded 1.5 billion in early 2012,[2] mostly on Qualcomm wireless modem chips. Other deployments include automotive infotainment systems.[12]

Apple A series processors beginning with the A7 contain a Secure Enclave coprocessor running an L4 operating system[13] based on the L4-embedded kernel developed at NICTA in 2006.[14] This implies that L4 is now shipping on all iOS devices, the total shipment of which is estimated at 310 million for the year 2015.[15]

[…]

References
1. "Hypervisor Products - General Dynamics Mission Systems". gdmissionsystems.com. Archived from the original on 15 November 2017. Retrieved 26 April 2018.
2. "Open Kernel Labs Software Surpasses Milestone of 1.5 Billion Mobile ... (Press release). Open Kernel Labs. January 19, 2012. Archived from the original on February 11, 2012.

[…]

13. "iOS Security, iOS 12.3" (PDF). Apple Inc. May 2019.
14. Mandt, Tarjei; Solnik, Mathew; Wang, David (July 31, 2016). "Demystifying the Secure Enclave Processor" (PDF). BlackHat USA. Las Vegas, NV, USA. Archived (PDF) from the original on October 21, 2016.
15. Elmer-DeWitt, Philip (October 28, 2014). "Forecast: Apple will ship 310 million iOS devices in 2015". Fortune. Archived from the original on September 27, 2015. Retrieved October 25, 2015.

New (guest) blog post: "CVE-2020–9854: "Unauthd"

https://objective-see.com/blog/blog_0x4D.html

by: Ilias Morad (@A2nkF_)

Impressive exploit chain that combines three macOS logic bugs, to elevate privileges from user, to ring-0!

"Soon"

Have a read!
...and mahalo to @A2nkF_

Ich frage mich ob die Gewährleistung bei so einem Produktfehler greifen würde und man deshalb ein neueres Modell oder Geld zurück fordern könnte.

Außerdem ebenso zur gleichen Zeit:

heise (03.08.2020): TCC-Absicherung in macOS "komplett geknackt"
[i]Einem Sicherheitsexperten ist es gelungen, Apples eigentlich drakonische "Entitlement Checks" zu umgehen. Das Problem wurde gepatcht.

Das ist ein gewöhnlicher Sicherheitsvorfall

der ja auch gepacht wurde.

Beunruhigend ist, wie simpel das Leck ist.

Das wäre sicher vermeidbar gewesen.

Aus meiner Sicht muss eine gute Sicherheitsarchitektur, ob nun soft- oder hardwarebasiert darauf konzipiert sein, dass es Lücken gibt und man dann definierte Wege hat, sie zu stopfen.
Wenn man versucht eine perfekte Lösung baut, die sich dann wider Erwarten als nicht perfekt herausstellt und dann nichts mehr machen kann, hat man echte Probleme.