Логотип Зефирнет

OpenSSL выпускает исправление для предыдущего исправления.

Дата:

Если вы являетесь пользователем OpenSSL, вы, вероятно, знаете о самых последних громкое исправление релиз, который вышел еще в марте 2022 года.

Это исправление принесло нам OpenSSS 3.0.2 и 1.1.1n, обновления для двух текущих полностью поддерживаемых вариантов продукта.

(Существует устаревшая версия 1.0.2, но обновления этой версии доступны только для клиентов, платящих за премиум-поддержку, и, учитывая изменения и улучшения в продукте со времен 1.0.2, мы настоятельно рекомендуем вам перейти на более раннюю версию. основная версия даже — возможно, особенно — если вы планируете продолжать платить за поддержку.)

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

Исправленная тогда ошибка была связана со специальным алгоритмом вычисления того, что известно как модульные квадратные корни, которые сложнее вычислить, чем обычные квадратные корни.

К сожалению, код для выполнения этого вычисления с использованием алгоритма, впервые открытого в 1890-х годах, был неуклюже закодирован, мучительно написан, плохо прокомментирован и труден для понимания.

Однако, учитывая, что он не находился в очевидной «внешней» части OpenSSL, и учитывая, что переписать его было бы сложной задачей, мы предполагаем, что он был тщательно проверен на правильность ответов при представлении правильно сформированные числа, но не проверены на их надежность при столкновении с маловероятным входом.

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

Когда вы работаете только с целыми числами и запрещаете дроби любого вида, вы обнаружите, что многие числа не имеют модульных квадратных корней, точно так же, как вы обнаружите, что многие целые числа не имеют обычных квадратных корней. Таким образом, 7 × 7 = 49, поэтому 49 имеет квадратный корень, который является целым числом, а именно 7. Но нет целого числа, которое можно было бы умножить само на себя, чтобы получить 50 или 51, потому что следующий «совершенный квадрат» — это 8 × 8. = 64. Вы можете пытаться сколько угодно долго, но вы никогда не найдете целочисленного ответа на √51.

Никогда на самом деле неправильный, просто неполный

Другими словами, хотя код OpenSSL BigNumber (многие алгоритмы шифрования основаны на работе с числами, состоящими из сотен или даже тысяч цифр) никогда не давал неправильно ответ, иногда он не понимал, что ответа не найти, и застревал в бесконечном цикле.

Этот бесконечный цикл, которым можно злоупотреблять, чтобы спровоцировать то, что известно как Отказ в обслуживании атака (DoS) может быть вызвана, если злонамеренный веб-сайт отправляет заминированный цифровой сертификат.

Это означало, по иронии судьбы, что программное обеспечение, которое скрупулезно относилось к проверке цифровых сертификатов, могло быть поставлено на колени из-за этой ошибки, получившей название CVE-2022-0778, в то время как программы, которые вообще не беспокоились о проверке сертификата, не пострадали от этого.

Учитывая важные «обучаемые моменты», выявленные этим багом, мы подробно освещали его не только на Naked Security, где объясняли как написать лучший стиль кода, но и на Sophos News, где SophosLabs показала кровавые подробности того, как заминированный сертификат может вызвать уязвимость, и как отладить код, чтобы понять ошибку.

Тем временем еще две дыры в безопасности

Следующее обновление OpenSSL было 3.0.3или 1.1.1o для пользователей предыдущего выпуска, в котором исправлена ​​ошибка, которая не считалась серьезным недостатком (по крайней мере, мы не освещали ее в Naked Security), главным образом потому, что ошибка не была в самом коде библиотеки шифрования OpenSSL.

Вместо того, чтобы затрагивать все программное обеспечение, которое полагалось на OpenSSL в качестве поставщика криптографических данных, CVE-2022-1292 только что затронул служебный скрипт, написанный на Perl, который поставлялся вместе с набором инструментов OpenSSL.

Этот сценарий, известный как c_rehash (Короче для перефразирование каталога сертификатов) — это малоизвестный инструмент, который берет каталог файлов криптографических сертификатов, таких как те, которые поддерживаются Mozilla в качестве доверенных центров сертификации (ЦС), и создает список хэшей файлов, который может помочь программному обеспечению найти определенные сертификаты быстрее, чем поиск в алфавитный список имен.

Например, каталог сертификатов ЦС Mozilla выглядит так…

$ ls -l /usr/share/ca-certificates/mozilla -rw-r--r-- 1 утка утка 2772 2022 06:23 ACCVRAIZ05.crt -rw-r--r-- 32 утка утка 1 1 1972:2022 AC_RAIZ_FNMT-RCM.crt -rw-r--r-- 06 утка утка 23 05 32:1 AC_RAIZ_FNMT-RCM_SERVIDORES_SEGUROS.crt [. . .] -rw-r--r-- 904 утка утка 2022 06 23:05 emSign_Root_CA_-_G32.crt -rw-r--r-- 1 утка утка 1302 2022-06-23 05:32 vTrus_ECC_Root_CA .crt -rw-r--r-- 1 утка утка 1 774-2022-06 23:05 vTrus_Root_CA.crt

…в то время как OpenSSL c_rehash script генерирует список символических ссылок, которые позволяют находить отдельные сертификаты с помощью хэшей на основе имени издателя в самом сертификате, а не по имени его файла:

