Pull to refresh

Поведение Curl на macOS отличается от документированного. Apple считает, что это нормально

Level of difficultyEasy
Reading time3 min
Views9K
Original author: Daniel Stenberg

tldr: Apple считает, что все в порядке. Я нет.


28 декабря 2023 года в систему отслеживания ошибок Curl был отправлен отчет об ошибке 12 604. Мы получаем множество таких отчетов изо дня в день, так что сам по себе этот факт вряд ли был чем-то необычным. Мы читаем отчеты, проводим расследование, задаем дополнительные вопросы, чтобы увидеть, что мы можем узнать и на что нужно обратить внимание.


Название проблемы в этом случае было совершенно ясным: поведение флага –cacert несовместимо между macOS и Linux, и оно было зарегистрировано Юэдуном Ву.


Дружелюбный репортер показал, что версия Curl, поставляемая в комплекте с macOS, ведет себя иначе, чем двоичные файлы Curl, собранные полностью из открытых исходников. Даже при запуске одной и той же версии Curl на одном компьютере с MacOS.


Параметр командной строки Curl --cacert позволяет пользователю сказать Curl, что нужен конкретно этот набор доверенных сертификатов центра сертификации. Если TLS-сервер не может предоставить сертификат, который можно проверить с помощью этого набора, передача должна завершиться с возвратом ошибки.


Такие поведение и функциональность в Curl установлены уже много лет назад (опция добавлена в декабре 2000 года) и, конечно же, предназначены они для того, чтобы пользователи знали, что взаимодействуют с известным и доверенным сервером. Довольно фундаментальная часть того, что на самом деле делает TLS.


Когда этот параметр командной строки используется с curl в macOS, версия, поставляемая Apple, видимо, откатывается назад и проверяет хранилище системного центра сертификации на случай, если предоставленный набор сертификатов центра сертификации не пройдет проверку. Вторичная проверка, о которой не просили, не документирована и, откровенно говоря, становится полной неожиданностью. Таким образом, когда пользователь запускает проверку с использованием Curl и обрезанного, выделенного файла сертификата центра сертификации, она не завершится неудачно, если в системном хранилище центра сертификации содержится сертификат, который сервер сможет проверить!


Это проблема безопасности, ведь теперь внезапно проходят проверки сертификата, которые проходить не должны.


Я сообщил об этом как о проблеме безопасности в электронном письме, отправленном в отдел безопасности продуктов Apple 29 декабря 2023 года, 08:30 UTC. Это не серьезная проблема, но это проблема.


Apple говорит, что все в порядке


8 марта 2024 года компания Apple Product Security ответила мудро:


Привет,

Еще раз благодарим вас за то, что сообщили нам об этом и предоставили нам время для расследования.

Версия OpenSSL (LibreSSL) от Apple намеренно использует встроенное системное хранилище доверенных сертификатов в качестве источника доверия по умолчанию. Поскольку сертификат сервера можно успешно проверить с помощью встроенного системного хранилища доверенных сертификатов, мы не считаем, что это необходимо учитывать на наших платформах.

С наилучшими пожеланиями,
Сохраняйте спокойствие
Команда безопасности Apple

Дело закрыто.


Я не согласен


Очевидно, я думаю иначе. Эта недокументированная функция делает проверку сертификата центра сертификации с помощью Curl в macOS абсолютно ненадежной и несовместимой с документацией. Обманывает пользователей.


Будьте в курсе.


Поскольку в поставляемой нами версии Curl это не является уязвимостью безопасности, мы не выпустили CVE или что-то еще для решения этой проблемы. Проблема, строго говоря, даже не в коде Curl. Curl [в MacOS] идет с версией LibreSSL, которую поставляет Apple, и [с этой библиотекой Apple] собирает Curl для использования на своих платформах.

Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
Total votes 59: ↑56 and ↓3+53
Comments43

Articles