А можно ли через docker.sock создать контейнер, в котором ФС хоста будет куда-то смонтирована?

Гипотетическая ситуация такая: у атакующего есть доступ к контейнеру, в котором смонтирован docker.sock с хоста

И как в условиях контейнеров ведут себя kernel-эксплойты, что сделать с namespace-ами, чтобы запустить свой код на хосте?

А почему нельзя? Вроде как всегда что-то монтируется - только обычно легитимное. Если атакующий получит доступ к этому управляющему сокету (rw), то считай что он с правами демона докера имеет доступ к хосту...

не было возможности проверить.

Нашел в книге по докеру сценарий с установкой jenkins с sudo без пароля и монтированием сокета, нарисовался сценарий для лр

Это, кажется, немного другое

это когда твой юзер на хосте, но в группе docker

а мы о побеге из самого контейнера

а

Я вижу 3 основных сценария: дырявое ядро, доступный для rw сокет или privileged-режим

если не рассматривать зиродеи

читал https://www.blackhat.com/docs/us-17/thursday/us-17-Cherny-Well-That-Escalated-Quickly-How-Abusing-The-Docker-API-Led-To-Remote-Code-Execution-Same-Origin-Bypass-And-Persistence_wp.pdf, но там на сети сконцентрировались

ну да, то что выше и писали, прямое управление сокетом на rw работает

>Update - After tweeting this article out @benhall pointed out that actually the ro setting on the volume mount doesn’t have a lot of effect in terms of security. An attacker with ro access to the socket can still create another container and do something like mount /etc/ into it from the host, essentially giving them root access to the host. So bottom line is don’t mount docker.sock into a container unless you trust its provenance and security

пока думал, что возникнет еще проблема переезда в новый контейнер, который ты создаешь со смонтированной фс, понял, что раз сокет доступен, то и интерактив -it /bin/bash точно так же будет работать

в доке реверс-шелл использовали

Ребят, мб я туплю, но есть ли аналог BadUSB для дисков?