CA released certificates that allow anyone to spoof any site on the Internet

TidBITS Talk
1

The other security debacle this week was the revelation that the private keys to eight eMudhra intermediate Certificate Authority (CA) certificates have been compromised. This is on the scale of the 2014 Heartbleed vulnerability in OpenSSL, but without a catchy name.

eMudhra Intermediate CA Compromise

Ars Technica: The Internet goes on high alert after discovery of 8 compromised TLS certs

What happened is that eMudhra released 8 intermediate certificates that have trivial private keys. How trivial? The keys are: 4, 56, 66, 115, 155, 156, 230, and 237.

Knowing the private key, anyone can forge a certificate for any site, and sign it with eMudhra’s inane private key. If the chain-of-trust trusts the eMudhra certificate, then your forged certificate is trusted. If you can intercept traffic then you can transparently decrypt HTTPS connections that are for the site you forged.

The certificates have been added to revocation lists, so if you’re using a major browser (Chrome, Firefox, etc.) then you’re OK. The linked eMudhra Intermediate CA Compromise site will test this for you. Even Safari on macOS Ventura is OK, because, I think, applications using macOS TLS services have the revocation checked by macOS.

The problem is the all the places that have their own trusted certificate store, that are not easily updated. One example is curl on macOS – it depends on /etc/ssl/cert.pem, which likely won’t be updated until the next macOS point release. There’s also IoT devices (the o stands for Security), unmaintained CLI tools, containers, servers accidentally sealed up by drywall and forgotten. This is why it will take years to cleanup, hence the comparison to Heartbleed.

Right now, you can visit the linked site with your favorite web browser. Look at the Does your client still trust the compromised intermediates? section. If the result is all green “:white_check_mark: Did not connect”, you’re good for that browser. The site also give instructions for testing command line utilities such as curl.

13 Likes
2

Update:

5 Likes
3

FYI: The macOS 26.7.2 update does NOT remove the affected eMudhra certificates from /etc/ssl/cert.pem for tools that use that (e.g., curl, git, python3, ruby, perl, and openssl). In fact, if you followed the instructions in the Apple Support article to manually remove the affected eMudhra certificates from /etc/ssl/cert.pem for tools that use that (e.g., curl, git, python3, ruby, perl, and openssl), installing macOS 26.7.2 will overwrite the cert.pem and you will have to re-remove the eMudhra certificates using Apple’s instructions.

@Halfsmoke @mschmitt

2 Likes
4

The Apple support article does indicate that until Apple releases an update to remove the certs from /etc/ssl/cert.pem, the certs may be re-introduced and you will need to re-run the manual removal procedures.

Since Apple hasn’t provided info on which macOS release will remove those bad certs (and they’re notoriously bad about telling us about what they’ve changed in a macOS release) use the openssl command noted in the article to check if the bad certs have been re-introduced by a macOS update.

5

Quotes from the Apple Support article.

If you don’t use Terminal as part of your workflow, you don’t need to do anything. Your Apple devices now automatically block these certificates in Safari, Mail, and apps that use Apple’s networking and security frameworks.

Does Firefox use Apple’s networking and security frameworks? What mainstream networking apps do not?

Updates to certificate configuration data are sent to devices automatically and as needed, so you don’t need to install a software update to get this change.

Is this done because Install Security Responses and system files is enabled?

6

If those applications don’t come from Apple, then that’s a question for the application’s developer.

7

An easy way to tell is the test page, which has a table of your current browser’s results. In my case it shows that Chrome uses the vulnerable trust model, whereas Firefox does not.

1 Like
8

It’s reportedly fixed in macOS 27.2.1, macOS 26.7.3, and macOS 15.8.3, released today.

2 Likes