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 ;)

I have a slow burn project where I simulate a supply chain attack on my own motherboard. You can source (now relatively old) Intel PCH chips off Aliexpress that are “unfused” and lack certain security features like Boot Guard (simplified explanation). I bought one of these chips and I intend to desolder the factory one on my motherboard and replace it with the Aliexpress one. This requires somewhat difficult BGA reflow but I have all the tools to do this.

I want to make a persistent implant/malware that survives OS reinstalls. You can also disable Intel (CS)ME and potentially use Coreboot as well, but I don’t want to deal with porting Coreboot to a new platform. I’m more interested in demonstrating how important hardware root of trust is.

Calling it a “kill switch” buries the lede here. What these politicians call a kill switch is technology to passively detect drunk driving. In 2021, Congress passed a law (HALT Drunk Driving Act) requiring NHTSA to eventually require auto makers to install passive drunk driver detection systems. NHTSA missed their statutory November 2024 deadline to finalize the regulations on this so it’s not like this amendment failing has a substantial impact. This technology is still many model years (maybe 2029? 2030?) away. I make no claims to the merits of this technology, I just feel the need to clarify the current situation.

This is conceptually interesting to me because I see this as almost a more generic TI Webench. I’m curious why your focus in the sized “grid” blocks (presumably for placement directly on the PCB layout) instead of doing the same but for the schematic. That way I still have the flexibility of laying out the board how I want to meet eg mechanical constraints instead of working around a 12.7mm grid.

I’ve been paying for Google Workspace for my custom domain for years basically just so I can use Gmail. For just $7 more dollars a month, I upgraded my plan to access Gemini Pro, which has guaranteed enterprise-grade privacy controls. I think this is currently the best value platform for anyone who values their privacy for LLMs. If Apple and the DoD trust Google’s internal controls, I do too.

Because Red Hat pays the salaries of dozens (hundreds?) of kernel maintainers all over different subsystems. So they’re subject matter experts, and know exactly which ones are relevant to Red Hat.

I have an almost identical story except the state in question was Nevada. I’m curious what “dubious” domain it was, for me it was video game cheats. Maybe I’m actually the co-owner you’re talking about. :)

Checking version numbers usually isn’t a good way of determining whether software on Linux is vulnerable to CVEs. Big distros (especially Red Hat derivatives) lock software versions but back port security patches. Reporting “vulnerabilities” solely based on reported version number is pure noise.

Actually, VAC handles Cheat Engine and the like very well. You won’t get banned for simply having them open, only for having them attached to the game, which I think is reasonable.

I am exploring whether PCB prototypes can be imported tariff-free under HTSUS 9817.85.01. However getting a tariff broker to figure out how to do this properly might also be expensive.

I ordered an FPGA development board from China last month that unfortunately didn’t make it out of the country before tariffs/end of de minimis set in. So it’s now sitting in a consolidation warehouse overseas while I figure out what to do with it. Paying almost double its value in taxes alone just kills its viability as a hobby, and sourcing it overseas is the only way to get hands on hardware without shelling out $2,000+.

There’s a whole cottage industry over there where they harvest semiconductors from junk/e-waste and turn them in to usable products again. I assume that’s where the actual FPGA chip came from.

There are a ton of federal agencies that have the power to make regulations and then enforce them. This power is specifically delegated by Congress. It’s hard to imagine a functioning government without this. For example, Congress recognizes it is not a subject matter expert at radio signals, so it delegates the technical details of regulating the electromagnetic spectrum to the FCC. Same thing for the FDA. Congress isn’t an expert on how clinical trials should be designed so it delegates that to the FDA. A huge one is the DEA, which can both determine how drugs are scheduled and can also enforce it. Congress has the power to overrule the agency when it sees fit.

My go to on Windows is LLVM using the Windows SDK for libc. Before Microsoft had solved the whole msvcrt redistributable mess I used mingw-64 as the libc which worked pretty well actually.

Another vote for Micronaut. I’ve moved a Vert.x project to it recently. I love it. I will say though there are a lot of footguns and the wide variety of choices e.g. for persistence, views, etc make it hard to figure out the “right” way to do things. But the framework just really clicks for me.

Depending on the frequency and source maprad.io may be more useful for identifying signals.

I’m one of those kids who have been programming since they were 10 years old. My biggest tip is to work on personal projects that you are genuinely passionate about or would use yourself. It’s a great way to experiment with new technologies with practically zero risk. For example, I’m currently working on a web app that started out as a SvelteKit SPA and with two backend “micro services”. I just recently finished rearchitecting the project into a monolith and using Hotwire for the front end. I was able to get experience using both of these technologies risk-free.

As a result of being curious and working on things that interest me, there’s practically no area of software development that I haven’t touched. I’ve written Windows device drivers, firmware for an IoT product, hacked on the LLVM source, wrote a (really basic) hypervisor, and made countless web apps. All with no CS degree.

I just want to point out that Windows actually has similar packaging problems. For some reason, Windows didn’t ship with C/C++/.NET runtimes. So practically every app ships with either a copy of the runtime DLLs or an installer to install those runtimes globally. Every Windows installation inevitably gets a million msvcrt dlls across random places, never getting any security updates. I believe this situation is a lot better on recent versions of Windows 10/11.