LINUX.ORG.RU
ФорумTalks

Математика учета времени

 , ,


0

3

По сообщению cnet.com в OS X найден баг у комманды sudo засчет перестановки даты на начало времен: первое января 1970. Суть бага: в течении 10 минутного промежутка времени с момента успешной аутентификации sudo можно запускать комманды без аутентификации. В то время как время установлено на начало времен данная проверка приводит к успешному результату. Баг работает в версиях OS X 10.7-10.8.4, CVE-2013-1775

Поскольку в мак ос икс установка времени не требует привилегированных прав данная уязвимость имеет место быть. За отсутствие аналогичного поведения настроек даты и времени в DE Линус Торвальдс критиковал комманду Gnome (дочка не могла без прав root изменить дату и допекла папу):

So here's a plea: if you have anything to do with security in a distro, and think that my kids (replace «my kids» with «sales people on the road» if you think your main customers are businesses) need to have the root password to access some wireless network, or to be able to print out a paper, or to change the date-and-time settings, please just kill yourself now. The world will be a better place.

★★★★★

Последнее исправление: gh0stwizard (всего исправлений: 2)

Ответ на: комментарий от next_time

10 секунд != 10 минут

passwd_timeout Number of minutes before the sudo password prompt times out, or 0 for no timeout. The timeout may include a fractional component if minute granularity is insufficient, for example 2.5. The default is 5.

не благодари.

emulek
()
Ответ на: комментарий от geekless

ты не понял: почти любой *nix командой можно сделать почти всё что угодно.

Упомянутые vim&sed так вообще являются Тьюринг полными ЯП. find тоже в деле «найти что угодно и удалить что угодно» специализируется. Т.ч. делать именно rm нет никакой необходимости. find даже удобнее.

По большому счёту можно только какой-то особый скрипт разрешать, причём желательно вообще без всяких параметров.

emulek
()
Ответ на: комментарий от emulek

в третьих, если я имею право действовать от имени XXX, и я это доказал, то надо быть идиотом, что-бы требовать это доказательство через 10 секунд и от меня же.

Просветите по этому поводу, разве зловред не может перехватить пароль таким образом, и параллельно запустить скрытую сессию, в которой используя перехваченный пароль, зловред успешно авторизуется и будет делать свои тёмные делишки?

Ну или просто каким-то образом подстраиваться под существующую сессию, или ссылаться на неё.

Ну например, я использовал команду «sudo rm /tmp/file», команда выполнена, а дальше зловред в этой же сессии запускает то самое «эрэм эрэф». Такая ситуация возможна, или используются какие-то инструменты для защиты сессии, уникальные номера соединений и прочее?

Или вообще, переслать какие-то данные в терминал, в котором недавно использовали sudo?

ekzotech ★★★★
()
Ответ на: комментарий от emulek

Это ты не понимаешь, потому что не умеешь читать маны.

Правило emulek ALL=(root) NOPASSWD: /usr/bin/tail -f /var/log/everything.log позволит тебе выполнять без ввода пароля только команду /usr/bin/tail -f /var/log/everything.log, только её, и ничего больше. Тьюринг-полное бла-бла-бла.

geekless ★★
()
Ответ на: комментарий от Reset

И удобно (пароль не надо вводить) и подменить в принципе не возможно.

Ты сидишь под учёткой админа?

А про подменить - хз, я 2 раза на ровном месте ловил хитрого зловреда (сидя под учёткой простого пользователя, админская запаролена) который не прося пароль (т.е. не запуская UAC) умудрялся записать себя в реестр и ещё продублировать в некоторых местах в домашней папке.

И после ребута стандартный набор - неработающий regedit, неработающий диспетчер задач и прочее.

ekzotech ★★★★
()
Ответ на: комментарий от ekzotech

Так суть-то не в том, какие там могут быть уязвимости в винде у этого механизма, а в том, что нам вообще говоря нужен механизм, чтобы повысить права процесса после подтверждения пользователя. Если пользователь УЖЕ аутентифицирован, то просить пароль — избыточно. А вот просто спросить в таком окне, на которое не сможет повлиять злоумышленник — это ок.

geekless ★★
()
Ответ на: комментарий от x3al

Лучше, чем лишние SUID-бинарники, доверяющие внешним файлам

ох... Тебе хоть 33 года исполнилось?

А ещё злоумышленник может заюзать fork bomb. Кто ему даст права на запись в per-user сокет? В идеале, конечно, это делается в пользовательском неймспейсе (man pam_namespace), но крупные дистрибутивы не спешат внедрять это.

