Bug 1084 - the owner of conf-files is reduced to lp
: the owner of conf-files is reduced to lp
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/cups)
: unstable
: all Linux
: P4 blocker
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2002-07-13 13:33 by
Modified: 2003-08-25 15:18 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2002-07-13 13:33:20
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 \"User root\" 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 \"User root\"!). 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 From 2002-08-08 16:36:30 -------
Я тут подумал - наверное не все так гладко.

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

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

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

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