Apple до сих пор не закрыла дыру: git в macOS доверяет скомпрометированным сертификатам eMudhra
Ten days later, Git on macOS still trusts the compromised eMudhra certificates
Об инциденте с eMudhra Apple узнала 17 октября, но спустя десять дней git, curl и python3 в macOS по-прежнему доверяют скомпрометированным сертификатам. Обновление macOS 27.2 не только не исправило проблему, но и отменило ручной обходной путь, снова оставив разработчиков уязвимыми. При этом десятки других проектов, многие из которых ведут волонтёры, выпустили исправления ещё несколько дней назад. Safari уже защищён, а вот инструменты разработчика — нет.
Любой может перехватить любое HTTPS-соединение, которое устанавливают эти инструменты.
- chrisweekly
Верно, так что дело не только в git, а в куче системных утилит; macOS доверяет плохим сертификатам, и эти утилиты, которые доверяют ОС, затронуты. Я использую homebrew для своего git и curl, но ещё не проверял, имеет ли это здесь значение.
Несколько возмутительно, что рекомендация Apple — вручную редактировать цепочку сертификатов, и ожидать, что последующие обновления ОС могут отменить вашу меру защиты, вновь внося уязвимость (как уже случалось по крайней мере один раз).
- jrochkind1
То, что MacOS не удалила из системного /etc/ssl, кажется большим делом, затрагивающим не только поставляемый с ОС git. Я полагаю, /etc/certs не используется большей частью графического ПО Mac? Хаотичное состояние управления сертификатами на уровне ОС, в том числе в Linux, довольно удручает.
Если Apple всё ещё пытается позиционировать себя как компанию, ориентированную на безопасность, можно было бы подумать, что удаление отозванных корневых сертификатов из /etc в системном обновлении было бы довольно простой задачей?
- truelson
Вот что Apple (сами) рекомендуют для исправления: https://support.apple.com/en-us/149555
Практически каждому разработчику на Mac, вероятно, стоит применить их патч.
- qaz_plm
Заявление Apple: https://support.apple.com/en-us/149555
- kryptiskt
Я не саркастичен, когда говорю, что Apple следует скопировать Windows Update; понятия не имею, как они дошли до такого, не имея способа добавлять небольшие патчи вне монолитных обновлений ОС.
- faxmeyourcode
Хотя нет доказательств, что кто-либо знал об этих слабых ключах в течение полутора лет, когда им доверяли практически все, и нет свидетельств атак типа MITM в реальных условиях из-за этого, можно представить, какую выгоду получило бы некое агентство с тремя буквами, если бы даже на 10 дней появилась возможность собирать учётные данные важных людей на высоких постах.
У меня нет доказательств, но я убеждён, что этот провал с генерацией ключей wrap/unwrap был намеренным, а слабые ключи были обнаружены и держались в секрете агентствами или правительствами и использовались для эксплуатации их противников.
Вам не нужно проводить традиционную MITM-атаку, _если вы владеете аэропортом_ или _владеете бесплатным публичным Wi-Fi_. Трафик можно собирать в открытом виде, и нам приходится смириться с _отдалённой возможностью_, что это продолжалось более полутора лет. Если не так долго, то уж точно последние 10 дней.
- commandlinefan
Похоже, мы все просто... отказались от отзыва сертификатов? CRL и OCSP были разработаны именно для такого, но оба, похоже, были заброшены как неработоспособные без какой-либо замены.
- gringofyx
Плоский файл cert.pem (или подобный) не может сказать «не доверять этому промежуточному сертификату».
В macOS уже есть нужный верификатор (путь Security.framework/trustd, который защищал Safari). Было бы хорошо, если бы MacOS направляла CLI через него.
- kd913
Они ведь только что выпустили MacOS 27.2 несколько дней назад? Как и почему они не выпустили патч хотя бы тогда?
- mFixman
Вопрос к тем, кто разбирается: почему у нас сотни корневых удостоверяющих центров, когда уязвимость в одном из них может сломать шифрование?
Разве не было бы разумнее иметь штук 5, которые можно было бы тщательно контролировать, чтобы что-то вроде сертификатов eMudhra, вероятно, обнаружили до их развёртывания?