Специалисты «Базис», компании-лидера российского рынка средств виртуализации, вместе с сотрудниками ИСП РАН и испытательной лаборатории «Фобос-НТ» провели очередной этап тестирования компонентов с открытым исходным кодом, которые используются в инструментах виртуализации по всему миру, в том числе в продуктах компании. Результатом совместной работы стало обнаружение и последующее устранение 191 дефекта в коде, некоторые из которых были расценены как уязвимости.

В рамках нового этапа испытаний тестировались следующие компоненты с открытым исходным кодом: nginx, ActiveMQ Artemis, Apache Directory, libvirt-exporter, QEMU. Особое внимание было уделено libvirt — сбой в работе этой библиотеки может нанести ущерб инфраструктуре и привести к утечке конфиденциальной информации, поэтому она была подвергнута комплексному исследованию. Перечисленные компоненты используются вендорами по всему миру — libvirt предоставляет API для управления виртуальными машинами, nginx помогает балансировать нагрузку и т.д. — и от качества их работы зависит множество российских и иностранных решений для работы с виртуальными средами.

При разработке и тестировании продуктов «Базис» применяются различные виды анализа, такие как фаззинг, статический анализ, композиционный анализ, модульное и функциональное тестирование. На прошедшем этапе испытаний основной упор исследователи сделали на разметке срабатываний статического анализатора Svace (разработан в ИСП РАН) и создании фаззинг-целей.

Статический анализ выявил 178 дефектов в коде тестируемых компонентов. Изучив их, специалисты ИСП РАН и «Базис» разработали 86 исправлений, которые были приняты в основные ветки разработки соответствующих проектов. Большая часть срабатываний относилась к популярному брокеру сообщений ActiveMQ Artemis и серверу каталогов Apache Directory.

Фаззинг-тестирование выявило еще 13 дефектов в коде — 5 в Apache Directory LDAP API и 8 в библиотеке libvirt. Последние были найдены в ходе проверки функций обработки инструкций, которые потенциально могут быть получены из конфигурационных файлов при создании виртуальной машины. В частности, были найдены ошибки, связанные с переполнением буфера, а также несколько проблем, связанных с неоптимальной работой функций в отношении некоторых контроллеров. Все поданные исправления были оперативно приняты в основные ветки разработки libvirt и Apache Directory.

Источник изображения: Markus Spiske / Unsplash

В рамках подготовки к тестированию для наиболее критичных компонентов открытого ПО, лежащих на поверхности атаки, были разработаны фаззинг-тесты. Их можно найти в соответствующих проектах на GitLab-портале Центра исследований безопасности системного ПО. В дальнейшем созданные сотрудниками ИСП РАН и «Базис» цели послужили исследованиям, которые специалисты «Фобос-НТ» выполняли на своих мощностях. Найденные коллегами дефекты также были учтены при обновлении компонентов с открытым исходным кодом в продуктах «Базис».

«Мы очень серьезно относимся к качеству кода экосистемы «Базис», поэтому тестируем на ошибки и уязвимости не только собственный код, но даже компоненты с открытым исходным кодом, которые используем. Более того, без такого тестирования невозможны современная безопасная разработка и сертификация. Такой подход делает наши решения более качественными и защищенными, а также вносит вклад в развитие открытых инструментов виртуализации, которые используются различными вендорами по всему миру. Реализовать его было бы сложно без партнеров, сотрудничество с ИСП РАН и НТЦ «Фобос-НТ» позволяет «Базису» выстраивать качественные процессы безопасной разработки и тестирования инструментов виртуализации, повысить уровень зрелости экосистемы. В результате наши продукты не только сертифицированы ФСТЭК России, но и в максимально короткие сроки проходят инспекционный контроль. В итоге наши заказчики могут быть уверены, что решения «Базиса» проверены, а созданная на их основе инфраструктура компании безопасна», — отметил Дмитрий Сорокин, технический директор компании «Базис».

Очередной этап тестирования и исследования кода проходил на инфраструктуре Центра исследований безопасности системного ПО, созданного ФСТЭК России на базе ИСП РАН. Компания «Базис» принимает непосредственное участие в деятельности Центра и является активным участником РБПО-процессов, инициируемых и развиваемых ФСТЭК России. Работы по разметке и созданию целей для фаззинга выполнялись совместно с ИСП РАН, к решению этой задачи были привлечены студенты профильных специальностей МГТУ им. Н.Э. Баумана и Чувашского государственного университета. Сотрудники испытательной лаборатории НТЦ «Фобос-НТ» проводят сертификационные испытания продуктов «Базис» и занимаются улучшением фаззинг-тестов, в том числе разработанных компанией.

«Яндекс» объявил о запуске нового конкурса в рамках программы «Охота за ошибками». Эксперты в области информационной безопасности смогут получить денежное вознаграждение до 2,8 млн руб. за обнаружение критических уязвимостей в продуктах и сервисах российского IT-гиганта. Это в пять раз больше обычных премий, которые «Яндекс» выплачивает этичным хакерам.

Охотники за ошибками смогут получить повышенное вознаграждение за отчёты в двух категориях. Одна из них — IDOR (Insecure Direct Object Reference), или небезопасный прямой доступ к объектам. Это уязвимости в механизмах защиты сайтов, через которые злоумышленники могут получить доступ к приватной информации через ошибки в API.

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

Источник изображения: pixabay.com

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

В соответствии с правилами, исследователи могут использовать только собственные тестовые аккаунты для проверки возможных уязвимостей. Пытаться получить доступ к информации других пользователей нельзя. «Яндекс» отдаст приоритет найденным во время конкурса ошибкам и оперативно их исправит. Мероприятие проводится до 31 августа 2023 года.

Компания Intel, по сообщению ресурса Tom's Hardware, возобновила отгрузки процессоров Xeon Sapphire Rapids после устранения выявленной ошибки. Клиенты, которые ранее закупили проблемные чипы, могут получить обновление микрокода, в котором баг отсутствует.

Об обнаруженной ошибке стало известно в конце июня нынешнего года. Говорилось, что баг может провоцировать внезапную остановку работы системы. На тот момент способов решения проблемы известно не было. Чипы Sapphire Rapids доступны в двух конструктивных вариантах: XCC и MCC. В первом случае применяется сборка из четырёх кристаллов: число вычислительных ядер варьируется от 36 до 60. Вторая модификация имеет монолитную конструкцию с числом ядер до 32. И именно в MCC-изделиях обнаружилась недоработка. Intel заявила о приостановке поставок этих процессоров из соображений предосторожности, но не назвала конкретную дату возобновления отгрузок.

Изображение: Intel

Проблему удалось решить путём выпуска новой версии прошивки, так что компании не пришлось инициировать дорогостоящую программу отзыва и замены чипов. «Недавно мы сообщили о проблеме с подмножеством процессоров Intel Xeon со средним числом ядер (SPR-MCC), которая может прерывать работу системы при определённых условиях. Из соображений предосторожности мы временно приостановили поставки этих изделий. Теперь мы уверены, что новая микропрограмма решает проблему. Мы возобновили поставки всех версий SPR-MCC и работаем с клиентами над внедрением исправленной прошивки», — сказали в Intel.

Корпорация Intel, по сообщению ресурса Tom's Hardware, вынуждена приостановить поставки определённых процессоров Xeon Sapphire Rapids из-за обнаружившейся ошибки. Баг может провоцировать внезапную остановку работы системы. Специалисты Intel уже занимаются решением проблемы.

Чипы Xeon Sapphire Rapids существуют в двух конструктивных исполнениях — XCC и MCC. В первом случае применяется сборка из четырёх кристаллов, а количество вычислительных ядер варьируется от 36 до 60. Второй вариант имеет монолитную конструкцию с числом ядер до 32.

Источник изображения: Intel

Известно, что ошибка проявляется в отдельных MCC-моделях Sapphire Rapids. Отгрузки этих продуктов, как отмечается, были приостановлены в середине июня. По всей видимости, Intel работает над новой версией прошивки, которая позволит исправить баг. Если решить проблему удастся таким способом, компании не придётся инициировать программу отзыва и тратить значительные средства на обмен дефектных изделий.

«Нам стало известно о проблеме с частью процессоров Xeon Sapphire Rapids (MCC) со средним числом ядер, которая может прерывать работу системы при определённых условиях, и мы активно изучаем её. Из соображений предосторожности мы временно приостановили поставки этих чипов», — сообщил представитель Intel.

Нужно отметить, что ошибки в процессорах — не редкость. Так, чипы Intel Skylake вышли с 53 известными багами, а шесть месяцев спустя Intel сообщила ещё о 40 ошибках. А недавно стало известно, что процессоры EPYC Rome перестают функционировать через 1044 дня непрерывной работы, но устранять ошибку AMD не планирует.

Серверные процессоры AMD EPYC 7002 (Rome), по сообщению ресурса Tom's Hardware, «зависают» спустя 1044 дня непрерывной работы — это приблизительно 2,86 года. После этого требуется перезагрузка сервера для восстановления его нормального функционирования.

Проблема связана с тем, что ядро названных чипов не может выйти из энергосберегающего режима CC6. Говорится, что конкретные сроки возникновения сбоя могут варьироваться: они зависят от функции Spread Spectrum и опорной частоты REFCLK (используется процессором для отслеживания времени).

Источник изображения: AMD

Однако пользователь Reddit с ником acid_migrain говорит, что на самом деле проблема проявляется через 1042 суток и примерно 12 часов, а не 1044 дня, как предупреждает сама AMD. Дело в том, что счётчик TSC (Time Stamp Counter), работающий на частоте 2800 МГц, зависает при значении 0x3800000000000000. Это 2800 × 10⁶ × 1042,5, то есть, спустя 1042 дня и 12 часов после начала отсчёта. «Здесь слишком много нулей, чтобы это было совпадением», — отмечает acid_migrain.

AMD не планирует исправлять ошибку. Избежать сбоя, как уже отмечалось, можно путём периодической перезагрузки сервера. Второй вариант — отключить возможность перехода в состояние CC6. Наблюдатели говорят, что данная особенность EPYC Rome вряд ли будет критична для большинства пользователей: почти три года непрерывной работы — это большой срок, в течение которого, скорее всего, будут выполняться перезагрузки в связи с техническим обслуживанием или обновлениями.