нет такого мануала.

Эмм. Кто сказал, что демон один? Да и он не обязан быть запущенным всё время, только указанное в конфиге же.

ладно, форкай sudo, в 33 демона, а я поржу, кому, кроме тебя ЭТО будет нужно.

ЗЫЖ хоть определись, что за хрень ты тут предлагаешь...

emulek
()
Ответ на: комментарий от ekzotech

Ты сидишь под учёткой админа?

Нет.

который не прося пароль (т.е. не запуская UAC) умудрялся записать себя в реестр и ещё продублировать в некоторых местах в домашней папке.

Пользователь имеет права для записи в собственную ветку реестра и в свою домашнюю директорию. При чем тут UAC?

Reset ★★★★★
()
Ответ на: комментарий от Reset

Ога, один раз набрал, а потом не заметил как sudo пролез во вредоносном скрипте. Всё таки ничего лучше UAC пока не изобрели. И удобно (пароль не надо вводить) и подменить в принципе не возможно.

а расскажешь, почему «не возможно»? Не, я не троллю, вправду не понимаю.

emulek
()
Ответ на: комментарий от emulek

а расскажешь, почему «не возможно»? Не, я не троллю, вправду не понимаю.

Допустим, авторизация для доступа к фиче выполняется через пароль. Если злоумшленник каким-либо образом узнает или подберёт пароль, он получает полный доступ к фиче. Например, он может показать фейковой окно, неотличимое от окна gksudo, и украсть пароль.

В винде устроено иначе.

Пользователю показывается окно с предложением подтвердить или отклонить авторизацию доступа к фиче. Никакой процесс не может нажать в этом окне кнопку «да» вместо пользователя. Реализация оконной системы гарантирует это. (Как именно гарантирует — не помню подробностей. Уже много лет с архитектурой винды не приходилось сталкиваться.)

Таким образом, нажать кнопку «да» может только пользователь, и если она нажата, система точно знает, что это действительно разрешение от человека.

Поскольку пользователь не вводит никаких паролей, злоумышленнику нет смысла подделывать окно авторизации с целью показать пользователю. Ничего полезного для себя он не узнает.

geekless ★★
()
Ответ на: комментарий от Reset

Пользователь имеет права для записи в собственную ветку реестра и в свою домашнюю директорию. При чем тут UAC?

В секцию автозапуска? «Пользователь» может и имеет. А вот процессы, не авторизованные пользователем для модификации этой ветки, иметь права менять её не должны.

geekless ★★
()
Ответ на: комментарий от Reset

Пользователь имеет права для записи в собственную ветку реестра и в свою домашнюю директорию. При чем тут UAC?

А запись в RUN? И потом, как из собственной ветки реестра приложение может блокировать системные? Как я понимаю, заблокировать запуск диспетчера задач может только системный процесс, или процесс, запущенный от админа. Нет?

ekzotech ★★★★
()
Ответ на: комментарий от geekless

Никакой процесс не может нажать в этом окне кнопку «да» вместо пользователя. Реализация оконной системы гарантирует это. (Как именно гарантирует — не помню подробностей. Уже много лет с архитектурой винды не приходилось сталкиваться.)

Вроде как все окна блокируются и замирают, т.е. видео «замерзает», хотя звук продолжает идти.

Но что это абсолютно исключает возможность нажатия этой кнопки программой - я не знал, или знал, но забыл =)

ekzotech ★★★★
()
Ответ на: комментарий от ekzotech

Вроде как все окна блокируются и замирают, т.е. видео «замерзает», хотя звук продолжает идти.

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

geekless ★★
()
Ответ на: комментарий от ekzotech

Просветите по этому поводу, разве зловред не может перехватить пароль таким образом

не может. Сами иксы работают с правами рута, а зловред работает с правами юзера. Потому иксы читают пароль прямо с клавиатуры. Причём пароль не выводится на экран, а значит зловред не может прочитать его с экрана. Далее пароль поступает на /dev/pts/0, который AFAIK эмулируется иксами. Далее sudo проверяет свой stdin, который должен быть /dev/pts/0, а не какой-то файл. Сама sudo тоже работает от рута, потому вытянуть оттуда пароль не представляется возможным.

Возможно в этой схеме и есть дыра, но я как-то не нашёл. Кейлоггеры есть, но у них УЖЕ должны быть права рута.

и параллельно запустить скрытую сессию, в которой используя перехваченный пароль, зловред успешно авторизуется и будет делать свои тёмные делишки?

