Bug 1084

Summary: the owner of conf-files is reduced to lp
Product: Sisyphus Reporter: imz <vanyaz>
Component: cupsAssignee: 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
The configuration is default (i.e. User lp).
After package installation /etc/cups/cupsd.conf is owned by root, group root (this is right).
But after \'service cups restart\' the owner is changed:

$ l /etc/cups/cupsd.conf
-rw-------    1 lp       lp          17943 Jun 18 01:00 /etc/cups/cupsd.conf

(rpm -V cups report this, too).

This is quite bad from the security point of view: theoretically, a normal user could get root\'s permissions in two steps.

The first step: find a hole in a filter that used by CUPS for processing input data before printing; this hole should allow to write to a file. (In practice, no such hole is known, but it is quite possible to exist.) Then the user forms a special request to CUPS which uses this hole to overwrite /etc/cups/cupsd.conf (it is owned by lp, and the filters are run as lp): he puts \&quot;User root\&quot; there. 

The second step: after restarting CUPS (system reboot) the new configuration is active, the filters are run as root, and it is possible to get access to any data in the system by quite simple Postscript requests (this is practically implementable, very simple; never use \&quot;User root\&quot;!). So he can read any private keys, any private data, and probably also rewrite it (since the first step succeeded). So he can get a root shell or whatever he wants.
---
apt-get remove cups
apt-get install cups
rpm -V cups
service cups restart
rpm -V cups
l /etc/cups/cupsd.conf
---
cups-1.1.15-alt2 (some previous releases also behave like this).

(I\'m making this report in order no to forget about this bug.)

As you know, CUPS is not secure at how he protects the data in the printing queue. (If you use CUPS, then the data you print can be stolen by another user without much trouble.) But that is not as bad as the described misbehavior, since that doesn\'t compromise the rest of the system.
Comment 1 inger@altlinux.org 2002-08-08 16:36:30 MSD
Я тут подумал - наверное не все так гладко.

Похоже cups умеет во время работы исправлять эти файлы

Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание.
Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть
Comment 2 inger@altlinux.org 2002-08-08 16:36:30 MSD
Я тут подумал - наверное не все так гладко.

Похоже cups умеет во время работы исправлять эти файлы

Как минимум он меняет статус принтера на Stopped на лету если с на него не удается отправить задание.
Возможно аналогичное поведение и с остальными конфигурационными файлами - я пока еще не успел посмотреть
Comment 3 imz 2002-10-05 20:09:47 MSD
Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.)
Comment 4 imz 2002-10-05 20:09:47 MSD
Это, по-моему, само по себе плохо: динамически меняющуюся информацию нужно хранить в другом месте (/var/). /etc может быть mounted read-only -- при нормальной работе, а не конфигурации системы, нет необходимости менять что-то в /etc/. (/etc/adjtime мешается, правда.)
Comment 5 inger@altlinux.org 2002-12-19 16:27:08 MSK
Это конечно все хорошо, но эта информация все-таки динамически меняется
только при конфигурировании. Так что перенос этой конфигурации в /var 
не целесообразен.
Comment 6 inger@altlinux.org 2002-12-19 16:27:08 MSK
Это конечно все хорошо, но эта информация все-таки динамически меняется
только при конфигурировании. Так что перенос этой конфигурации в /var 
не целесообразен.
Comment 7 inger@altlinux.org 2002-12-19 16:27:58 MSK
Боюсь, что скорее удасться переписать CUPS чем зафиксить это
Comment 8 inger@altlinux.org 2002-12-19 16:27:58 MSK
Боюсь, что скорее удасться переписать CUPS чем зафиксить это
Comment 9 imz 2003-01-08 00:11:48 MSK
Хочу прокомментировать.
Comment 10 imz 2003-01-08 00:11:48 MSK
Хочу прокомментировать.
Comment 11 imz 2003-01-08 00:24:39 MSK
А если информация таки меняется только при кофигурировании, то пользователю 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, сильно повышает степень угрозы от возможных дырок в обработчиках заданий на печать (разные типы данных, фильтры, драйверы для принтеров). А их все проверить довольо тяжело, по-моему, были сообщения о найденных (и исправленных) дырах в них.
Comment 12 imz 2003-01-08 00:24:39 MSK
А если информация таки меняется только при кофигурировании, то пользователю 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, сильно повышает степень угрозы от возможных дырок в обработчиках заданий на печать (разные типы данных, фильтры, драйверы для принтеров). А их все проверить довольо тяжело, по-моему, были сообщения о найденных (и исправленных) дырах в них.
Comment 13 Dmitry V. Levin 2003-01-13 17:40:20 MSK
In \&quot;non-insecure\&quot; mode files must be available only for root.
Comment 14 Dmitry V. Levin 2003-01-13 17:40:20 MSK
In \&quot;non-insecure\&quot; mode files must be available only for root.
Comment 15 inger@altlinux.org 2003-01-15 15:03:25 MSK
надо смотреть, проверять и доделывать cups-1.1.18-alt2
Comment 16 inger@altlinux.org 2003-01-15 15:03:25 MSK
надо смотреть, проверять и доделывать cups-1.1.18-alt2