Самый дорогой software-failure в истории — ~$5,4 млрд прямого ущерба. А причина — баг из первой главы учебника по тестированию: рассинхрон «20 против 21 параметра» во внутреннем валидаторе. Разбираем timeline, root cause и — главное — три отдельных провала QA, которые это допустили, плюс уроки, которые забираются в любую команду.
19 июля 2024 года в 04:09 UTC CrowdStrike выкатил обновление контентного файла для своего антивируса Falcon Sensor. За следующие 78 минут 8,5 миллиона Windows-машин по всему миру ушли в бесконечный BSOD-loop. Встали аэропорты (>5000 отменённых рейсов только в США), больницы, банки, биржи, 911-диспетчерские. Прямой ущерб корпоративных клиентов — около $5,4 млрд по оценке Parametrix; одна только Delta потеряла ~$500 млн.
Самое неприятное для нас, инженеров: баг был тривиальный. Не гонка потоков на проде под нагрузкой, не хитрый UB в компиляторе — а банальный выход за границу массива, который ловится unit-тестом за пять секунд. Ниже — как именно это произошло и почему ни один уровень защиты не сработал.
Timeline: что произошло
04:09 UTC, 19 июля — выкатан channel file 291 (
C-00000291-*.sys). Это не код, а конфиг с правилами детекции для kernel-mode-драйвера Falcon Sensor.Сразу после установки — драйвер в kernel-mode читает channel file → out-of-bounds read → kernel panic → BSOD.
При перезагрузке — драйвер грузится снова (он уровня ядра, стартует на boot), снова читает тот же файл → снова BSOD. Замкнутый цикл.
05:27 UTC — CrowdStrike откатил файл (через 78 минут). Но машины, уже получившие его, новый файл скачать не могли — они в BSOD-loop, до сети дело не доходит.
Восстановление — каждую машину вручную: boot в safe mode, удалить
C-00000291*.sys, перезагрузить. Для BitLocker — ещё и ввести recovery-ключ. Помножьте на 8,5 млн.
Полная хронология — в техническом разборе CrowdStrike и на Wikipedia.
Почему «контентный файл» мог уронить ядро
Falcon Sensor — kernel-mode-антивирус, видит каждое действие в системе. Чтобы быстро ловить новые угрозы, CrowdStrike доставляет channel files — файлы с правилами детекции. И вот их архитектурный статус и стал корнем проблемы:
расширение
.sys(что путает всех — это не драйверы, а данные для драйвера);доставляются автоматически каждые несколько часов, без согласия клиента;
считались «контентом», поэтому не проходили полный QA-конвейер, который проходит сам драйвер;
не подписывались Microsoft через WHQL — формально это же «не новый драйвер»;
клиенты не могли отложить их или раскатывать поэтапно — файл доходил до всех сразу.
То есть «контент летает без проверки и сразу на всех» — при том, что этот контент способен уронить ядро. Дальше дело техники.
Конкретный баг
По публичному root cause analysis CrowdStrike — классический off-by-one и out-of-bounds read:
Template Type 291 (внутренний формат channel file) обновили в феврале 2024 — он стал принимать 21 входной параметр вместо 20.
Content Validator — внутренний инструмент, проверяющий channel files перед выпуском, — ожидал 20 параметров и про изменение «не знал».
19 июля файл 291 выпустили с 21 параметром. Валидатор его пропустил как корректный.
Драйвер в kernel-mode обратился к 21-му параметру по индексу
[20]— а такого элемента в выделенной памяти нет. Out-of-bounds read.В kernel-mode out-of-bounds read = немедленный kernel panic = BSOD.
Один рассинхрон «20 против 21» на стороне внутреннего валидатора уронил половину корпоративной инфраструктуры планеты.
Три отдельных провала QA
Это не «один баг проскочил». Это три независимых барьера, каждый из которых должен был остановить катастрофу — и ни один не сработал.
1. Сам валидатор никто не тестировал на edge-кейсах. Валидатор — это тоже софт, и в нём тоже бывают баги. Когда формат обновили до 21 параметра, валидатор не обновили синхронно. Не было теста уровня «hello world»: «прогони через валидатор все актуальные Template Type и проверь точное число полей». Такой тест ловит баг мгновенно.
2. Не было staged rollout для channel files. Для основного драйвера поэтапная раскатка была. А «контент» уезжал всем сразу. Уйди файл 291 сначала на 1% — массовые BSOD были бы видны за 15 минут, и его откатили бы до того, как он дошёл до остальных. Вместо этого все 8,5 млн получили его одновременно.
3. Не было kill switch и boot-level recovery. Когда контент роняет kernel-драйвер, система не загружается. Не было ни механизма «N BSOD за минуту → пропустить этот channel file и грузиться без него», ни локального отката последнего файла. Драйвер и данные оказались жёстко связаны без аварийного обхода.
Что CrowdStrike поменял после
(Из публичных RCA и Remediation Hub.)
Поэтапная раскатка для channel files — ring-based (canary → small → large), как у Microsoft/Apple для апдейтов ОС.
Контроль на стороне клиента — выбор, когда получать content-обновления.
Доп. валидация — сторонний review для значимых изменений в Template Types.
Тесты для самого Content Validator — regression на boundary conditions для всех известных форматов.
Независимая телеметрия — отдельный канал оповещения, не зависящий от того, что продукт сам уронил сеть.
Уроки, которые забираются в любую команду
1. «Контент» — это код. Если данные (config, feature flags, channel files, ML-модели, JSON-схемы) могут уронить приложение — значит, по факту это код. Тот же конвейер: unit, integration, staged rollout, kill switch.
2. Staged rollout — для всего, что доезжает до прод-машин. Не только для бинарей. Для флагов, моделей, конфигов, пушей, скриптов. Минимальный canary: 1% → 10% → 50% → 100% с мониторингом между кольцами. Это не overhead, это вторая линия защиты, когда unit-тест пропустил баг.
3. Валидаторы тоже тестируются. Любой инструмент, проверяющий другие артефакты (linter, schema checker, type checker), должен иметь свой test suite: на валидных примерах (должен пропустить) и невалидных (должен поймать). Иначе это security theatre.
4. Boundary conditions — first-class тест-кейсы. Off-by-one — самый частый и самый дорогой баг индустрии. 20 vs 21, 0 vs 1, N vs N+1, пустой массив, max. Эти кейсы должны быть в каждом наборе тестов для функции с индексным доступом или коллекцией.
5. Kill switch без сети. Любой авто-апдейт, доезжающий до прод-машины без согласия пользователя, обязан иметь способ откатиться локально. Иначе апдейт, убивший сеть, делает восстановление невозможным.
6. Тестируйте recovery, а не только happy path. У CrowdStrike не было протокола «как поднять 8,5 млн машин из BSOD-loop». В каждый release-план должен входить ответ на вопрос: «что делаем, если этот релиз сломал прод и не откатывается сам?»
Чек-лист: как не словить свой CrowdStrike-момент
Каждый артефакт, доезжающий до прод-машины (код, config, флаг, ML-модель, контент), идёт через staged rollout: canary 1% → 10% → 50% → 100%.
Между кольцами — окно мониторинга и автоматический rollback при отклонении ключевых метрик (crash rate, error rate, latency).
У валидаторов и schema-checker'ов есть свой regression-набор на все известные форматы входа.
Boundary conditions явно покрыты для каждой функции с индексным доступом/коллекцией: N-1, N, N+1, 0, max.
Kill switch без сети: локальный откат конфига / safe-mode boot / флаг через cached-state.
У kernel-mode / system-critical компонентов есть механизм «N крашей за M минут → пропустить компонент на следующем boot».
Recovery-протокол задокументирован и протестирован: что делать, если не грузятся 1% / 10% / 50% / 100% машин.
Телеметрия о крашах не зависит от продукта (продукт сломал сеть — телеметрия всё равно дойдёт).
Контент-апдейты ≠ бинарные апдейты только на словах: по факту — тот же CI/QA-конвейер.
В disaster recovery runbook учтены каскадные сбои вроде «потеряли BitLocker recovery keys».
CrowdStrike 19 июля 2024 — это не злой рок и не редкий corner case. Это история про то, что базовые принципы — «тестируй границы, раскатывай поэтапно, держи kill switch» — не работали ни на одном уровне сразу. И любая команда, которой «некогда возиться с canary», находится в одной публикации от собственного такого дня.
Я разбираю подобные инциденты и практику QA каждый день в Telegram-канале «QA — Quality Assurance»: t.me/qa10100011000001. Если тема зашла — забегайте.