Glad I listened to @SGgrc beforehand as he put it into more digestable language and a sober context.
The talk starts with low-level code deepdives out of the gate. Truetype fonts are turing complete?!
Someone tried to hack Kaspersky via a complex iPhone attack (“Operation Triangulation”); Jake Appelbaum got (reluctantly) kicked out of CCC; NASA launched a cybersecurity guide for the space industry; India’s Prime Minister Narendra Modi tried to strongarm and retaliate against Apple over hacking warnings, plus early Pandemic Roundup items.
What the history of OpenBoot, Phrack, Mudge & Solaris, can teach us about the wisdom (or not) of Apple’s building their iPhone security debugging-backdoor-NSA-hack thing
In the days before people really, really, cared about security — when it was more amazing that mainstream computers worked at all rather than that they offered falsifiable guarantees about privacy and integrity, and most of all in the days before hackerdom decided that it would be great if all the world’s computation ran on “…surely 640Kb is enough for anyone?” glorified MS-DOS personal computers rather than on architectures specifically designed to carry the weight of “big data”… back in those days there was the concept of a monitor.
By monitor we don’t mean VDU nor LCD screen, but instead that what you considered to be your entire computer operating system was something which could be paused, inspected, poked, amended, restarted or halted, all by a little parasitic computer system which probably polled the device tree and booted it up in the first place. The consequence of the monitor was that — beyond being a mere “boot loader” — you were essentially running your entire operating system kernel under a live debugger on a 24×7 basis.
This “debugger” was the monitor; sometimes it was separate hardware, sometimes it was just a firmware-level subsystem with which you could interrupt your operating system at any point, and call back into. At Sun Microsystems (in particular, but much the same was available elsewhere) the monitor evolved into a complete and flexible little solution called OpenBoot, which subsequently became a PCI standard (it is/was(?) even in MacOS) and it was massively powerful.
Unfortunately: with great power comes great responsibility, which (per the first paragraph) people were not really aware of, yet.
Fire up the trusty OpenBoot system via L1-A and get the pointer to thecred structure via :ok hex f5e09000 18 + l@ .f5a99858ok goNow, get the effective user id byok hex f5a99858 4 + l@ .309 (309 hex == 777 decimal)ok goOf course you want to change this to 0 (euid root):ok hex 0 f5a99858 4 + l!ok gocheck your credentials!Alliant+ iduid=777(mudge) gid=1(other) euid=0(root)
tl;dr — press some keys, type a magic incantation in Forth and you become “root”
Let’s just say that OpenBoot was a very powerful and essential medicine… but that provision of that power caused security side-effects/issues that were not going to go away in any short period of time. An excellent little white paper from GIAC provided a synopsis and context from a few years later, in 2001.
The technique of elevating user privileges by manually editing system runtime memory is an exploit that can be used to subvert all operating system security measures. This vulnerability is not operating system platform specific and exists in all computer hardware that utilizes a programmable firmware component for hardware control and bootstrapping procedures. This paper will explain this vulnerability as a class of exploit and utilize the SUN Microsystems’ OpenBoot programmable ROM (PROM) and Solaris as a technical example.
Speaking as one of the people who had to clean up the mess: we/Sun Microsystems should have done a lot more to mitigate the ability of people to get at this powerful medicine; this issue was significant amongst others which drove Sun’s internal security community to create and force the adoption of the “Secure By Default” initiative, and to formalise customer provision and promote adoption of the Solaris Security Toolkit which (amongst many other configuration changes) locked-down several different routes by which the OpenBoot monitor could be exploited.
From the perspective of 2023: this all should have happened 5, perhaps 10 years before Mudge’s posting, but there was neither the corporate will — nor customer will/expertise — to address the matter at that time.
Kaspersky elaborates on Operation Triangulation in which domestic subscribers, diplomatic missions, and embassies were targeted with Apple iOS zero-days (Russia’s FSB accused the USA for Operation Triangulation). The threat actors introduced two validators in the infection chain in order to ensure that the exploits and the implant do not get delivered to security researchers. Additionally, microphone recording could be tuned in such a way that it stopped when the screen was being used. They used private undocumented APIs in the course of the attack, indicating a great understanding of iOS internals. They additionally implemented in some modules support for iOS versions prior to 8.0, suggesting access for years. Link:https://securelist.com/triangulation-validators-modules/110847/