После аудита OpenVPN в нём нашли четыре опасные уязвимости

    Специалист по безопасности Гвидо Вранкен (Guido Vranken) своим фаззером нашёл четыре серьёзные уязвимости в безопасности OpenVPN. Что интересно, это произошло после недавно проведённых двух полных аудитов безопасности исходного кода этой программы. Это наталкивает на мысль, что аудит исходников не даёт абсолютной гарантии отсутствия багов.

    Сам Гвидо Вранкен считает, что в некоторых случаях человеческий аудит — вообще не лучший вариант. Он говорит, что спонсорам аудита OpenVPN (деньги собирали через краудфандинг) не следовало оплачивать ручной аудит, а надо было нанять экспертов, которые будут заинтересованы в нахождении уязвимостей любыми средствами (через тот же фаззинг). Такая стратегия принесла бы наибольшие дивиденды. По крайней мере, сейчас мы видим, что фаззинг оказался эффективнее, чем анализ вручную.

    OpenVPN — свободная реализация технологии виртуальной частной сети (VPN) с открытым исходным кодом для создания зашифрованных каналов между ПК. Создана Джеймсом Йонаном (James Yonan) и распространяется под лицензией GNU GPL.

    Уже выпущены патчи для OpenVPN. Следуется обновиться до версий 2.4.3 и 2.3.17 как можно скорее, чтобы чувствовать себя в безопасности. Всё-таки дыры, найденные Гвидо, действительно очень серьёзные.

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

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

    Уязвимости


    CVE-2017-7521


    В функции extract_x509_extension() в файле ssl_verify_openssl.c обнаружено сразу несколько ошибок, в том числе некорректная процедура освобождения памяти и некорректное использование структуры GENERAL_NAMES.

    GENERAL_NAMES *extensions;
    int nid = OBJ_txt2nid(fieldname);
     
    extensions = (GENERAL_NAMES *)X509_get_ext_d2i(cert, nid, NULL, NULL);

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

    Соответственно, эта уязвимость классифицируется как удалённый сбой сервера / утечки памяти / двойное освобождение памяти (double-free, один и тот же участок памяти освобождается дважды).

    CVE-2017-7520


    Удалённый сбой клиента (включая MiTM), утечка данных.

    Эта уязвимость угрожает только тем, кто использует OpenVPN для подключения к прокси NTLM version 2.

    В файле ntlm_phase_3() in ntlm.c обнаружен следующий код:

    if (( *((long *)&buf2[0x14]) & 0x00800000) == 0x00800000)          /* Check for Target Information block */
    {
        tib_len = buf2[0x28];            /* Get Target Information block size */
        if (tib_len > 96)
        {
            tib_len = 96;
        }
        {
            char *tib_ptr = buf2 + buf2[0x2c];           /* Get Target Information block pointer */
            memcpy(&ntlmv2_blob[0x1c], tib_ptr, tib_len);           /* Copy Target Information block into the blob */
        }
    }

    Массив buf2 здесь содержит данные, полученные пиром (прокси).

    Фаззинг показал несколько багов. Во-первых, если buf[0x28] содержит значение 0х80 или больше, то tib_len станет отрицательным, что порушит memcpy. Во-вторых, buf[0x2c] используется как индекс для массива buf2. Если оно примет значение 0х80 или больше, то tib_len опять станет отрицательным и в данном случае будет указывать перед buf2, что приведёт к утечке данных. Память с этого адреса затем копируется в ntlmv2_blob, которым потом отправляется пиру. Налицо утечка данных и потенциальная возможность для атаки MiTM. Пароль пользователя, кстати, тоже хранится в стеке, и тоже будет отправлен пиру чистым текстом. Такая атака может быть спровоцирована злоумышленником в дистанционном режиме.

    Повреждение буфера стека у клиента и MITM (нет CVE)


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

    CVE-2017-7508


    Уязвимость позволяет осуществить удалённое обрушение сервера, на котором работает OpenVPN, если злоумышленник пошлёт на него специальным образом составленные данные.

    Дело в том, что функция mss_fixup_dowork() в файле mss.c содержит следующий код:

    ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr));

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

    CVE-2017-7522


    Атака с обрушением сервера mbed TLS/PolarSSL для своего успешного проведения требует, чтобы на сервере была установлена опция конфигурации –x509-track. Уязвимости подвержена OpenVPN 2.4 (не 2.3), скомпилированная с криптографическим бэкендом mbed TLS/PolarSSL.

    Был найден ещё один баг (нет CVE) с переполнением буфера стека в случае исключительно длинной опции –tls-cipher, но это не классифицировали как реальную уязвимость, потому что эксплуатация возможна только при условии ненадёжных настроек, а тогда атака доступна и по другим каналам.

    Для поиска уязвимостей Вранкен использовал фаззер libFuzzer вместе с AddressSanitizer (ASAN), UndefinedBehaviorSanitizer (UBSAN) и MemorySanitizer (MSAN).
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 40
    • +6
      Это наталкивает на мысль, что аудит исходников не даёт абсолютной гарантии отсутствия багов.

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

        Ну как же, это один из основных постулатов open-source — открытый код безопаснее, потому что каждый может изучить.

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

          Смогут они найти что-то или нет — другой вопрос. Я, в некоторых проектах (или частях одного крупного), бывает сразу и о основную логику вникнуть не могу, требует времени. Что говорить о нештатной эксплуатации.
          • +6
            Безопаснее переходить дорогу за зеленый свет по пешеходному переходу солнечным днем, чем перебегать где попало в темной одежде ночью. Но абсолютной гарантии успеха даже первый вариант не дает.
            • +1
              Может и каждый, но вот кто это действительно делает? Вспомните историю с Heartbleed.
              • +1
                Вопрос в том, как был найден HeartBleed? Не благодаря ли тому, что код открытый?

                Да, найдено поздно, но найдено. А сколько есть уязвимостей в проприетарных системах, можно и после взлома не узнать.
                • 0
                  Вопрос в том, как был найден HeartBleed? Не благодаря ли тому, что код открытый?

                  Неа. Это как раз хороший пример, который показывает, что и открытый код в большинстве случаев никто, кроме тех, кто непосредственно занимается его разработкой и сопровождением, не анализирует и не выверяет.
                  Будь код OpenSSL закрытым, ну нашел бы этот баг через те же несколько лет кто-то из внутренних разработчиков, только и всего.
                  • 0
                    Будь код OpenSSL закрытым, ну нашел бы этот баг через те же несколько лет кто-то из внутренних разработчиков, только и всего.

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

                    • 0
                      Ну так и с открытым абсолютно то же самое. Мы-то судим об одной уязвимости, которую нашли, при этом понятия не имеем, сколько их там ещё может быть. Так, чисто по статистике, какого-то преимущества по надёжности или безопасности у проприетарного или опенсурсного ПО не наблюдается. Т.е. сказать, что какая-то модель надёжнее, нельзя. Просто в проприетарном, если что, всегда можно ткнуть пальцем на конкретную организацию и сказать: «Это они виноваты». А в опенсурсе так не получится.
                      • +1
                        при этом понятия не имеем, сколько их там ещё может быть

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

                        Так, чисто по статистике, какого-то преимущества по надёжности или безопасности у проприетарного или опенсурсного ПО не наблюдается

                        А вот такие утверждения нуждаются в доказательстве. Приведите, пожалуйста, статистику.
                • 0
                  NSA точно делает.
                • 0

                  Ну да, он безопаснее — но это не значит, что он абсолютно безопасен.

                  • +1
                    Открытый код не безопаснее, а «потенциально безопаснее».

                    То есть у каждого желающего есть потенциальная возможность анализировать код и искать в нем проблемы — не обязательно даже сидеть самому смотреть, или нанимать экспертов — можно хотя-бы по-быстрому прогнать исходники через анализатор и получить дополнительные данные о качестве кода.
                • 0
                  Уязвимости так и будут появляться пока программы разрабатываются как произведения искуства, или творчества, если угодно.
                  • 0
                    Это как? Связи уловить не могу.
                    • 0
                      Речь, наверное, про то, что очень большая часть программистов самоучки-быдлокодеры, которые, например, на java пишут в процедурном стиле.
                      Правда сомнительно, чтобы в столь сложных проектах, как openvpn, мог разобраться и что-то дельное написать откровенный быдлокодер.
                      PS: Оскорбить ни кого не хочу. Просто факт: пока технология развивается — научного подхода ждать не стоит. Когда-нибудь IT это перерастет. Но пока это нормально.
                      • +1
                        Никогда IT это не перерастёт. Научный подход в программировании и так есть, с него, собственно, всё и началось. Он даже не сильно более требователен к качеству персонала. Но его проблема в том, что он требует просто астрономических трудозатрат, которые себя банально не окупают.
                        • 0
                          Ну перестали же врачи резать на удачу. Изучили/изобрели наркоз, антисептику и асептику, рентген… Чем мы хуже?
                          Просто постепенно будет написан почти весь код, который нужен миру и пространством для работы программистов останется только рефакторинг и оптимизация под частные задачи. Оптимизация мало сказывается на безопасности (не выгодно ломать код, который ни где не повторяется), а для рефакторинга нужно не только язык понимать, но и понимать что-то в теории программирования.
                          • 0
                            Ну перестали же врачи резать на удачу
                            Через несколько тысяч лет после зарождения медицины…

                            И количество врачебных ошибок все еще велико. Антисептика работает не всегда, от наркоза просыпаются не все, а трактовка мутных рентгеновских снимков — зачастую искусство.

                            У нас тоже, в общем-то есть аналогичные инструменты. Вместо антисептики — защитное программирование, вместо наркоза — сэндбоксы, а вместо рентгена вот фаззинг, например.
                      • +1
                        Мне это напомнило мысли отсюда:
                        … у большинства программистов не сформировано структурное отношение к программе (здесь слово «структурное» употребляем без прямой связи со структурным программированием, а в общем смысле). Программа для них — это нечто сродни литературному тексту, который пишет программист-«писатель», пытаясь описать требующиеся от машины действия. Более того, в таком отношении присутствует даже некая «художественная трепетность».

                        Вывод: восприятие программы как инженерной системы, составленной из конструкций, которые соединяются по определённым правилам, не сформировано у массовых программистов, и это представляет реальную проблему для развития ИТ как инженерной деятельности. Обязательное требование к инженерной деятельности — наличие строгих (обычно математизированных) методов, позволяющих анализировать и гарантировать свойства создаваемых конструкций, выводя их из свойств использованных элементов и соединений.
                        • 0
                          Жаль только, что этот вывод этот взят автором с потолка. А его «безусловно было продемонстрировано» на той же странице — попытка перейти от частного случая к общему выводу, причем путем радикального ухудшения читаемости кода.
                          • 0

                            Ну, я бы не сказал что качество кода радикально ухудшилось. Хотя и сильно лучше тоже не стало.

                    • 0
                      > Следуется обновиться до версий 2.4.3 и 2.3.17

                      У меня убунта, обновился:

                      root@42116f182a1c:/# openvpn --version
                      OpenVPN 2.3.2 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Jun 22 2017


                      Версия значительно старше, но дата сборки — вчерашняя. Уязвима она или нет?
                    • 0
                      Вот зачем выкладывать это после того как только-только (позавчера) релиз с заплаткой вышел. В репах пока ничего нет. Придется самому собирать.
                      • 0
                        Для некоторых дистрибутивов можно установить последнюю версию с оф. сайта.
                      • +2
                        А как узнать, проверяли ли его при помощи PVS-Studio?
                        • +1

                          Дружелюбно попросить сотрудников компании (например, Andrey2008, foto_shooter, AsyaRak, SvyatoslavMC) ответить, если им не сложно.

                          • 0
                            Спасибо! Отправил сообщения двум сотрудникам из списка: Andrey2008 и SvyatoslavMC (остальные двое read-only — наверное нет смысла к ним обращаться?).
                            • +1
                              Мы не проверяли проект OpenVPN. Проверял ли его кто-то ещё, я не знаю, но думаю, что нет.

                              Найдем ли мы такие ошибки? Не знаю, надо пробовать, но сомневаюсь. Надо понимать, что ранее мы не ориентировались в направлении поиска уязвимостей и только в последние месяцы начали смотреть в эту сторону. Там есть некоторая специфика, которой мы будем учить анализатор.

                              Сейчас PVS-Studio круто ищет ошибки. Некоторые из них по совместительству являются уязвимостями. Буквально на днях, мой коллега продемонстрировал, что некоторые из уязвимостей могли бы быть найдены с помощью PVS-Studio, если бы его кто-то запустил :). Он взял некоторые проекты (старые версии исходников) и убедился, что уязвимости находятся. Вот эта заметка: "Как PVS-Studio может помочь в поиске уязвимостей?".
                            • +1
                              Ну что Вам ответить?) Я проверю неисправленные исходники, посмотрим с коллегами несколько найденных CWE, кое-что может совпадёт с материалом этой статью. Диагностики PVS-Studio действительно покрывают очень много серьёзных CWE (но не все, многое из оригинального списка не относится к C/C++/C#, также очень много неадекватных правил, на мой взгляд).

                              Далее идёт работа по эксплуатации уязвимости и приведении её к CVE, для чего нужен соответствующий опыт. Найдя код:

                              ASSERT(BLEN(buf) >= (int) sizeof(struct openvpn_tcphdr));
                              


                              вряд ли я написал бы в статьи что-то типа
                              … существует возможность сконструировать такой пакет для сервера, чтобы указанное утверждение не выполнялось, и сервер остановится.

                              Мы пробуем сейчас сотрудничать со специалистами по безопасности, которые смогут выявлять уязвимости на основе найденных CWE с помощью PVS-Studio.

                            • 0
                              Можно даже самостоятельно взять открытый код и прогнать в PVS-Studio, и даже написать об этом на Хабр.
                              В этом и суть опен-сорса.
                              • +1
                                Посмотреть список на их сайте.
                              • +3
                                Не надо путать ручной аудит и фаззеры. Ручной аудит проверяет, что нет закладок. Фаззер пытается программу уронить. Можно иметь хорошо написанную программу с бэкдором, которой фаззер будет полностью доволен. И можно иметь честно написанную программу без бэкдоров, в которой фаззер будет ловить баги.

                                Фаззер хорошо, FUD в статье — нет.
                                • –1
                                  Государственная дума в первом чтении пропатчила уязвимости.

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.