LINUX.ORG.RU

Множественные уязвимости в Matrix’s Rust библиотеке Vodozemac

 ,


0

2
Исследователь Soatok нашёл серьёзные криптографические проблемы в Rust-библиотеке Matrix — vodozemac (коммит a4807ce…).
Основные уязвимости:
    Высокая: X25519 Diffie–Hellman может вернуть all‑zero (элемент тождества). В коде Vodozemac не проверяют was_contributory(), поэтому совместный секрет может быть нулём — это полностью ломает конфиденциальность.
    Возможность даунгрейда V2→V1 (downgrade).
Другие проблемы: слабая проверка ECIES (CheckCode ~100 значений), исчезновение ключей сообщений после MAX_MESSAGE_BYTES, детерминированные IV в формате «pickle», обход проверки MAC/подписи при #[cfg(fuzzing)], строгая проверка Ed25519 по умолчанию отключена.
Таймлайн раскрытия: найдено 2026-02-11, автор уведомил Matrix, дал неделю на реакцию; публичное раскрытие — 2026-02-17.
Влияние: потенциальное раскрытие переписок/ключей при реальных условиях (особенно с ошибками RNG или в групповых чатах). Matrix поспешно утверждала «никакого практического воздействия», но автор предоставил PoC и патч.
Рекомендация автора: не использовать Matrix (по крайней мере — пока эти баги не исправлены); предложен простой патч — проверять was_contributory() для всех DH-результатов.

src: https://soatok.blog/2026/02/17/cryptographic-issues-in-matrixs-rust-library-vodozemac/


vodozemac — это реализация криптографических алгоритмов Olm и Мегольма на чистом Rust, предлагающая высокоуровневый API для простого создания защищенных каналов связи с использованием этих алгоритмов.

Разработанный как современная альтернатива криптографической библиотеке libolm, используемой для сквозного шифрования в Matrix, vodozemac предоставляет не только алгоритмы Ольма и Мегольма, но и дополнительные криптографические функции, полезные для разработки клиентов Matrix, такие как SAS и интегрированная схема шифрования, описанная в MSC4108.

★★★

Последнее исправление: hakavlad (всего исправлений: 2)

Сказал бы хоть, что это ненужно должно делать как библиотека вообще? Это для вычисления матриц или для протокола? Или так автора зовут?

Bfgeshka ★★★★★
()
Последнее исправление: Bfgeshka (всего исправлений: 2)
Ответ на: комментарий от dataman

Это чисто для протокола на чистом Rust.

Не совсем так, эта уязвимость не относится к самому протоколу Matrix, это реализация сквозного шифрования, те уязвимость в современных клиентах которые используют эту библиотеку: Element, Cinny итд. Сам сервер matrix-synapse не реализует Olm/Megolm протокол.

Хорошо что нашли, это классические болезни роста возбуждающей новой технологии (c)

Obezyan
()
Ответ на: комментарий от Obezyan

Не совсем так, эта уязвимость не относится к самому протоколу Matrix

Но мой комментарий тоже не относился ни к уязвимости, ни к протоколу Matrix.
Перекаламбурю – чисто для галочки на голом Rust.
Вроде стало хуже.

dataman ★★★★★
()
Ответ на: комментарий от dataman

Я потом понял, но менять уже не стал, тут просто наложилось, в это же время было обсуждение этой же новости у себя в пространстве, большинство используют Cinny, где эта уязвимость присутствует.

Obezyan
()

https://matrix.org/blog/2026/02/analysis-of-reported-issues-in-vodozemac/ Матрица ответила

Сегодня была опубликована статья в блоге, в которой утверждается о наличии ряда уязвимостей в криптографической библиотеке vodozemac компании Matrix. Статья появилась после частного обращения по адресу security@matrix.org. Хотя мы предпочитаем скоординированное раскрытие информации, автор решил опубликовать её до дальнейшего технического обсуждения, включая уточнение заявленной серьезности.

Мы серьезно относимся к проблемам криптографии и приветствуем проверку наших криптографических протоколов и реализаций. Однако мы не согласны с несколькими выводами в статье относительно возможности эксплуатации и влияния на развертывание Matrix. Ниже мы анализируем утверждения с точки зрения реальных возможностей злоумышленников и инвариантов протокола.

🔗Краткое изложение

Мы подтверждаем, что код Olm 3DH в vodozemac в настоящее время не отклоняет все нулевые выходные данные X25519. Мы не согласны с утверждением в статье о том, что это приводит к какой-либо потере конфиденциальности в Matrix, не говоря уже о полной потере.

Olm v2 не стандартизирован и не используется в современной версии Matrix. Заявления, сформулированные как ухудшение качества, касаются экспериментальной будущей конфигурации, а не текущей спецификации. Olm v1 использует усеченные 64-битные теги аутентификации сообщений, пережиток более раннего времени, когда криптография Matrix в значительной степени следовала за Signal. Мы признаем это как компромисс и то, что использование более длинных тегов аутентификации обеспечило бы больший запас безопасности, как было публично задокументировано в предыдущем аудите vodozemac. Тем не менее, усеченные 64-битные теги аутентификации сообщений остаются распространенным компромиссом в развернутых системах обмена сообщениями, и мы не считаем это практически эксплуатируемой уязвимостью. Например, Signal также использует 64-битные теги аутентификации сообщений. «Разные проблемы» представляют собой смесь механизмов пользовательского интерфейса, которые ошибочно интерпретируются как криптографические проверки (например, CheckCode), и наблюдений без продемонстрированного влияния на безопасность.

В заключение, мы считаем, что в публикации не описаны какие-либо практически применимые уязвимости.

Главное утверждение статьи в блоге заключается в том, что злоумышленник может читать переписку пользователей Matrix. Для этого требуется, чтобы два добросовестных клиента получили один и тот же предсказуемый сессионный ключ. В публикации не показан способ достижения этой цели в рамках модели аутентифицированного распределения ключей Matrix.

hakavlad ★★★
() автор топика