Про сбой CrowdStrike и Windows

19 июля 2024 года случился один из самых больших технических сбоев в современной истории - больше 8 млн. компьютеров на Windows упали в BSOD (синий экран смерти) и без помощи кожаных мешков встать уже не смогли. Если помните, тогда это затронуло много всего - аэропорты, больницы, операторы связи, банки - куча рейсов было отменено, куча каскадных сбоев по всей инфраструктуре и прочее-прочее. Проблема с программами, которые виртуальные, ОЧЕНЬ сильно повлияла на мир физический в тот момент. Причиной этих сбоев стала проблема при работе антивирусной программы от компании Crowdstrike. Ее продуктами пользуются тысячи компаний по всему миру.

А почему вообще случился этот сбой?
Корневой причиной этого инцидента оказалось плохое обновление. Следите за руками:
- Часть проверок безопасности шла вместе с дистрибутивом очередной версии их продукта. Но это инфобез, а значит новые угрозы появляются чаще, чем клиенты привыкли обновляться. Поэтому Crowdstrike поставляли облачные обновления с библиотеками новых проверок.
- Применить эти обновления просто так нельзя, потому что антивирус Crowdstrike работает на уровне ядра ОС и ниже. Просто так "с улицы" Microsoft никому не дает выполнять код на уровне ядра, для этого нужно получить специальный сертификат Windows Hardware Quality Labs, где ваш код будет жестко проверен.
- Если для обновления проверок безопасности нужно каждый раз проходить такую сертификацию, то о "быстрых" обновлениях можно забыть - такие сертификации занимают дни и недели.
- Поэтому Crowdstrike написали драйвер, который помимо выполнения части проверок, мог динамически загружать и выполнять код из файлов обновлений т.е. они сделали некий "движок" проверок. Именно этот драйвер и отправился на сертификацию и когда-то успешно ее прошел. За счет этого хода получилось, что и сертификат от Microsoft новый получать каждый раз не нужно и все свежие данные для обнаружения угроз доставляются и применяются очень быстро. Успех!
- В феврале 2024 Crowdstrike зарелизили новый тип проверок. Одной из его особенностей стало то, что в файле обновления добавилось новое 21-е поле (раньше было 20).
- 19 июля Crowdstrike покатили обновление, которое впервые начало использовать проверку безопасности с этим самым 21 полем. И тут - БУМ!!! - BSOD из-за чтения за пределами массива, потому что никакого 21 поля в рантайме нет.
- СТОП. Но в файле обновления оно же есть? Да, есть. Но беда была в том, что логика, которая читала этот файл и инициировала дальнейшую работу проверок из обновления, читала ТОЛЬКО ПЕРВЫЕ 20 ПОЛЕЙ. ОНА ВСЕГДА ПЕРЕДАВАЛА ДАЛЬШЕ ТОЛЬКО 20 ПОЛЕЙ, КАРЛ!
- А тут впервые сработала логика, которая ожидала во входном массиве 21-е поле. Но поля этого не оказалось. Из-за чего эта логика упала и потащила за собой всю систему...

Тэк, а почему упала ОС, а не просто приложение?
Это случилось потому, что этот код выполнялся на уровне ядра ОС. Когда падает код на уровне приложения - падает приложение. Когда падает код на уровне ядра - падает сама ОС. Такой защитный механизм реализован во всех современных ОС - таким образом она защищается от невалидного состояния, в котором продолжать работу ЕЩЕ ОПАСНЕЕ, чем просто упасть.
Важная фишка - драйвер от Crowdstrike был зареган как boot-start драйвер. Этот тип драйверов вклинивается в процесс запуска ОС и запускается на максимально раннем этапе, что усугубило ситуацию.

Почему проблему не выявили раньше, если релиз нового типа проверок был в феврале?
Это хороший вопрос к качеству тестирования в Crowdstrike. В самом постмортеме они честно говорят, что на этапе тестирования использовали в этом 21 поле wildcard типа звездочки. Вероятно, из-за этого логика работы с конкретными значениями не запускалась.

Как можно работать с массивом и не проверять его размерность и кол-во входных параметров?!
¯\_(ツ)_/¯
В своем постмортеме ребята честно выделяют это как один из action items.

P.S. Но на самом деле все это случилось из-за деплоя в пятницу.

P.PS. В комментах добавлю полный список их action items, как я его понял, а также ссылку на оригинал постмортема.