LRWXRWXRWX 1 DUCK DUCK 23 2022-06-24 13:41 002C0B4F.0-> GLOBALSIGN_ROOT_R46.CRT LRWXRWXRWX 1 DUCK DUCK 45 2022-06-24 13:41 02265526.0-> Intrust_ROT_CERTICIATICATITITIATE_AOTHORTY _-2-> urrust_ruot_certification_authority _-ru -1 36:2022 06a24 -> Staat_der_Nederlanden_EV_Root_CA.crt [. . .] lrwxrwxrwx 13 утка утка 41 03179-64.0-1 19:2022 fe06a24cd13 -> SZAFIR_ROOT_CA41.crt lrwxrwxrwx 8 утка утка 2 8.0-2-1 23:2022 feffd06 -> GlobalSign_Root_E24.crt lrwxr13wxrw41 утка -413.0-46 1:49 ff2022af06f.24 -> TUBITAK_Kamu_SM_SSL_Kok_Sertifikasi_-_Surum_13.crt

Некоторое программное обеспечение использует эти «хеш-ссылки», чтобы действовать как своего рода базовая система базы данных для индексации и поиска определенных сертификатов.

Кроме того, некоторые дистрибутивы операционных систем автоматически вызывают c_rehash скрипт в фоновом режиме, чтобы поддерживать эти специальные ссылки в актуальном состоянии.

Метасимволы оболочки считаются вредными

К сожалению, сценарий опирался на Perl system() функцию (или эквивалентную команду) для вычисления хэшей файлов, а system() система автоматически запускает командную оболочку, такую ​​как Bash, для запуска любых необходимых подпрограмм.

И, как вы, вероятно, знаете, командные оболочки не всегда воспринимают свои аргументы командной строки буквально, поэтому, если вы поместите в эти аргументы специальные символы, оболочка будет обрабатывать их потенциально опасными способами.

Например, команда echo runthis буквально печатает текст runthis, но команда echo $(runthis) не распечатывает символы напрямую $(runthis).

Вместо этого так называемый метакоманда $(runthis) означает подстановка команд, поэтому он говорит: «Выполните команду runthis и заменить $(...) часть с выводом этой команды, когда она будет завершена»:

   # аргумент трактуется буквально, метасимволы не найдены $ echo runthis runthis # пытается выполнить 'runthis', но такой команды не существует $ echo $(runthis) -bash: runthis: команда не найдена # запускает две команды, собирает вывод обеих $ echo $(whoami; uname -s -r) утка Linux 5.18.6

Если риск, связанный с $(...) звучит знакомо, потому что это была уязвимость метакоманды, которая использовалась в недавнем Ошибка «Фоллина» в Windows. Чтобы узнать больше и увидеть эту ошибку в действии, вы можете посмотреть запись нашего вебинара. Просто нажмите на изображение ниже. [Требуется регистрация, доступ открывается сразу же после этого.]

Что исправили?

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

Ниже вы можете увидеть код, который был изменен с 1.1.1n в 1.1.1o:

Команда Perl вида `...` (команда между обратными кавычками, например `runthis`, это просто старомодный способ записи $(runthis) подстановка команд) была заменена специальной внутренней функцией, называемой compute_hash который уделяет больше внимания странным метасимволам в построенной командной строке.

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

Поэтому на этой неделе видел выпуск OpenSSL 3.0.4 и 1.1.1p, чтобы исправить еще одну рискованную системную команду в c_rehash утилита:

На этот раз это был призыв к cp (копировать файл) через командную оболочку system() функция, которая была заменена более безопасной, специальной внутренней функцией, называемой copy_file.

Это исправление имеет официальный идентификатор CVE-2022-2068.

Как предупреждает журнал изменений OpenSSL:

[ c_rehash] распространяется некоторыми операционными системами таким образом, что он выполняется автоматически. В таких операционных системах злоумышленник может выполнять произвольные команды с привилегиями скрипта.

Что делать?

  • Обновите OpenSSL, как только сможете. Если вы полагаетесь на свой дистрибутив Linux для управления централизованно установленной копией, обратитесь за подробностями к производителю дистрибутива. Если вы полагаетесь на свою собственную сборку OpenSSL вместо общесистемной (или наряду с ней), не забудьте также обновить эту копию. Ты ищешь 3.0.4 or 1.1.1p, Бег openssl version чтобы увидеть, какая версия у вас есть.
  • Рассмотрите возможность выхода на пенсию c_rehash полезность, если вы ее используете. Универсальная утилита openssl, который в первую очередь обычно используется для создания и подписания сертификатов, теперь включает встроенную подкоманду с именем rehash делать ту же работу. Пытаться openssl rehash -help для дополнительной информации.
  • Дезинфицируйте свои входы и выходы. Никогда не предполагайте, что полученные вами входные данные можно безопасно использовать как есть, и будьте осторожны с данными, которые вы передаете в качестве выходных данных для других частей вашего кода.
  • Будьте бдительны в отношении множественных ошибок при проверке кода на наличие определенных типов ошибок. Программист, который был небрежен с system() Команда в одном месте кода могла допустить аналогичные ошибки в другом месте.

Программисты часто создают (или воспроизводят) одну и ту же ошибку много раз, обычно по совершенно невинным и понятным причинам.

Либо они не знали об этом классе ошибок во время работы над кодом, либо они воспользовались «временным сокращением», чтобы ускорить работу над прототипом, но никогда не возвращались и не убирали позже, либо они скопировали и вставили кого-то чужой ошибочный код и сделали его своим…


Spot_img

Последняя разведка

Spot_img