стратегия
Миллионы ИТ-систем, включая индустриальные и IoT, начнут непредсказуемо вести себя 19 января. Среди возможных сбоев: проблемы в обработке карточных платежей, ложные срабатывания систем безопасности, некорректная работа медицинского оборудования, сбои систем автоматизированного освещения, отопления и водоснабжения и тысячи более безобидных ошибок. Правда, произойдет это в 2038 году, но это не повод расслабляться — времени на подготовку уже недостаточно. Причиной вороха разных проблем станет переполнение переменных, в которых хранится дата и время. Хотя первопричина ошибки проста и понятна, ее устранение потребует обширных и систематизированных усилий, причем как от государств и международных структур, так и от конкретных организаций и частных лиц.
Негласный стандарт «эпохи» Unix
Unix Epoch — это система отсчета времени, принятая в операционных системах Unix и ставшая популярной в ИТ-индустрии. Отсчет ведется с момента 00:00:00 UTC 1 января 1970 года, который принят за нулевую точку. Любой момент времени представляется как количество секунд, прошедших с этой даты. Для дат ранее 1970 года используются отрицательные значения. Этот подход был выбран разработчиками Unix для простоты — вместо хранения года, месяца, дня и времени по отдельности достаточно одного числа, с которым удобно проводить манипуляции вроде сортировки или определения промежутка между датами. Сегодня Unix Epoch используется далеко за пределами Unix-систем: в базах данных, языках программирования, сетевых протоколах, в смартфонах на iOS и Android.
Часовая бомба Y2K38
Изначально при разработке Unix решили хранить время в 32-битном знаковом целом числе, что позволяло представить диапазон примерно от 1901 до 2038 года. Проблема в том, что 19 января 2038 года в 03:14:07 UTC это число достигнет максимального значения (2 147 483 647 секунд) и переполнится, став отрицательным. Специфика хранения данных в этом формате такова, что старший бит используется как знак «минус», поэтому следом за самым большим положительным числом следует самое большое отрицательное, и из января 2038 года компьютер «телепортируется» в 13 декабря 1901 года. В ряде случаев, впрочем, возможно более короткое «путешествие во времени» — в точку 0, то есть в 1970 год.
Это событие, известное как «Проблема 2038 года», «Эпохалипсис», или Y2K38, может привести к сбоям в системах, которые до сих пор используют 32-битное представление времени — от POS-терминалов, встроенных систем и маршрутизаторов до автомобилей и промышленного оборудования. Современные системы решают эту проблему, используя 64 бита для хранения времени. Это расширяет диапазон дат до сотен миллиардов лет в будущее, но миллионы устройств с 32-битной датой все еще находятся в эксплуатации и потребуют обновления или замены до наступления «дня Y».
32 и 64 бита здесь относятся именно к формату хранения даты. То, что операционная система и процессор являются 32-битными или 64-битными, не обязательно означает, что они хранят дату в своем «родном» формате. Более того, многие приложения хранят дату вообще другим способом и могут не быть подвержены проблеме Y2K38 вне зависимости от «битности».
В ряде случаев, когда нет нужды обрабатывать данные ранее 1970 года, дата хранится в беззнаковом 32-битном числе. Такое число может представлять даты с 1970 по 2106 годы, и проблема наступит в более отдаленном будущем.
Отличия от «Проблемы 2000»
Известная с конца ХХ века «Проблема 2000» (Y2K) была похожа тем, что системы, хранившие год в виде двух цифр, в 2000 году могли счесть новую дату 1900 годом. Эксперты и СМИ опасались «большого цифрового апокалипсиса», но в реальности у проблемы были многочисленные частные проявления, которые не привели к глобальным катастрофическим сбоям.
Ключевое отличие Y2K38 от Y2K — масштаб цифровизации нашей жизни. Число систем, которые надо обновить, на несколько порядков выше числа компьютеров в ХХ веке, а количество повседневных дел и процессов, управляемых компьютерами, не поддается вычислению. При этом в «обычных» компьютерах и ОС проблему Y2K38 уже устранили или устранят в обозримом будущем простой установкой обновлений, а вот микрокомпьютеры, которые заведуют кондиционерами, лифтами, насосами, дверными замками и заводскими конвейерами, вполне могут прожить следующее десятилетие с устаревшей и уязвимой к Y2K38 версией ПО.
Возможные проблемы «Эпохалипсиса»
Переход даты на 1901 или 1970 год будет по-разному влиять на различные системы. В каких-то, где, например, освещение включается каждый день в 19:00, это может быть вообще незаметно. В каких-то системах, завязанных на полное и точное время, произойдет полный отказ. Например, в 2000 году не работали платежные терминалы и турникеты городского транспорта. Возможны и комичные случаи, такие как выдача свидетельства о рождении с датой в 1901 году. Гораздо хуже случи отказа критических систем, такие как полный отказ системы отопления или системы анализов костного мозга в больнице.
Особое место в «Эпохалипсисе» занимает криптография. Еще одно важное отличие 2038 года от 2000-го – повсеместное использование шифрования и цифровых подписей для защиты всех коммуникаций. Сертификаты безопасности, как правило, не проходят проверку при ошибочной дате на устройстве, поэтому уязвимое устройство окажется отрезано от большинства коммуникаций, даже если в запущенных бизнес-приложениях нет фрагментов кода, ошибочно обрабатывающих дату.
К сожалению, полный спектр последствий можно определить только контролируемым тестированием всех систем с отдельным анализом возможностей каскадного отказа.
Злонамеренная эксплуатация Y2K38
Командам ИТ и ИБ стоит относиться к Y2K38 не как к простой программной ошибке, а как к уязвимости, которая может приводить к различным сбоям, включая отказ в обслуживании. В ряде случаев ее могут эксплуатировать и злоумышленники. Для этого им нужна способность манипулировать временем в атакуемой системе. Она есть как минимум в двух сценариях:
- при вмешательстве в данные протокола NTP, когда атакуемой системе подсовывают фальшивый сервер точного времени;
- при подмене сигнала GPS, если система пользуется спутниковым временем.
Наиболее вероятна эксплуатация ошибки в системах OT и IoT, где традиционно уязвимости устраняются подолгу, а последствия отказа могут быть гораздо ощутимее.
Пример легко эксплуатируемой уязвимости, связанной с отсчетом времени — CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) в системах автоматизации бензоколонок Dover ProGauge MagLink LX4. Манипуляции со временем позволяют добиться отказа в обслуживании на автозаправке и отказа в доступе к панели веб-управления устройством. Дефект удостоился отдельного бюллетеня CISA.
Текущий статус устранения Y2K38
Фундамент для решения проблемы Y2K38 успешно заложен в основных ОС. В ядре Linux добавлена поддержка 64-битного времени даже для 32-битных архитектур начиная с версии 5.6 в 2020 году, а 64-битный Linux всегда был защищен от этой проблемы. Семейство BSD, macOS и iOS используют 64-битное время на всех современных устройствах. Ни одна версия Windows, выпущенная в XXI веке, не подвержена Y2K38.
Ситуация на уровне хранения данных и приложений гораздо сложнее. Современные файловые системы вроде ZFS, F2FS, NTFS и ReFS были спроектированы с 64-битными временными метками, в то время как старые системы ext2/ext3 остаются уязвимыми. Ext4 и XFS требуют включения специфичных флагов (расширенные inode для ext4, bigtime для XFS) и могут потребовать офлайн-конвертации существующих файловых систем. Сохраняется устаревший формат хранения времени в протоколах NFSv2/NFSv3. В базах данных тоже мозаика: тип TIMESTAMP в MySQL фундаментально ограничен 2038 годом и требует миграции на DATETIME, в то время как стандартные типы timestamp в PostgreSQL безопасны. Для приложений, написанных на C, созданы пути для использования 64-битного времени на 32-битных архитектурах, но всем проектам требуется перекомпиляция. В языках Java, Python и Go обычно используют типы, избегающие переполнения, но безопасность собранных проектов зависит от того, взаимодействуют ли они с уязвимыми библиотеками, написанными на C.
Огромное количество 32-битных систем, встраиваемых устройств и приложений остаются уязвимыми, пока их не пересоберут и не протестируют, а затем не установят обновления у всех пользователей.
Различные организации и энтузиасты стараются систематизировать информацию по этому поводу, но их усилия разрозненны, поэтому никакой «общей базы уязвимостей Y2K38» нет (1, 2, 3, 4, 5).
Подходы к устранению Y2K38
К «Проблеме 2038», применимы методологии, созданные для приоритизации и устранения уязвимостей. Ключевой проблемой будет то, что никакой инструмент на сегодня не может составить исчерпывающий список подверженного проблеме ПО и «железа», поэтому необходимо обновить инвентарь ИТ-активов, убедиться, что он обогащен подробной информацией о прошивках и установленном ПО и дальше систематически изучать вопрос уязвимости.
Приоритизировать список можно, исходя из критичности бизнес-систем и данных о технологическом стеке, на котором построена каждая система. Далее — изучение портала поддержки, прямые запросы к производителю оборудования и ПО о статусе Y2K38, на крайний случай — проверка тестированием.
При тестировании своих систем важно принимать специальные предосторожности:
- никогда не тестировать системы, находящиеся в реальной эксплуатации (production systems);
- создавать резервную копию данных в системе непосредственно перед тестом;
- изолировать тестируемую систему от коммуникаций, чтобы он не могла «сбить» другие системы в организации;
- если смена даты проводится с использованием NTP или GPS, убедиться, что тестовые «сигналы-2038» не могут достичь других систем;
- после тестирования установить в системах корректное время и подробно задокументировать все обнаруженные аспекты поведения системы.
Если система подвержена Y2K38, необходимо запросить у производителя сроки по исправлению, а при невозможности исправления — спланировать миграцию, благо запас времени пока еще позволяет обновить даже достаточно сложные и дорогие системы.
Главное в устранении Y2K38 — не думать, что это проблема далекого будущего, решение которой легко ждет еще 5–8 лет. Вероятнее всего, для полного устранения дефекта запас времени недостаточен уже сейчас. Но в рамках организации и ее технологического парка можно запланировать ежегодные мероприятия, систематически продвигаться к решению проблемы — и успеть.
Советы