Security Week 2202: Y2K22

от автора

Новогодние праздники — самое подходящее время для неожиданных глюков софта, который, по идее, должен работать, пока все остальные отдыхают. Именно на новый 2022 год пришлось сразу несколько сообщений о проблемах с обработкой дат, которые можно по аналогии с «проблемой 2000 года» или Y2K назвать «Y2K22». Сбои интересны тем, что, в отличие от «проблемы 2000» или «проблемы 2038» в Unix time, или хотя бы «проблемы 2010», от 2022 года никто таких сбоев не ожидал.

Наиболее заметной оказалась проблема с onpremises-серверами Microsoft Exchange. 1 января Exchange версий 2016 и 2019 гг. перестал обрабатывать почту (новость, обсуждение на Хабре, статья Microsoft). Причина сбоя была во встроенном в Exchange Server антивирусном сканере, а точнее, в простом обработчике даты внутри. Дата обрабатывалась в виде «YYMMDDHHMM» и при этом хранилась в виде числа в переменной такого типа, который допускает максимальное значение 2147483647. Сразу после боя курантов дата сменилась на 2201010001, и произошло переполнение.

К счастью, проблема решалась как временным способом (отключение антивирусного сканера), так и постоянным — скрипт для обновления кода Microsoft выложила вечером 1 января по московскому времени. В условиях почти всемирного выходного это достаточно оперативно. Тем не менее администраторам почтовых систем требовалось а) обнаружить, что почта не ходит, и б) накатить патч вручную. В какой-то момент недальновидность разработчика заложила в почтовый сервер бомбу замедленного действия.

Другие сообщения о проблемах со временем не приводили непосредственно к сбоям, а просто действовали на нервы. В твите выше и в статье на Bleeping Computer сообщается о сбросе часов в автомобилях Honda и Acura. Автомобиль утверждает, что на дворе 2002 год, а не 2022. В отличие от бага Y2K в старых материнских платах, где сбой происходил только в сам момент смены года, проблема в японских автомобилях более серьезная: можно сколько угодно пытаться установить правильную дату, но при следующем запуске авто она откатывается обратно на 1 января 2002 г. И этот сбой не вызван хранением даты в формате int32, как в случае с Exchange. Техподдержка автопроизводителя сообщает, что «проблема решится сама собой в августе 2022 года». Подробного объяснения причин такого феномена, равно как и патчей (которые вряд ли будут доступны для старых машин), пока не существует.

Что ещё произошло:

Автор популярных библиотек faker.js и colors.js намеренно добавил в них код, приводящий к зависанию. Это вызвало сбои во всех программах, использующих код этих библиотек — они распространяются по свободной лицензии MIT. Автор аргументировал свои действия несправедливой эксплуатацией свободного кода крупными компаниями. Судя по всему, после этого автор лишился доступа к своим репозиториям на Github, а вредоносные изменения там были отменены администрацией хостинга. История подробно описана на Хабре. Она имеет логическую связь с декабрьскими багами в log4j: там тоже шла речь об открытом проекте, разрабатываемом на общественных началах, которым бесплатно пользуются крупные организации, встраивая код в коммерческие продукты. Возможно, это и правда несправедливо, но устраивать саботаж — странный способ добиваться справедливости.

Опубликовано подробное описание прошлогоднего бага, который делал невозможным звонок в экстренные службы, если на Android-телефоне установлен Microsoft Teams. Как выяснилось, имела место комбинация причин. Если Teams установлен, но вы в него не залогинены, то при каждом запуске он создает виртуальную телефонную учетную запись. При попытке позвонить в 911 или 112 телефонная система Android пытается понять, через какую учетку звонить, применяет криво написанную систему сортировки и падает с ошибкой. Тем временем январский апдейт безопасности для Android закрыл 35 уязвимостей.

Исследователи из Кореи нашли способ записывать данные на некоторые SSD так, чтобы они сохранялись после форматирования (новость, научная работа). Это открывает путь к вредоносным атакам на ПК, которые переживают полную переустановку системы.


ссылка на оригинал статьи https://habr.com/ru/company/kaspersky/blog/599995/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *