Как стать автором
Обновить

Выбираем базовые образы для приложений на .NET: минимум уязвимостей, максимум быстродействия

Уровень сложностиСредний
Время на прочтение14 мин
Количество просмотров4.6K
Всего голосов 33: ↑33 и ↓0+35
Комментарии6

Комментарии 6

Разрешите побыть адвокатом дьявола :)

50-метровый образ в проде - круто. 0 уязвимостей на сканере - круто

Но

  1. это 50 метров - это на hello world. В жизни размер приложения с либами несколько сотен метров. иногда до гигабайта (у нас в основном java+springboot). И размер образа не так важен, как размер последнего часто меняющегося слоя

  2. мы оптимизируем количество срабатываний сканера. А платим за это тем, что тестируем не тот дистрибутив, который будет в проде.

Вы правы, дело не в сокращении размера образа на несколько десяток мегабайт. Надо уменьшать количество компонентов в образе, которые не использует приложение, но которыми могут воспользоваться злоумышленники.

Приведу пример: в одной из библиотек приложения есть уязвимость RCE (удаленное выполнение кода). С установленными в контейнере утилитами, менеджером пакетов не составит труда снять дамп памяти вашего процесса и отправить его на удаленный сервер для последующего анализа. С другой стороны если в контейнере есть только рантайм и ваше приложение вектор атаки сильно сокращается.

Какого рода эти уязвимости, реально ли вообще ими воспользоваться ?

Если мы говорим о образах с .NET, то MS оперативно выпускает новые версии базовых образов с исправлениями и интересного на данный момент нет.

Но я просканировал образ, которые собирал более года назад (на основе последней доступной версий mcr.microsoft.com/dotnet/aspnet ) и нашел несколько интересных уязвимостей, которые потенциально могут привести к DoS или влиять на безопасность:

  • CVE-2023-36799 - A vulnerability exists in .NET where reading a maliciously crafted X.509 certificate may result in Denial of Service. This issue only affects Linux systems.

  • CVE-2023-4911 - buffer overflow in ld.so leading to privilege escalation

  • CVE-2023-36054 - krb5: Denial of service through freeing uninitialized pointer

  • CVE-2018-8292 - .NET Core: information disclosure due to authentication information exposed in a redirect

  • CVE-2023-36558 - ASP.NET Security Feature Bypass Vulnerability in Blazor forms

Любая зависимость и любая уязвимость усложняют жизнь. Даже если ими не реально воспользоваться, надо тратить время на ручной или полуручной анализ и обоснование этого. В некоторых отраслях мы это делаем «для себя», а в некоторых это может быть основанием для написания формальных документов и отдельное согласование с ИБ.

Упрощает дело анализ по категориям — отметаем все узявимости, которые имеют вектор атаки в доступом к USB на основании того, что средство контейнеризации и контроль физического доступа исключают этот вектор атаки и т.д., но все равно это время и расходы.

Чем меньше уязвимостей показывает сканер, тем лучше с точки зрения и реальной безопасности, и работы со службами ИБ и их требованиями.

В свое время тоже интересовался этой темой. Для AOT hello-world получил такой результат (PublishAot, StaticallyLinked, scratch):

REPOSITORY                      TAG         IMAGE ID      CREATED        SIZE
localhost/dotnet-web-slim       latest      19c432d03ca3  2 minutes ago  11.3 MB
localhost/dotnet-web            latest      a089d676d3fb  7 minutes ago  18.1 MB

Для редхатовского ubi-micro такой (PublishSingleFile, PublishTrimmed):

REPOSITORY                       TAG         IMAGE ID      CREATED         SIZE
localhost/dotnet-web-ubi-micro   latest      51b29cdc96cb  3 seconds ago   57.4 MB
Зарегистрируйтесь на Хабре, чтобы оставить комментарий