sudo проверит, откуда ей посылают данные. К тому же вредонос не знает пароль.

Ну например, я использовал команду «sudo rm /tmp/file», команда выполнена, а дальше зловред в этой же сессии запускает то самое «эрэм эрэф». Такая ситуация возможна, или используются какие-то инструменты для защиты сессии, уникальные номера соединений и прочее?

ну наверное там есть какая-то терминалоспецифичная кука.

На самом деле, вопрос в другом: почему _тебе_ нельзя удалить rm /tmp/file? Если ты его сделал, то право у тебя есть. Если не ты, то пусть удаляет та хрень, которая сделала этот файл.

Конечно sudo это костыль, и через неё нельзя всё делать, что нужно, и что не нужно. Есть нормальные политики доступа.

emulek
()
Ответ на: комментарий от geekless

Это ты не понимаешь, потому что не умеешь читать маны. Правило emulek ALL=(root) NOPASSWD: /usr/bin/tail -f /var/log/everything.log позволит тебе выполнять без ввода пароля только команду /usr/bin/tail -f /var/log/everything.log, только её, и ничего больше.

да знаю я это всё. И про параметр «» тоже знаю. Вот только смысла в команде /usr/bin/tail -f /var/log/everything.log нет никакого: проще включить себя и процесс пишущий /var/log/everything.log в какую-нибудь группу. В данном случае для процесса это должна быть init группа, а для тебя просто группа. Тогда процесс может ставить права для группы ro, что-бы ты мог только читать. Это будет более безопаснее, чем права рута. Даже для tail. Ты уверен, что в tail нет никаких переполнений буфера и т.д.? А в inotify? Код там большой, запутанный, и никто (кроме тебя) не запускает этот код от кого угодно с привилегиями рута.

emulek
()
Ответ на: комментарий от emulek

не может. Сами иксы работают с правами рута, а зловред работает с правами юзера. Потому иксы читают пароль прямо с клавиатуры. Причём пароль не выводится на экран, а значит зловред не может прочитать его с экрана. Далее пароль поступает на /dev/pts/0, который AFAIK эмулируется иксами. Далее sudo проверяет свой stdin, который должен быть /dev/pts/0, а не какой-то файл. Сама sudo тоже работает от рута, потому вытянуть оттуда пароль не представляется возможным.

Я даже не знаю, в какой именно ман ткнуть тебя носом, столько чуши ты понаписал.

Возможно в этой схеме и есть дыра, но я как-то не нашёл. Кейлоггеры есть, но у них УЖЕ должны быть права рута.

Самая главная дыра этой схемы заключается в том, что в реальности всё устроено абсолютно иначе, чем твоих фантазиях абзацем выше.

geekless ★★
()
Ответ на: комментарий от ekzotech

Просветите по этому поводу, разве зловред не может перехватить пароль таким образом

Может. Весь иксовый ввод доступен всем подключенным клиентам. Если зловред работает с правами твоей учётки, это автоматически означает, что он слышит всё, что ты вводишь в иксах и видит содержимое всех твоих окон, а также может посылать любой ввод в любое окно.

Энжой ёр десктоп линукс.

geekless ★★
()
Последнее исправление: geekless (всего исправлений: 1)
Ответ на: комментарий от emulek

не может. Сами иксы работают с правами рута, а зловред работает с правами юзера. Потому иксы читают пароль прямо с клавиатуры. Причём пароль не выводится на экран, а значит зловред не может прочитать его с экрана. Далее пароль поступает на /dev/pts/0, который AFAIK эмулируется иксами. Далее sudo проверяет свой stdin, который должен быть /dev/pts/0, а не какой-то файл. Сама sudo тоже работает от рута, потому вытянуть оттуда пароль не представляется возможным.

В иксах есть дырка. Конкретнее — XQueryKeymap() не требует прав рута, требуется в нескольких легитимных случаях и им можно слушать пароли. Готовая реализация — xspy, ей дофига лет (гитхаб — зеркало) и все о ней знают.

Все грабы не спасают от XQueryKeymap, о чём девелоперы иксов в курсе и дружно заявляют notabug.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Все грабы не спасают от XQueryKeymap, о чём девелоперы иксов в курсе и дружно заявляют notabug.

Пока с десяток зловредов не устроят эпидемию[1], никто не пошевелится. А когда устроят, вдруг окажется, что вместо notabug в трекере уже готовы наложить патч на 5 строчек, запрещающий XQueryKeymap при активном грабе. Как всегда в этой нашей опенсорсе, короче.

[1] Если иксы будут к тому времени живы, конечно.

