Вопрос HACK NGINX+DAV. Уязвимость?

HACK NGINX+DAV
оригинал опубликован на форуме nginx: forum.nginx.org/read.php?21,271302

Обнаружил уязвимость. Надеюсь не я первый.... и уже есть таблетка.
Команда DELETE (модуля WEBDAV) исполняется мастер-процессом nginx от пользователя root. Так как по умолчанию мастер-процесс стартует от рута для доступа к портам 80 & 443 (0-1024).
root 9100 0.0 0.4 331232 7960 ? Ss 14:06 0:00 nginx: master process /usr/sbin/nginx
nginx 9101 0.1 0.9 388432 18548 ? S 14:06 0:11 nginx: worker process
nginx 9102 0.0 0.8 388164 16620 ? S 14:06 0:07 nginx: worker process
nginx 9103 0.0 0.4 331236 8676 ? S 14:06 0:00 nginx: cache manager process

Это уязвимость предоставляет внешним пользователям удалять в области доступа любые файлы и папки, вне
зависимости от владельца и прав доступа. (включая файлы созданные рутом или иным пользователем.)

Дырка обнаружена на конфигурации:
nginx version: nginx/1.7.11
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --http-client-body-temp-path=/var/lib/nginx/tmp/client_body --http-proxy-temp-path=/var/lib/nginx/tmp/proxy --http-fastcgi-temp-path=/var/lib/nginx/tmp/fastcgi --http-uwsgi-temp-path=/var/lib/nginx/tmp/uwsgi --http-scgi-temp-path=/var/lib/nginx/tmp/scgi --pid-path=/run/nginx.pid --lock-path=/run/lock/subsys/nginx --user=nginx --group=nginx --with-pcre-jit --with-debug --with-file-aio --with-ipv6 --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_xslt_module --with-http_image_filter_module --with-http_geoip_module --with-http_sub_module --with-http_dav_module --add-module=/usr/src/1/nginx-dav-ext-module-master --with-http_flv_module --add-module=/usr/src/1/f4f-hds-master --with-http_mp4_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_degradation_module --with-http_stub_status_module --with-http_perl_module --with-mail --with-mail_ssl_module --with-http_auth_request_module --add-module=/usr/src/1/echo-nginx-module-master --add-module=/usr/src/1/nginx_md5_filter-master --add-module=/usr/src/1/ngx_devel_kit-master --add-module=/usr/src/1/lua-nginx-module-master --add-module=/usr/src/1/set-misc-nginx-module-master --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' --with-ld-opt=' -Wl,-E,-rpath,/usr/local/openresty/luajit/lib'

ngx_http_dav_ext_module.c 30.05.2013

Первая мысль которая приходит в голову - это стартовать мастер-процесс nginx, как и воркеры, от пользователя nginx. Но тогда по логике демон потеряет доступ к портам 80 и 443..... или не потеряет?
Уважаемые подскажите плизззз! как дырку правильно запаять!

DAV команда MOVE так же исполняется над папками и файлами любого системного пользователя.

itcod пишет: HACK NGINX+DAVОбнаружил уязвимость. Надеюсь не я первый.... и уже есть таблетка.

Интересно было бы понять, пофиксена ли бага в актуальной версии nginx.

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

Добрый вечер уважаемые!
Выложил ролик. Кино показывает как воркеры nginx или модуль dav (якобы все с правами nginx) запросто по webdav командам MOVE DELETE переименовывают и удаляют папки владельца root. С файлами рута они почти так же "бережно" обходятся. лёгкие различия показались только с командой COPY.

"улыбаемся и машем!"(с)мадагаскар

Если кому будет интересно покопать конфиги nginx, то они тут:
itcod.com/test/2016.12.04.demo.nginxConfig/

Aleksej пишет: Интересно было бы понять, пофиксена ли бага в актуальной версии nginx.

А мне интересно в какой проге эта дырка... в самом nginx, его модулях, в сторонних модулях, в lua.... вагон вариантов пока...
Если у кого есть рабочий webdav на nginx, буду очень благодарен если повторите мой тест (как в видео) и поделитесь тут результатом.

Вы издеваетесь что ли?
Уверен что директория /opt/home/test/.TEST принадлежит не пользователю root или её права позволяют писать в неё пользователю nginx, а acl не заданы.

То что показано в виде, является стандартной реализацией базовых прав Unix:

То есть при переименовании директории, в рассмотрение берутся права родительской. При чём здесь Nginx? Он вполне работает в этой же идеологии, как и любая другая программа.
Почитайте что-нибудь про основы прав в *nix системах.

hubbitus Спасибо!!!!
Да уж.... склероз похоже меня одолел..... про рекурсию прав я даже и не вспомнил.... почему-то я её по жизни только к хоум-директориям воспринимал адекватно... век живи - век учись!

Сам дурак, зато спрашиваю и учусь
Тема закрыта.

Дураки те, кто не спрашивает и не учится. Какой выход нашли, подЕлитесь? Selinux или Apparmor? Как перекрыли дыру?