Copy Fail: старые Linux-образы всё ещё рискуют
Сначала хорошие новости: Linux-эксплойт “Copy Fail”, о котором писал It’s FOSS, уже исправлен. Это не ситуация из серии «бросайте всё, потому что фикса ни у кого нет». Фикс есть. Ваша задача — убедиться, что он действительно попал туда, где работают ваши workloads.
И вот на этом втором пункте команды часто сгорают. 💀
На одном Linux-ноутбуке путь обычно простой: обновить packages, перезагрузиться при необходимости и жить дальше. В cloud- и container-средах реальность сложнее. Исправленный package в upstream repository не означает автоматически, что каждый base image, container layer, node pool, virtual machine template, CI runner и долгоживущий workload уже чист. Старые images остаются. Cached layers остаются. “Golden” templates превращаются в окаменелости. Production часто запускает вчерашнюю filesystem с сегодняшней уверенностью.
Так что практический вывод прямой: Copy Fail может быть уже patched, но устаревшие Linux-следы всё равно требуют активной зачистки.
Что произошло: patched не значит gone#
Отчёт It’s FOSS рассказывает о Linux-эксплойте, известном как “Copy Fail”, и, что важно, отмечает: он уже patched. Это важно, потому что разговор о security не должен начинаться с паники. Если patch доступен, приоритет смещается от догадок к исполнению.
Проблема в том, что многие организации воспринимают “patched upstream” так, будто это означает “resolved internally”. Это разные вещи.
Vulnerability может быть исправлена maintainers, но всё ещё оставаться в:
- unpatched Linux hosts;
- старых VM snapshots и templates;
- base container images, которые не были rebuilt;
- running containers, запущенных до patch;
- Kubernetes nodes, которые не были rolled;
- CI/CD runner images с cached dependencies;
- internal mirrors или registries, которые sync медленно;
- appliances или managed workloads с delayed update cycles.
Security fixes — это не магические пакеты, отправленные во весь ваш fleet. Это изменения, которые нужно pull, build, deploy, restart и verify. До этого старые vulnerable bits могут продолжать выполняться в production.
В этом главный урок. Patch — это начало закрытия проблемы, а не само закрытие.
Почему cloud и containers повышают срочность#
Cloud- и containerized-среды эффективны потому, что повторно используют layers, images, snapshots и templates. Но то же самое reuse может сохранять vulnerable components ещё долго после того, как maintainers выпустили fixes.
Традиционный server можно проверить и patch напрямую. Containers добавляют ещё один уровень косвенности: вы можете patch host, но ваш workload всё равно может быть основан на outdated image. Или вы можете rebuild application image, но build подтянет старый internal base image, который никто не обновил. Или registry tag говорит latest, а running workload был создан из более старого digest несколько недель назад.
Вот так risk и прячется.
Stale base images — обычное кладбище#
Многие container-команды зависят от base images: distribution images, language runtime images или внутренних hardened “golden” images. Когда выходит Linux security fix, эти base images нужно обновить, а downstream images — rebuilt.
Если вы patch только host nodes, но никогда не rebuild containers, вы всё ещё можете поставлять vulnerable userland packages внутри workload image. Если build cache продолжает переиспользовать старые layers, даже “новый” image может не содержать patched package, если build process не заставляет refresh.
Это особенно актуально для организаций, где есть:
- много microservices;
- несколько internal base images;
- долгоживущие container tags;
- медленные image promotion pipelines;
- production workloads, pinned к immutable digests;
- раздельная ownership у platform- и application-команд.
Эксплойт может быть patched upstream, но vulnerable layer может оставаться похороненным под вашим приложением, как проклятый артефакт.
Kubernetes не очищает старые workloads автоматически#
В Kubernetes patching — это не одно действие. Нужно думать как минимум о трёх поверхностях:
- Node OS packages — Linux hosts, на которых работают kubelet и container runtime.
- Container images — filesystem и packages внутри ваших application containers.
- Running pods — workloads, которым может понадобиться restart или redeploy, чтобы подхватить rebuilt images.
Обновление base image в registry не обновляет pods, которые уже запущены со старого image digest. Обновление nodes не обязательно обновляет application containers. Rebuild image не имеет значения, если deployment manifests всё ещё указывают на старый digest.
Именно поэтому cloud-native patching должен включать rollout verification, а не только package updates.
Что командам делать сейчас#
Не усложняйте первый response. Отнеситесь к этому как к проблеме patch propagation. Ваша цель — доказать, что patched Linux components существуют не только в repositories, но и в runtime.
1. Patch Linux hosts#
Начните с очевидного слоя: hosts, VMs и nodes.
Примените security updates через ваш стандартный package manager, проверьте необходимость reboot и убедитесь, что обновления действительно применились на всех relevant systems. Для cloud fleet это значит проверить не только новые instances, но и уже работающие nodes.
2. Обновите base images#
Найдите base images, от которых зависят ваши services: distro images, runtime images и internal golden images. Обновите их, пересоберите downstream images и отключите build cache там, где он может удерживать старые layers.
3. Пересоберите и redeploy workloads#
Rebuild сам по себе недостаточен. Убедитесь, что production deployments используют новые image digests, а старые pods, containers и long-running jobs были перезапущены.
4. Проверьте templates, snapshots и CI runners#
VM templates, autoscaling images, CI runner images и internal registries часто забывают в patch cycles. Но именно они могут снова и снова создавать fresh-looking systems со старой vulnerable базой.
5. Зафиксируйте доказательство#
Команде нужен не только список выполненных действий, но и evidence: какие versions стоят на hosts, какие image digests задеплоены, какие templates обновлены и какие workloads перезапущены.
Главное#
Copy Fail уже patched, и это хорошая новость. Но для cloud-команд настоящий риск — не отсутствие fix, а задержка между fix upstream и реальным обновлением runtime.
Если у вас есть старые Linux images, cached container layers, VM templates или Kubernetes workloads, которые не проходили rebuild и redeploy после patch, считайте их подозрительными, пока не доказано обратное.