ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | the owner of conf-files is reduced to lp | ||
|---|---|---|---|
| Product: | Sisyphus | Reporter: | imz <vanyaz> |
| Component: | cups | Assignee: | Anton Farygin <rider> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P4 | CC: | george, rider |
| Version: | unstable | ||
| Hardware: | all | ||
| OS: | Linux | ||
|
Description
imz
2002-07-13 13:33:20 MSD
Я тут подумал - наверное не все так гладко. Похоже cups умеет во время работы исправлять эти файлы Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание. Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть Я тут подумал - наверное не все так гладко. Похоже cups умеет во время работы исправлять эти файлы Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание. Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.) Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.) Это конечно все хорошо, но эта информация все-таки динамически меняется только при конфигурировании. Так что перенос этой конфигурации в /var не целесообразен. Это конечно все хорошо, но эта информация все-таки динамически меняется только при конфигурировании. Так что перенос этой конфигурации в /var не целесообразен. Боюсь, что скорее удасться переписать CUPS чем зафиксить это Боюсь, что скорее удасться переписать CUPS чем зафиксить это Хочу прокомментировать. Хочу прокомментировать. А если информация таки меняется только при кофигурировании, то пользователю lp не нужно владеть правами на её изменение -- ведь для конфигурации у нас специальный режим (admrestart и т.д.), при котором как раз сервер работает под root и не принимает запросов. Именно этого и хочется: чтобы ошибка в обработчике запросов на печать не могла привести к изменению конфигурационного файла не авторизованным пользователем и, как следствие, получению им прав root (через некоторое время). Запросы обрабатываются под lp, поэтому желательно, чтобы lp не имел права записи в конфигурационный файл cups. Кстати, вот пример когда этим можно было бы воспользоваться: <a href="http://www.idefense.com/advisory/12.19.02.txt">http://www.idefense.com/advisory/12.19.02.txt</a> смотрим только на Issue 1 -- можно получить shell под lp: The exploit created a set user id \'lp\' shell. While the current exploit works only against systems utilizing glibc-2.2.4-18.7.0.8, it is possible to make modifications that will make it effective against earlier glibc versions. The vulnerable code also exists in the latest version of CUPS (test platform [3]) and appears to be exploitable with slight modifications. Казалось бы, страшно, но не очень. Но так как конфигурационный файл доступен на запись lp, злоумышленник может поменять в нём свойства запуска сервера: заменить пользователя lp на пользователя root -- запросы на печать будут обрабатываться под root. И теперь, после очередного перезапуска cups ничего не заметившим администратором, повторяя те же действия получает shell под root. То, что конфигурационный файл доступен на запись lp, сильно повышает степень угрозы от возможных дырок в обработчиках заданий на печать (разные типы данных, фильтры, драйверы для принтеров). А их все проверить довольо тяжело, по-моему, были сообщения о найденных (и исправленных) дырах в них. А если информация таки меняется только при кофигурировании, то пользователю lp не нужно владеть правами на её изменение -- ведь для конфигурации у нас специальный режим (admrestart и т.д.), при котором как раз сервер работает под root и не принимает запросов. Именно этого и хочется: чтобы ошибка в обработчике запросов на печать не могла привести к изменению конфигурационного файла не авторизованным пользователем и, как следствие, получению им прав root (через некоторое время). Запросы обрабатываются под lp, поэтому желательно, чтобы lp не имел права записи в конфигурационный файл cups. Кстати, вот пример когда этим можно было бы воспользоваться: <a href="http://www.idefense.com/advisory/12.19.02.txt">http://www.idefense.com/advisory/12.19.02.txt</a> смотрим только на Issue 1 -- можно получить shell под lp: The exploit created a set user id \'lp\' shell. While the current exploit works only against systems utilizing glibc-2.2.4-18.7.0.8, it is possible to make modifications that will make it effective against earlier glibc versions. The vulnerable code also exists in the latest version of CUPS (test platform [3]) and appears to be exploitable with slight modifications. Казалось бы, страшно, но не очень. Но так как конфигурационный файл доступен на запись lp, злоумышленник может поменять в нём свойства запуска сервера: заменить пользователя lp на пользователя root -- запросы на печать будут обрабатываться под root. И теперь, после очередного перезапуска cups ничего не заметившим администратором, повторяя те же действия получает shell под root. То, что конфигурационный файл доступен на запись lp, сильно повышает степень угрозы от возможных дырок в обработчиках заданий на печать (разные типы данных, фильтры, драйверы для принтеров). А их все проверить довольо тяжело, по-моему, были сообщения о найденных (и исправленных) дырах в них. In \"non-insecure\" mode files must be available only for root. In \"non-insecure\" mode files must be available only for root. надо смотреть, проверять и доделывать cups-1.1.18-alt2 надо смотреть, проверять и доделывать cups-1.1.18-alt2 |
