Re: [devel] samba 0-day exploit

[Alexander Bokovoy <ab@altlinux.org>]

2010/2/7 Alexey Borovskoy <alb@altlinux.ru>:
> Добрый день.
>
> http://www.securityfocus.com/archive/1/509389
>
> P.S. Давайте все же слезем с неподдерживаемой ветки.
Не читайте желтую прессу. То, что там упомянуто -- не имеет отношения
к древности и неподдерживаемости ветки.

Выставьте

wide links = no
unix extensions = no

и забудьте об этой проблеме.

Подробнее прочитайте дискуссию
http://lists.samba.org/archive/samba-technical/2010-February/069183.html

Это не уязвимость, а "фича". В Самбе есть два режима, при которых можно
использовать символические ссылки в файловой системе на ресурсы: для Windows
(wide links) и для Unix (unix extensions). В первом случае разрешение ссылок в
реальные ресурсы делает сервер, во втором -- клиент.

Оба случая имеют под собой реальную основу и могут использоваться в реальной
жизни. Проблема возникает только с ситуациями, когда одновременно настроены
unix extensions и wide links.

Таким образом, для администраторов необходимо:
1. Включить unix extensions, отключить wide links,  -- для случая, когда
используются преимущественно unix-клиенты.

2. Отключить unix extensions, включить wide links -- для windows-клиентов в
этом случае будут выполняться проверки на выход за пределы текущей share и
никакая созданная клиентом символическая ссылка не сможет выйти за пределы
текущей share.

3. Отключить unix extensions, отключить wide links -- в этом случае невозможно
будет создать символическую ссылку с любого клиента.

Во всех случаях "привязывание" ресурсов за пределами текущей share правильнее
делать средствами mount -o bind.

Одновременно держать включенными обе опции смысла нет. К сожалению, это как раз
и является настройкой по умолчанию в Самбе с 2005 года.

Назвать это "уязвимостью" можно только с большой натяжкой, модифицировать для
этого smbclient вовсе не нужно -- в данном случае это показатель того, что
человек не понимает совершенно, что он делает.

Если пользователь имеет доступ по ssh на этот же сервер, то он может создать в
домашней директории символическую ссылку на что угодно, а потом разрешить эту
символическую ссылку из Windows клиента. Если используются unix extensions, то
фактически это равносильно доступу этого же клиента по ssh в смысле файловых
операций. За одним исключением -- в этом режиме символические ссылки разрешать
будет клиент, а не сервер. А переключившись на клиента, который не умеет unix
extensions, при включенном wide links, мы заставим сервер разрешить эту же
символическую ссылку -- с теми правами, под которыми зайдет пользователь (чаще
всего nobody для публичных ресурсов и с правами конкретного пользователя для
авторизованных).

Поскольку такое поведение в любом случае должно определяться ситуацией в
конкретной организации, то это вопрос настроек, применяемых администратором.
Максимум, что можно сделать с нашей (дистрибутивной) стороны -- сменить
умолчание на wide links = no, unix extensions = yes, предполагая, что будет
больше unix клиентов, либо сменить на умолчание wide links = yes, unix
extensions = no.

Я могу также добавить код, тестируемый сейчас Джереми Эллисоном,
который запрещает wide links при включении unix extensions и наоборот.
Любой взаимоисключающий (или выключающий оба режима) вариант возможен
в качестве дистрибутивного.

Хотелось бы только одного -- поменьше "веры" в то, что говорят в
желтой прессе, которой стали многие информационные бюллетени по
безопасности.
-- 
/ Alexander Bokovoy