geekless ★★
()
Ответ на: комментарий от geekless

Если пользователь УЖЕ аутентифицирован, то просить пароль — избыточно. А вот просто спросить в таком окне, на которое не сможет повлиять злоумышленник — это ок.

1. разве в венде нет Over9000 программ, которые нажимают любые кнопки в любых окошках?

2. ну скачал я программу, но спросил мну UAC, ну я согласился(а зачем качал), и что дальше? Зачем этой программе права рута и пароль пользователя? Она и без них всесильна.

3. пароль в sudo нужен для sudo. Именно sudo определяет, КТО её запускает, т.к. скрипты не умеют эмулировать клавиатуру.

emulek
()
Ответ на: комментарий от x3al

Передай привет своим ментейнерам.

у меня всего один. И вот что он тебе ответил:

«I think a better name for PAM might be SCAM, for Swiss Cheese Authentication Modules, and have never felt that the small amount of convenience it provides is worth the great loss of system security. We miss out on half a dozen security problems a year by not using PAM, but you can always install it yourself if you feel that you're missing out on the fun. (No, don't do that)»

Patrick.

emulek
()
Ответ на: комментарий от emulek

1. разве в венде нет Over9000 программ, которые нажимают любые кнопки в любых окошках?

Купи букварь, ты не умеешь читать.

Никакой процесс не может нажать в этом окне кнопку «да» вместо пользователя. Реализация оконной системы гарантирует это.

Так лучше видно?

Именно sudo определяет, КТО её запускает, т.к. скрипты не умеют эмулировать клавиатуру.

Да ты чо? И xterm-а не существует? Или он не «эмулирует клавиатуру» древнего аппаратного терминала?

2. ну скачал я программу, но спросил мну UAC, ну я согласился(а зачем качал), и что дальше? Зачем этой программе права рута и пароль пользователя? Она и без них всесильна.

Мы говорим не том, «зачем программе повышенные привелегии», а о том, как контроллировать их повышение. Под линуксом контроль выполняется через жопу. В винде он сделан правильно.

geekless ★★
()
Ответ на: комментарий от Reset

Пользователь имеет права для записи в собственную ветку реестра и в свою домашнюю директорию. При чем тут UAC?

а при чём тут «безопасность»? Если вирус пропишется в авто загрузку, отправит куда надо ЦП, выложит для всех мою порнуху, удалит все мои файлы, и сделает ещё много интересных вещей?

emulek
()
Ответ на: комментарий от emulek

1. Есть, но для того, чтобы нажать хоть что-то в elevated-окне (дефолтные права — medium/low, необходимые — high), нужно быть elevated (или драйвером, что неспортивно, требует валидной подписи и геморроя с установкой). Очевидно, что UAC-диалог — elevated.

http://msdn.microsoft.com/en-us/library/bb625963.aspx если нечего делать, но тут это оффтоп. И вообще, mandatory integrity control — это MAC, в десктопных дистрибутивах он, как правило, не используется (а SELinux все выключают).

x3al ★★★★★
()
Ответ на: комментарий от emulek

Вся соль в том, что дефолтные права для скачанного неподписанного бинарника — low. С ними есть доступ в специальную песочницу где-то внутри ~ и специальную ветку реестра. Всё взаимодействие (в том числе и с такими же ограниченными бинарниками) запрещено. И да, в оффтопике 2 браузера дефолтно работают именно с такими правами, при этом у них нет видимых юзеров проблем (скачивание/загрузка файлов юзером вполне себе работают как обычно).

x3al ★★★★★
()
Ответ на: комментарий от geekless

Допустим, авторизация для доступа к фиче выполняется через пароль. Если злоумшленник каким-либо образом узнает или подберёт пароль, он получает полный доступ к фиче. Например, он может показать фейковой окно, неотличимое от окна gksudo, и украсть пароль.

у тебя какие-то дикие понятия о безопасности. ЯННП.

Пользователю показывается окно с предложением подтвердить или отклонить авторизацию доступа к фиче. Никакой процесс не может нажать в этом окне кнопку «да» вместо пользователя. Реализация оконной системы гарантирует это. (Как именно гарантирует — не помню подробностей. Уже много лет с архитектурой винды не приходилось сталкиваться.)

я даже не знаю, КАК гарантирует, за то знаю про Over9000 программ, которые эти «гарантии» успешно обходят. Т.е. возможно uac и не обойдут, а толку-то? Ну скачаю я и запущу xyz.exe, откуда я знаю, что это вредоносное ПО?

