Shameless plug for a couple blog posts I have written as explorations of the Virtualization Framework:

- Introduction when Monterey was released: https://macops.ca/macos-monterey-apple-silicon-vms/

- New features added in Ventura: https://macops.ca/virtualization-updates-2022-06/

Cool! What’s the difference between Virtualisation.framework and Hypervisor.framework?

Hypervisor.framework provides only the bare necessities: the ability to manage vCPUs, stage 2 page tables, and handle hypervisor exits. It does not do any sort of virtualization except for the CPU itself (which, on ARMv8, is very little due to hardware providing good primitives already). Virtualization.framework is full operating system virtualization suitable for running modern Linux and macOS guests.

AFAIK Virtualization.framework is built on top of Hypervisor.framework. Former is high-level one allowing you to create Linux VM with few hundreds lines of code. Latter allows you to run your whatever you want with few tens of thousands lines of code, but absolute freedom when it comes to drivers and every low level detail.

Very cool thanks!

Have you met OS X?

Whataboutism without data smells like FUD.

Uh, it's pretty well-known that Apple ships some absolutely ancient stuff in macOS. It can't be that hard to find a reference… but, here ya go:

  » curl --version
  curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (securetransport) libressl/2.8.3 zlib/1.2.11 nghttp2/1.41.0
  release-date: 2019-03-27
  protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
  features: asynchdns gss-api http2 https-proxy ipv6 kerberos largefile libz multissl ntlm ntlm_wb spnego ssl unixsockets
  » bash --version
  gnu bash, version 3.2.57(1)-release (x86_64-apple-darwin20)
  copyright (c) 2007 free software foundation, inc.

So unless Apple has some patches on top of that, as curl's website says, there are 22 vulns. in that 2.5 yo version.[1]

That version of bash is from about when the copyright indicates, i.e., 14 years ago. Thankfully there probably isn't a good exploit path for bash that doesn't already involve one being able to run code, but still, as a dev, it'd be nice to get a more recent version.

[1]: https://curl.se/docs/releases.html

Subsequent versions of bash are GPLv3 “encumbered”. Apple as an organisation have decided that the best way to avoid potential licensing issues with GPLv3 is to avoid GPLv3, which appears to be part of the intent of GPLv3. Tell me, who is hurting consumers of software? I will accept that Apple is partly to blame - they could be, and should be more open and perhaps contribute more, or at least follow Google’s lead and use it as marketing. But the GPLv3 is a burdensome license that even the star of the movement has rejected. That is holding back OSS as much as anything else. Making it commercially hard to use the software isn’t helping adoption or contributions.

`sudo dscl . -read Users/root accountPolicyData`

When you do this you'll get the creationTime and passwordLastSetTime as seconds since the 'epoch' – January 1, 1970, 00:00:00 (UTC). These are numbers like 1474441704.265237 which aren't very easy for a human to read :-)

To convert this into a human-readable date and time, open a terminal and do this:

  python

  >>> import time

  >>> time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime(1474441704.265237))

You'll get something like 'Wed, 21 Sep 2016 07:08:24'

(I'm sure you can do this in other languages than python...)

If you're already in the terminal you could instead enter

  date -r 1474441704

This is a much better answer!

One of my Macs is showing a root password change date of Nov 10th 2017. I can't explain that, so I'm reinstalling now. It did have sshd enabled and remotely accessible, though I thought root login was prohibited.

If I understood correctly, this particular bug was only exploitable from the GUI and this machine hasn't been away from home, so it's likely this isn't related, but posting here, in case it's part of a bigger picture.

OK, I guess when doing OP's root trick, the root user gets activated/created, and that's that's when the PW gets set to empty. I guess that's where my passwordLastSetTime comes from.

This works remotely as well (although not through SSH, obviously).

possibly the same timestamp here: 1510300538.767916 'Fri, 10 Nov 2017 04:55:38'

Oh wow. Is there any other explanation for this other than this having been exploited in the wild for almost three weeks? Or maybe someone just tried to log in over SSH to exploit some other weakness (something like predictable SSH passwords on jailbroken iOS devices), and happened to create the root user on your machine?

Did you also have sshd running, and do you know what kind of network you were using at the time?