invokestatic

So let’s take a step back and look at this threat model.

1) An attacker is MITMing your connection. This is already not easily exploitable by most threat actors short of being on a public Wi-Fi network, otherwise you are likely at the nation-state level attacker at this point.

2) An attacker knows exactly which Git repo you’re about to clone and has prepared a malicious version (noting they can’t snoop on your encrypted web traffic).

3) An attacker has developed a way to differentiate between Git over HTTPS and Safari, by using a side channel “fingerprinting” method that works with your exact versions of git and macOS.

4) You don’t pin the git clone to a particular hash or signature.

This is already a very low level of exploitability. All of these things need to be satisfied for the attack you’re describing to work.

Now let’s look at a more practical attack that exists regardless of if you have the patch from Apple.

1) A maintainer of an open source project you use has their GitHub account compromised due to credential stuffing and commits a malicious version.

2) You don’t pin the git clone to a particular hash or signature.

This attack is significantly more exploitable and has happened over and over again in supply chain attacks.

But look at the commonality: in both, no certificate pinning or signature checking was done. If you follow best practices, this stops both attacks dead cold.

This is the security engineering. It’s not just checking boxes. It’s evaluating risks.

1) I would argue that different trust stores are a carryover macOS’s Unix heritage. Having multiple roots of trust is actually very common. For instance Firefox maintains their own root of trust from the system, it’s called NSS. Different programming languages like Java and Rust also often use different roots. It’s not amazing, and has holes, but a lot of it comes down to historical reasons and a certain level of risk acceptance.

2) Yes, but actually, this is exactly why we have defense in depth. This is a temporary measure while a permanent patch is coming. Defense in depth means a single hole does not result in compromise. I would argue that this situation with Apple demonstrates defense in depth actually working as intended. If this was the permanent solution, and no further patch was coming from Apple, then yes, it would violate defense in depth.

3) Related to above, yes. But it’s not permanent.

An attacker absolutely cannot “easily distinguish” between a git clone and visiting the website and swap the certificate.

To know whether a request is a git client or web browser, an attacker needs to be able to inspect the contents of the web request (to check the user agent or whatever). If the site is using a legitimate certificate, the attacker has no way to inspect the contents because it is encrypted with a key they do not control.

If an attacker used their own, eMudhra-signed certificate, it would throw the certificate error in Safari.

Going against the grain here but I think this is decent security engineering from Apple. They patched the highest exploitable things immediately (Safari, Mail, etc). The residual risk is using these command line tools while someone is actively MITMing your connection.

How often are people “git clone”ing a repo without browsing to the GitHub site first? Safari would throw up certificate errors. And also, TLS on Git doesn’t even authenticate the code you’re downloading is legitimate at all. It could be modified by the Git host or a supply chain attack, etc.

Yea, it’s not great. Ideally the risk is reduced to zero from patching. But a lot of the times we accept some level of cybersecurity risk out of practicality. This is why we have responsible disclosure windows lasting months. It takes a while to do proper release engineering and testing for something like a whole OS update.

Yeah… it was patched in the source 3 days ago. Check the linked GHSA.

The python mermaidx library works for this, which works well for generating documentation with embedded diagrams as part of CI/CD but the layout/rendering can sometimes be very wonky. For instance I will have a bunch of connections crossing over each other instead of neatly arranged to avoid it. Changing the layout settings does not fix it so sometimes I will just export it from mmdc and embed a png.

It’s part of the MSVC x64 ABI, not a part of the kernel ABI. The kernel and user mode (Win32) APIs all use C linkage so vtables are not relevant and the ABI is a convention of the compiler not the OS. Practically speaking though if your software runs on Windows it will probably use the MSVC ABI.

Firmware & systems dev here, ARM still dominates in the microcontroller space. There are some niche offerings from major vendors but again they are niche. Espressif is the sole exception with their newer ESP32-C series chips, but they can get away with it due to their massive HAL. ARM Cortex is still the standard because there’s a decade or two of inertia behind it.

An apt comparison would be C vs Rust. Yes, Rust may be growing in market share, but C still dominates.

The privacy points in general are valid, but what irritates me is using this rationale against kernel mode anti cheats specifically.

You do not need kernel access to make spyware that takes screenshots. You do not need a privileged service to read the user’s browser history.

You can do all of this, completely unprivileged on Windows. People always seem to conflate kernel access with privacy which is completely false. It would in fact be much harder to do any of these things from kernel mode.

Actually, it is completely true. The TPM threat model has historically focused on software-based threats and physical attacks against the TPM chip itself - crucially NOT the communications between the chip and the CPU. In the over 20 year history of discrete TPMs, they are largely completely vulnerable to interposer (MITM) attacks and only within the last few years is it being addressed by vendors. Endorsement keys don’t matter because the TPM still has to trust the PCR commands sent to it by the CPU. An interposer can replace tampered PCR values with trusted values and the TPM would have no idea.

Technically yes, but it would produce an untrusted remote attestation signature (quote). This is roughly equivalent to using TLS with a self-signed certificate — it’s not trusted by anyone else. TPMs have a signing key that’s endorsed by the TPM vendor’s CA.

No, this is not true at all. Microsoft requires their system vendors (Dell, HP, etc) to allow users to enroll their own Secure Boot keys through their “Designed for Windows” certification.

Further, many distributions are already compatible with Secure Boot and work out of the box. Whether or not giving Microsoft the UEFI root of trust was a good idea is questionable, but what they DO have is a long, established history of supporting Linux secure boot. They sign a UEFI shim that allows distributions to sign their kernels with their own, distribution-controlled keys in a way that just works on 99% of PCs.

Well, this project is literally about me circumventing/removing Boot Guard so I don’t know how it’s corporate authoritarianism. I’m literally getting rid of it. In doing so I get complete control of the BIOS/firmware down to the reset vector. I can disable ME. To me, that’s ultimate freedom.

As a power user, do I want boot guard on my personal PC? Honestly, no. And we’re in luck because a huge amount of consumer motherboards have a Boot Guard profile so insecure it’s basically disabled. But do I want our laptops at work to have it, or the server I have at a colocation facility to have it? Yes I do. Because I don’t want my server to have a bootkit installed by someone with an SPI flasher. I don’t want my HR rep getting hidden, persistent malware because they ran an exe disguised as a pdf. It’s valuable in some contexts.

Yeah, but that doesn’t give me a reason to use the hot air station and hot plate collecting dust on my desk ;)