Last Week on My Mac: POPSS, vulnerability by documentation

It puzzles me how some major vulnerabilities seem to come and go without so much as a ripple of attention, while others raise a disproportionate hue and cry.

Last week saw two good examples: almost every major operating system, including macOS, has had to have a replacement kernel due to the POPSS bug, but headlines have been dominated by a problem with the Signal messaging app leaking information, as originally reported by Alec Muffett.

Let’s get the Signal problem out of the way before moving on to the more serious. The redoubtable Patrick Wardle discovered that Signal was not clearing message notifications properly, leading to them accumulating in a database stored locally by macOS. Although not difficult to extract from that database, that requires local access to the Mac, and is most plausible as a part of forensic analysis.

No doubt someone nasty will come along with some malware which extracts old Signal notifications and sends them back to a remote server. But if you’re one of the great majority of Mac users who don’t use Signal, and if your messages are mainly apologies for returning home late, or not doing domestic duties, its importance might escape you. If you do use Signal, there has been an update to address the issue now.

By far the more worrying bug for almost all computer users is known as POPSS, and in its own way, is almost as important as Meltdown or Spectre. Like those vulnerabilities, its mechanism is obscure in the sense that it’s difficult to explain, as that requires understanding of processor instruction sets and operating system kernels. If you want to go there, the best thing is to read Nick Peterson and Nemanja Mulasmajic’s detailed explanation.

The functional summary of POPSS is that most kernel engineering teams who have been developing for Intel and AMD processors in recent years have made certain assumptions about what happens when two instructions are used in fairly common circumstances. Those assumptions were based on a reading of documentation which fell short of being clear, and it now turns out that they were wrong.

As a result of this, almost all operating system kernels running on Intel or AMD processors exhibit a bug which can be exploited by malware. The results of exploitation, on Windows at least, are that an attacker can load and execute unsigned kernel code – which is potentially very serious. This is to be demonstrated by Peterson and Mulasmajic at the BlackHat 2018 conference in early August.

POPSS has so far affected operating systems from the following vendors:

  • Apple (macOS only, not iOS, watchOS or tvOS)
  • Check Point (security appliances)
  • DragonFly BSD
  • FreeBSD
  • Linux
  • Microsoft (most recent versions of Windows)
  • Red Hat
  • SUSE Linux
  • Synology (NAS systems)
  • Unbuntu
  • VMware
  • Xen.

It may also affect any embedded operating system running on Intel or AMD processors, such as those in routers, internet hardware, IoT devices, even washing machines, although it will clearly not be exploitable on all of those.

POPSS was the vulnerability which was the most important fix in Apple’s recent Security Update 2018-001 for High Sierra, and which currently hasn’t been fixed in Sierra or El Capitan. It was POPSS which almost certainly accounted for the replacement of all Apple’s kernel extensions in that security update, which in turn helped make it such a large and extensive update, as I reported here.

Fixing POPSS in High Sierra has exposed a vulnerability in Apple’s policy on security, though. Given its nature and extent, it is hardly plausible that Sierra and El Capitan (and every Intel implementation of macOS before them) are not vulnerable to POPSS. By fixing the bug in High Sierra but not making any announcement about previous versions of macOS, Apple has effectively revealed that those unpatched kernels are vulnerable unless and until it releases further security updates. Silence can be very informative at times.

This vulnerability is exceptional in several respects: its near-universal occurrence across the range of modern operating systems, the fact that it can be fixed relatively easily with no performance penalties, and its lack of publicity. It is also one of very few vulnerabilities which have directly resulted from inadequate documentation.

When every major kernel development team misunderstands instruction set documentation in this way, that documentation has failed, which is the root cause of the POPSS bug. Intel’s documentation has been revised, and is now in its 67th edition. It is hardly scant: if you have the time to browse its eleven volumes, you’ll see that they appear exhaustive.

Compared to Apple’s user or developer documentation of macOS, Intel’s is copious, complete, and meticulously accurate – even though it was clearly flawed in this single respect.

The lesson of POPSS is surely the importance of accurate and explicit documentation. It is a lesson which Apple, for one, has yet to learn. Only yesterday I highlighted an error in its developer documentation of WebKit views. With better documentation, the developers of Signal may have avoided their recent bug. With better documentation, Apple’s EFI firmware wouldn’t have been in such a mess this time last year. And with better documentation, we wouldn’t waste so much time trying to work around bugs, or discover how to do things which should be straightforward.

Rather than using WWDC 2018 as the platform to inflict whole new sets of bugs and problems in macOS 10.14 and iOS 12, Apple should be telling us how massive investment in better quality management and documentation are transforming the reliability and usability of its products. I somehow doubt it.