Итак, сегодня закончилось эмбарго на проблемы безопасности OpenSSL, и патчи были сняты. Основываясь на содержании проблемы безопасности, сложности ее использования на практике и том факте, что большинство дистрибутивов Linux принимают основные меры предосторожности, чтобы предотвратить ее использование в качестве жизнеспособного вектора атаки: эта проблема не затрагивает почти всех пользователей OpenSSL в реальный мир.
Дополнительные сведения о CVE-2022-3786 и CVE-2022-3602 см. в публикации команды OpenSSL под названием CVE-2022-3786 и CVE-2022-3602: переполнение буфера адресов электронной почты X.509 .
我很伤心.example кодируется в xn--hpq721bdf90g.example ). Это работает и в адресах электронной почты. Проблема заключалась в том, что если вы указали неправильный адрес электронной почты в сертификате TLS, это могло привести к удаленному выполнению кода из-за переполнения буфера на некоторых платформах. К счастью, это определение «некоторых платформ» не включает Ubuntu на процессорах amd64.Основная причина, по которой это не имеет большого значения для большинства людей, заключается в том, что большинство современных компиляторов включают защиту от переполнения стека , которая предотвращает выполнение произвольного кода из-за переполнения буфера. На практике средство защиты стека поймет, что что-то не так, и заставит программу взорваться. Это сводит атаку от атаки с выполнением произвольного кода к простой атаке типа «отказ в обслуживании», что на практике намного скучнее.
Для получения дополнительной информации об этом см. эту статью , в которой объясняется, как работает эта атака, как вы можете воспроизвести ее дома с помощью уязвимой версии OpenSSL и, наконец, почему это не является практической проблемой. Если бы какая-либо организация захотела использовать это, это почти наверняка привело бы к тому, что сертификат был бы замечен в журналах прозрачности сертификатов, а затем потенциально была бы поставлена под вопрос способность всего центра сертификации выдавать сертификаты. Это, вероятно, приведет к тому, что центру сертификации не будет разрешено выдавать сертификаты до тех пор, пока ситуации, которые позволили этому органу выдавать сертификаты, не будут исправлены и не оценены независимо.
Я предполагаю, что это наиболее жизнеспособно в средах с пользовательскими корневыми сертификатами TLS, но на практике они достаточно редки, чтобы не сделать этот механизм полезной атаки. В уравнении есть гораздо более низкие плоды. Возможно, люди действительно так не доверяют центрам сертификации.
Я чувствую себя вынужденным извиниться за то, как я отношусь к проблеме OpenSSL в своем блоге. Я поверил команде OpenSSL на слово и чувствую, что поступил правильно, даже если на практике это обернулось гигантским пустяком. Если мое освещение проблем навредило вам или заставило волноваться сверх нормы, мне очень жаль. Я исходил из информации, которую мне дали, и я слышал из нескольких источников, которым я доверяю, что это было то, о чем действительно нужно заботиться. Я воспользуюсь этим опытом, чтобы определить, как я буду сообщать об этих вещах в будущем.
Почему я расстроен
Есть две большие вещи, которые расстраивают меня в этой паре уязвимостей.
Во-первых, очевидно, что команда OpenSSL не знает, какие флаги компилятора используются для компиляции OpenSSL на популярных платформах . Типа, я понимаю, на каком-то уровне это имеет смысл. OpenSSL используется в миллиардах различных сред, и все они представляют собой уникальные снежинки.
Однако на каком-то уровне это кажется немного непростительным. Ubuntu и CentOS являются одними из крупнейших пользователей OpenSSL. Люди, работающие в Canonical и Red Hat, вносят свой вклад в OpenSSL. Я чувствую, что они должны иметь некоторое представление о том, что делают наиболее распространенные среды. Конечно, они не смогут помешать какому-нибудь встроенному устройству в Палау передать ACE указатель с адреса электронной почты в сертификате, но я очень надеюсь, что Ubuntu и CentOS — это цели, о которых они действительно заботятся и проверяют их. .
Второе, что меня беспокоит, это то, что, кажется, сегодня, 1 ноября 2022 года, ошибка была понижена с «КРИТИЧЕСКОЙ» до «ВЫСОКОЙ» . Чтобы дать команде OpenSSL максимально возможную пользу от сомнений, это несколько разумно. По мере того, как они продолжали копаться в вещах и исследовать, насколько уязвимы люди, они поняли, что их первоначальная оценка проблемы была неверной. Это означает, что люди, которые говорили, что это очень плохо, точно сообщали о том, что они понимали в то время. На каком-то уровне именно так работает научный процесс: у вас есть гипотеза, вы ее проверяете, сообщаете о результатах. Это просто расстраивает, что это заняло так много времени, чтобы понизить его. Я был готов к критической уязвимости, и я уверен, что другие люди тоже.
Я беспокоюсь, что это будет рассматриваться как причина не воспринимать «КРИТИЧЕСКИЕ» раскрытия информации всерьез, как мы должны . «КРИТИЧЕСКАЯ» ошибка ДОЛЖНА рассматриваться как критическая. С точки зрения общественного здравоохранения, людям сказали, что что-то действительно плохое вот-вот выйдет в течение недели, а затем из-под них вытащили ковер, и теперь это «нет, мы были неправы, вы, вероятно, в порядке».
Опять же, такое случается, и для них совершенно рационально передумать. Я просто беспокоюсь, что этот уровень усталости от тревог только что научил людей не воспринимать вещи всерьез, потому что на этот раз все было не так уж плохо.
Оказывается, рекомендации OpenSSL были более разрушительными, чем сама уязвимость.
— дкп (@tweetdkp) 1 ноября 2022 г.
В NixOS включена защита стека, поэтому она никогда не была уязвима для этой проблемы. Моя статья , в которой говорилось, что нужно перекомпилировать nginx с OpenSSL 1.x, была не нужна. Тем не менее, это был классный способ продемонстрировать overrides в nixpkgs, поэтому я все равно буду считать это победой.
Зона горячего дубля™️
Возможно, нам нужно перестать писать новый критический с точки зрения безопасности код на C. Вот полное содержимое одного из патчей, исправляющих CVE-2011-3602 :
--- a/crypto/punycode.c +++ b/crypto/punycode.c @@ -181,7 +181,7 @@ int ossl_punycode_decode(const char *pEncoded, const size_t enc_len, n = n + i / (written_out + 1); i %= (written_out + 1); - if (written_out > max_out) + if (written_out >= max_out) return 0; memmove(pDecoded + i + 1, pDecoded + i,
Для тех из вас, кто плохо знает C, вот моя попытка объяснить, что происходит. Это функция, которая декодирует текст punycode в соответствующий текст Unicode. Одна из вещей, которые он делает, — это копирование данных из входного буфера, их декодирование и помещение результатов в выходной буфер. Этот оператор if здесь, чтобы предотвратить переполнение буфера и то, что будет дальше. Если это «что будет дальше» находится в стеке, то значение потенциально может переполниться, и тогда это значение станет адресом возврата для вызова этой функции.
Основной причиной этого является поочередная запись за пределы буфера вывода. Это стало возможным, потому что в C нет способов статически доказать, что вы не можете перезаписывать буферы, подобные этому, так что компилятор откажется компилировать код.
Возможно, нам как отрасли нужно более серьезно относиться к формальным проверкам, безопасности памяти и связанным с ними вещам. Возможно, добавление Rust в ядро Linux — это хорошо. Rust также был недавно добавлен в ядро Windows, и никто не заметил его присутствия.
M11 01 2022 21:36 (UTC)
