Home > Privacy, Security > The Apple curl security incident 12604

The Apple curl security incident 12604

Privacy, Security 4 Comments

When this command line option is used with curl on macOS, the version shipped by Apple, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification. A secondary check that was not asked for, is not documented and plain frankly comes completely by surprise. Therefore, when a user runs the check with a trimmed and dedicated CA cert file, it will not fail if the system CA store contains a cert that can verify the server!

This is a security problem because now suddenly certificate checks pass that should not pass.

↫ Daniel Stenberg

Absolutely wild that Apple does not consider this a security issue.

About The Author

Thom Holwerda

Follow me on Mastodon @[email protected]

4 Comments

  1. 2024-03-11 2:43 am
    cpcf

    I understand the authors concerns, I do not understand at all Apple response. Of course I have to assume what we read in the article as Apple’s response is valid, but I suppose based on the discussed concerns it might not be a valid response.

    So do I now have to assume Apple is an insecure platform and Apple as an untrusted source?

  2. 2024-03-11 3:49 am
    Alfman verbose=1

    cpcf,

    So do I now have to assume Apple is an insecure platform and Apple as an untrusted source?

    I wouldn’t necessarily attribute apple’s libressl changes to malicious intent without clear evidence of that. Assuming the info is correct, the bug report does make it seem created a bug that ought to be fixed even if apple intended to change the certificate store.
    https://github.com/curl/curl/issues/12604

    This is concerning because 1) it’s a legit bug, but also 2) it could be used nefariously by apple and by extension government agencies that order apple.to comply with wiretapping requests. At the very least the onus is on apple to document the changes. It might be better to provide a run time warning. The failure to disclose this violates user trust IMHO. The binaries allegedly don’t match the source, if true, this is bad since it means the code can’t be audited.

    I could chalk all of this up to an innocent mistake or oversight. But with their response they can no longer claim ignorance, any failure to document their changes now become intentional.

    • 2024-03-11 5:24 pm
      cpcf

      @Alfman

      This is concerning because 1) it’s a legit bug, but also 2) it could be used nefariously by apple and by extension government agencies that order apple.to comply with wiretapping requests.

      Then if true this a clear difference between what Apple does versus what Apple says, that’s a loss of confidence for me, and for some it will be a loss of trust. Your final sentence is telling.

  3. 2024-03-11 3:59 am
    Alfman verbose=1

    I’m not positive, but this could be related to these apple changes to openssl (before it was forked to libressl).

    https://hynek.me/articles/apple-openssl-verification-surprises/

    Apple ships a patched version of OpenSSL with macOS. If no precautions are taken, their changes rob you of the power to choose your trusted certificate authorities (CAs) and break the semantics of a callback that can be used for custom checks and verifications in client software.

    If OpenSSL’s certificate verification fails while connecting to a server, Apple’s code will intercept that error and attempt to verify the certificate chain itself with system trust settings from the keyring, potentially throwing away your verification results. Therefore:

    You can’t limit your trust to certain CAs using SSL_CTX_load_verify_locations.

    This apparently isn’t news but doesn’t appear to be widely known.

    Contrary to documentation, returning 0 from SSL_CTX_set_verify’s callback does not make the TLS handshake fail. That makes the callback unsuitable for extra verification purposes (such as hostname verification).

    MITRE has assigned CVE-2014-2234 for this issue.

    https://nvd.nist.gov/vuln/detail/CVE-2014-2234