Поскольку пользователь не вводит никаких паролей, злоумышленнику нет смысла подделывать окно авторизации с целью показать пользователю. Ничего полезного для себя он не узнает.

да ему и знать ничего не нужно. Можно прямо взять, и уе...

emulek
()
Ответ на: комментарий от emulek

ЯННП.

Это твоё обычное состояние, не переживай. Не всем дано быть умными.

я даже не знаю, КАК гарантирует, за то знаю про Over9000 программ, которые эти «гарантии» успешно обходят. Т.е. возможно uac и не обойдут, а толку-то? Ну скачаю я и запущу xyz.exe, откуда я знаю, что это вредоносное ПО?

Ок, будем повторять каждую реплику два раза. Чтобы лучше доходило.

Мы говорим не том, «зачем программе повышенные привелегии», а о том, как контроллировать их повышение. Под линуксом контроль выполняется через жопу. В винде он сделан правильно.

geekless ★★
()
Ответ на: комментарий от geekless

Ничего страшного, XP-софт зачастую работает. А попытки писать конфиги в Program Files и прочие нехорошие места прозрачно перехватываются и направляются в ~\AppData\Local\VirtualStore.

x3al ★★★★★
()
Ответ на: комментарий от emulek

которые эти «гарантии» успешно обходят ... uac и не обойдут

/0

Reset ★★★★★
()
Ответ на: комментарий от geekless

В секцию автозапуска? «Пользователь» может и имеет. А вот процессы, не авторизованные пользователем для модификации этой ветки, иметь права менять её не должны.

т.е. regedit.exe может, а virus.exe не может? А отличает это libastral.dll?

emulek
()
Ответ на: комментарий от emulek

Отличает нажатие кнопочки «повысить программе права».

geekless ★★
()
Ответ на: комментарий от geekless

Самая главная дыра этой схемы заключается в том, что в реальности всё устроено абсолютно иначе, чем твоих фантазиях абзацем выше.

но как именно — власти скрывают.

emulek
()
Ответ на: комментарий от geekless

Может. Весь иксовый ввод доступен всем подключенным клиентам. Если зловред работает с правами твоей учётки, это автоматически означает, что он слышит всё, что ты вводишь в иксах и видит содержимое всех твоих окон, а также может посылать любой ввод в любое окно. Энжой ёр десктоп линукс.

пруф?

emulek
()
Ответ на: комментарий от emulek

но как именно — власти скрывают.

Гугл в помощь. Я на форумах не писал херни, как это ты делаешь, а читал умные книжки. Книжки, статьи, маны. И до сих пор читаю каждый день.

geekless ★★
()
Ответ на: комментарий от emulek

т.е. regedit.exe может, а virus.exe не может? А отличает это libastral.dll?

На каждом скачанном файле висит метка, что он untrusted. Её вешает скачивающий софт.

x3al ★★★★★
()
Ответ на: комментарий от geekless

Система может отличить скачанный файл от скомпилированного на ПК? А с учётом того, что метки ставятся далеко не на одни .exe, проблема ещё шире.

x3al ★★★★★
()
Ответ на: комментарий от x3al

Просто надо не доверять никому. :)

regedit.exe имеет цифровую подпись, ему доверять можно.

geekless ★★
()
Ответ на: комментарий от x3al

notabug (:

PS: да. работает до сих пор. Нефиг всякую гадость непонятную запускать...

emulek
()

Тред не читал, но вроде аналогичная новость была про линукс где-то год назад. Тоже судо и тоже сдвиг времени. Один в один. Что, тогда на маке никто не проверил ?!

RiD
()
Ответ на: комментарий от next_time

всё правильно: таймаута либо нет вообще, либо он в минутах

passwd_timeout Number of minutes before the sudo password prompt times out, or 0 for no timeout. The timeout may include a fractional component if minute granularity is insufficient, for example 2.5. The default is 5.

перевод нужен что-ли слова «fractional»?

emulek
()
Ответ на: комментарий от emulek

Червь Морриса. Первый *nix червь. После которого народ задумался о безопасности. Вообще, *nix системы проектировались без учета безопасности вообще, тогда просто не существовало такого понятия. Первые костыли, которые повышают безопасность в ядро линукс стали закладывать в 200х (ога, selinux и apparmor), но говорить о том, что у «меня *nix и поэтому я в безопасности» это бред полный. Факт в том, что сейчас десктопная винда защищена гораздо лучше и она уже готова отражать атаки, чего нельзя сказать о линуксе, который на десктопе пока даже и не был.

Reset ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.