{"id":42865,"date":"2024-04-16T23:45:38","date_gmt":"2024-04-17T03:45:38","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=42865"},"modified":"2024-04-16T23:45:38","modified_gmt":"2024-04-17T03:45:38","slug":"the-apple-curl-security-incident","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/04\/16\/the-apple-curl-security-incident\/","title":{"rendered":"The Apple curl Security Incident"},"content":{"rendered":"

Daniel Stenberg<\/a> (Hacker News<\/a>, Slashdot<\/a>):<\/p>\n

\n

The friendly reporter showed how the curl version bundled with macOS behaves differently than curl binaries built entirely from open source. Even when running the same curl version on the same macOS machine.<\/p>\n

The curl command line option --cacert<\/a><\/code> provides a way for the user to say to curl that this is the exact set of CA certificates to trust<\/strong> when doing the following transfer. If the TLS server cannot provide a certificate that can be verified with that set of certificates, it should fail and return error.<\/p>\n

[…]<\/p>\n

When this command line option is used with curl on macOS, the version shipped by Apple<\/em>, it seems to fall back and checks the system CA store in case the provided set of CA certs fail the verification<\/strong>. A secondary check<\/em> that was not asked for, is not documented and plain frankly comes completely by surprise.<\/p>\n

[…]<\/p>\n

This is a security problem because now suddenly certificate checks pass that should not pass.<\/strong><\/p>\n<\/blockquote>\n

Yet another case where Apple’s security team doesn’t agree about what constitutes a security issue.<\/p>\n\n

Previously:<\/p>\n