Seccomp в K8s 2/3: обходы и брейкауты
В другом посте я в основном описывал операционную нагрузку от ведения seccomp-профилей и описывал сценарии, где профиль может быть не таким эффективным, как мы думаем. Это тот пост, где я хотел вернуться к взгляду атакующего. У вас есть контейнер. Seccomp включён. Профиль выглядит разумно - нет bpf, нет ptrace, сетевые syscalls ограничены. Что делаем?
Пока я собирал это исследование, я понял, что есть немало ситуаций, где seccomp-фильтр можно обойти. Они делятся на несколько категорий:
- Путаница с архитектурами - вызов заблокированных syscalls через альтернативные ABI или архитектуры CPU, на которые вы не рассчитывали (разбирать не буду: либо очевидно, либо митигация уже есть)
- Кривая настройка профиля - seccomp технически активен, но профиль разрешает больше, чем задумывалось (режим privileged, загрязнение наследованием от runtime, опасные правила, завязанные на capabilities)
- Семантика применения - злоупотребление разницей между SCMP_ACT_KILL (поток) и SCMP_ACT_KILL_PROCESS, или SCMP_ACT_LOG, чтобы прощупать фильтр и не умереть
- Мультиплексирование syscalls - один разрешённый syscall делает работу многих заблокированных.
Дальше поговорим про мультиплексирование. Давайте встанем на место атакующего, у которого RCE в окружении. Давайте даже допустим, что контейнер запущен с CAP ADD ALL, ему выданы все capabilities, и по факту это уже не контейнер. И посмотрим, сможем ли мы обойти seccomp.
https://telegra.ph/Seccomp-v-K8s-23-obhody-i-brejkauty-09-30
#ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers
В другом посте я в основном описывал операционную нагрузку от ведения seccomp-профилей и описывал сценарии, где профиль может быть не таким эффективным, как мы думаем. Это тот пост, где я хотел вернуться к взгляду атакующего. У вас есть контейнер. Seccomp включён. Профиль выглядит разумно - нет bpf, нет ptrace, сетевые syscalls ограничены. Что делаем?
Пока я собирал это исследование, я понял, что есть немало ситуаций, где seccomp-фильтр можно обойти. Они делятся на несколько категорий:
- Путаница с архитектурами - вызов заблокированных syscalls через альтернативные ABI или архитектуры CPU, на которые вы не рассчитывали (разбирать не буду: либо очевидно, либо митигация уже есть)
- Кривая настройка профиля - seccomp технически активен, но профиль разрешает больше, чем задумывалось (режим privileged, загрязнение наследованием от runtime, опасные правила, завязанные на capabilities)
- Семантика применения - злоупотребление разницей между SCMP_ACT_KILL (поток) и SCMP_ACT_KILL_PROCESS, или SCMP_ACT_LOG, чтобы прощупать фильтр и не умереть
- Мультиплексирование syscalls - один разрешённый syscall делает работу многих заблокированных.
Дальше поговорим про мультиплексирование. Давайте встанем на место атакующего, у которого RCE в окружении. Давайте даже допустим, что контейнер запущен с CAP ADD ALL, ему выданы все capabilities, и по факту это уже не контейнер. И посмотрим, сможем ли мы обойти seccomp.
https://telegra.ph/Seccomp-v-K8s-23-obhody-i-brejkauty-09-30
#ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers