LOL I either forgot or just learned that #Mudge has somewhat ineffectively blocked me on Twitter.

Man that guy sucks. Security folks (or anybody, really) should not take him seriously.

What a fucking clown.

So #Mudge is no longer at #CISA?

That’s probably a good thing for #CISA (and all of companies and individuals who work and partner with #CISA), given that Zatko has shown a willingness to put his own petty beefs with his managers ahead of, you know, the security of the company of which he was the nominal CISO.

https://www.linkedin.com/posts/executivegov_careergrowth-cybersecurity-executivemoves-activity-7227742943124615169-tb0I?utm_source=share&utm_medium=member_ios

I’m disappointed to see #Mudge taken seriously by an organization as critical to the Internet’s security as #CISA.

Having observed #Zatko’s tenure at #Twitter, I believe he is, at best, incompetent, and at worst, an opportunistic grifter. His Twitter "whistleblower" testimony contained confusing inaccuracies and, IMO, was more of an indictment of Mudge’s service as Twitter’s security chief then of Twitter itself.

It is a shame our tax dollars are now paying his salary.

https://www.washingtonpost.com/politics/2023/09/05/cisa-makes-big-name-hire-its-crusade-against-insecure-products/

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.

So, in July 1998, Mudge posted in Phrack an article titled “FORTH Hacking on Sparc Hardware” explaining how to use the monitor to change the UID of your shell process to be zero/the root user:

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.

https://www.giac.org/paper/gcih/182/privilege-elevation-system-memory-editing-sun-sparc-platform/101427

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.

So when I look at Apple, and there’s an apparent hardware debugging widget in the memory which can be driven by undocumented means to poke the entire system, for a device which they are literally advertising as robust and secure, my reactions are basically:

#apple #essay #mudge #openboot #operationTriangulation #sunMicrosystems

https://alecmuffett.com/article/108789