LINUX.ORG.RU

locally-exploitable vulnerabilities

Не интересно

Polugnom ★★★★★ ()

To the best of our knowledge, all systemd-based Linux distributions are
vulnerable, but SUSE Linux Enterprise 15, openSUSE Leap 15.0, and Fedora
28 and 29 are not exploitable because their user space is compiled with
GCC's -fstack-clash-protection.


This confirms https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php:
«It should be clear that kernel-only attempts to solve [the Stack Clash]
will necessarily always be incomplete, as the real issue lies in the
lack of stack probing.»

Yorween ()

Это все косяки alloca. При чём тут systemd?

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

ваши уязвимости не уязвимости, not-a-bug, лёня бох

Ясно.

tailgunner ★★★★★ ()

GuixSD

in every modern Linux distro

Из всех modern distro systemd стоит только в NoxOS'е.

Camel ★★★★★ ()
Ответ на: GuixSD от Camel

Лови наркомана.

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

Наши уязвимости - уязвимости, так бывает, когда софт пишут на C. Бывало и хуже. systemd, естественно, не виноват, в каком-нибудь rsyslog полюбому тоже бы такое находили, если бы еще кто-то использовал =P

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

Интересно, а если переписать systemd на Swift ситуация улучшится?

Hartmann ()

Просто прогнать прект через cppcheck и сразу видны эти ворнинги про alloca, как и некоторые другие. Неужели из всех 1000+ контрибуторов этим никто не занимается?

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

в каком-нибудь rsyslog полюбому тоже бы такое находили, если бы еще кто-то использовал =P

Что, в нем не находят? Надо же. А ведь его используют.

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

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

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

Это все косяки alloca. При чём тут systemd?

alloca выделяет память на стеке. При беглом анализе systemd просто выделяет на стеке столько, сколько запросил юзер. Действительно, что могло пойти не так :D

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

Просто прогнать прект через cppcheck и сразу видны эти ворнинги про alloca, как и некоторые другие. Неужели из всех 1000+ контрибуторов этим никто не занимается?

Становится интересно, что можно будет увидеть, если прогнать через Coverity.

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

в каком-нибудь rsyslog полюбому тоже бы такое находили, если бы еще кто-то использовал =P

Полностью согласен, зачем нужен rsyslog, если есть божественный syslog-ng?

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

Полностью согласен, зачем нужен rsyslog, если есть божественный syslog-ng?

А side-by-side comparison есть? А то в rsyslogd можно сделать old-style конфиг, а в syslog-ng вроде как нельзя :)

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

А side-by-side comparison есть?

Таки есть, но не полный и неофициальный.

в rsyslogd можно сделать old-style конфиг, а в syslog-ng вроде как нельзя

В syslog-ng нельзя, но в rsyslogd он «compatible to legacy syslogd but ugly»

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

В syslog-ng нельзя, но в rsyslogd он «compatible to legacy syslogd but ugly»

Ась? Он один в один.

kirk_johnson ★★ ()

Пришла пора признать

Лёнины поделия 3/5 wouldnt bang, так если по совести.

(мой уровень если что - - hello world 10/10).

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

Он один в один

Тут проблема в том, как поддержка легаси-конфига криво реализована в rsyslog.

Если по сути, для сферического локалхоста syslog-ng подходит лучше, потому что он тупо удобнее за счет простоты в настройке и использовании.

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

Если по сути, для сферического локалхоста syslog-ng подходит лучше, потому что он тупо удобнее за счет простоты в настройке и использовании.

Не знаю, спорно. Можно на syslog-ng сделать что-нибудь подобное, чтобы не сильно длиннее было:

# Configuration file for rsyslogd(8). See rsyslog.conf(5) for details.

$ModLoad imuxsock # Provides support for local system logging (e.g. via logger command)
$ModLoad imklog   # Provides kernel logging support (previously done by rklogd)

# Use default timestamp format
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

# File syncing capability is disabled by default. This feature is usually not
# required, not useful and an extreme performance hit.
#$ActionFileEnableSync on

# Set the default log owner
$FileOwner root
$FileGroup wheel

# Include all config files in /etc/rsyslog.d
$IncludeConfig /etc/rsyslog.d/*.conf

# Log ansible messages to the separate file
:syslogtag, startswith, "ansible-"    /var/log/ansible.log
& stop

# Log private authentication messages to the separate file
$FileCreateMode 0640
auth.*                                /var/log/auth.log
authpriv.*                            /var/log/auth.log
$FileCreateMode 0644

# Per-facility log files
cron.*                                /var/log/cron.log
daemon.*                              /var/log/daemon.log
kern.*                               -/var/log/kern.log
mail.*                                /var/log/mail.log
user.*                                /var/log/user.log

# Catch-all (except for auth, authpriv, cron and mail) file
*.*;\
auth.none;\
authpriv.none;\
cron.none;\
mail.none                            -/var/log/messages

# Send emergency messages to everyone
*.emerg                               :omusrmsg:*
kirk_johnson ★★ ()
Последнее исправление: kirk_johnson (всего исправлений: 1)

TheAnonymous заголовок надо тематический делать или хотя бы теги ставить. собака под кустом тоже много чего может просто оставить.

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

Действительно, что могло пойти не так :D

:)))

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

Можно на syslog-ng сделать что-нибудь подобное

Как-то так:

@include "/etc/syslog-ng/conf.d/*.conf"

### Global options.
options { ts-format(iso); owner("root"); group("wheel"); perm(0640); };

### Sources

source src { unix-dgram("/dev/log"); internal();
       	     file("/proc/kmsg" log_prefix("kernel: "));
};

### Destinations

destination messages { file("/var/log/messages"); };
destination auth { file("/var/log/auth.log"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination mail { file("/var/log/mail.log"); };
destination user { file("/var/log/user.log"); };
destination console_all { usertty( * ); };
destination ansible { file("/var/log/ansible.log"); };


### Filters

filter crit { level(crit .. emerg); };
filter syslog { facility(syslog) and not filter(debug); };
filter auth { facility(auth, authpriv) and not filter(debug); };
filter cron { facility(cron) and not filter(debug); };
filter daemon { facility(daemon) and not filter(debug); };
filter kern { facility(kern) and not filter(debug); };
filter mail { facility(mail) and not filter(debug); };
filter user { facility(user) and not filter(debug); };
filter ansible { facility(daemon) and filter(match("ansible-")); }

### Logs

log { source(src); filter(syslog); destination(messages); };
log { source(src); filter(auth); destination(auth); };
log { source(src); filter(cron); destination(cron); };
log { source(src); filter(daemon); destination(daemon); };
log { source(src); filter(kern); destination(kern); };
log { source(src); filter(user); destination(user); };
log { source(src); filter(mail); destination(mail); };
log { source(src); filter(crit); destination(console_all); };
log { source(src); filter(ansible); destination(ansible); };

Можно сделать намного короче, подставляя filter и destination напрямую, но так читать удобнее.

otto ()

locally-exploitable vulnerabilities

Що, опять? Что на этот раз нужно сделать от рута?

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

Что на этот раз нужно сделать от рута?

systemd запустить

aplay ★★★★ ()

Уязвимость CVE-2018-16864 проявляется с апреля 2013 года (появилась в systemd 203), но пригодна для эксплуатации только после изменения, внесённого в systemd 230 в феврале 2016 года.
Уязвимость CVE-2018-16865 проявляется с декабря 2011 года (systemd 38) и доступна для эксплуатации с апреля 2013 года (systemd 201).
Проблемы CVE-2018-16864 и CVE-2018-16865 устранены несколько часов назад в master-ветке systemd.
Уязвимость CVE-2018-16866 появилась в июне 2015 года (systemd 221) и устранена в августе 2018 года (не проявляется в systemd 240).
Публикация рабочего эксплоита отложена до выпуска исправлений дистрибутивами. В настоящий момент в дистрибутивах уязвимости пока остаются неисправленными (Debian, Ubuntu, RHEL, Fedora, SUSE).

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

Не интересно

И давно локальное повышение привилегий до root перестало быть интересным?

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

теги в норме, сорри. внутри темы их просто не видно, а в списке топиков все ок.

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

не исключено, что локальный характер этой уязвимости обусловлен просто отсутствием у systemd соответствующего функционала для remote logging. =)

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

А дальше? Мне нужна конкретная инструкция, как правильно выстрелить себе в ногу, а не эти мелкие вбросики.

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

Публикация рабочего эксплоита отложена до выпуска исправлений дистрибутивами.

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

А дальше?

А дальше в ОП все описано.

Если коротко, то если есть исполнение кода от любого пользователя, у которого есть права на запись логов (/run/systemd/journal/socket) — есть возможность получить привилегии journald (т.е. root).

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

Ога, осталась только еще одна мелочь - попасть за машину физически.

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

Ога, осталась только еще одна мелочь - попасть за машину физически.

Зачем физически?

Вот тебе два готовых сценария на основе последних найденных уязвимостей:

  1. Сервер. Получается исполнение кода в gitea, после чего уязвимость из ОП используется для повышения привилегий до root и закрепления на системе.

  2. Десктоп. Отправляется письмо со вложенным SVG файлом человеку, который использует Thunderbird, после чего уязвимость из ОП используется для повышения привилегий до root и закрепления на системе.

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

А дальше в ОП все описано.

TL;DR.

Если коротко, то если есть исполнение кода от любого пользователя, у которого есть права на запись логов (/run/systemd/journal/socket) — есть возможность получить привилегии journald (т.е. root).

ШЕРЕТО!

А если серьёзно, то это не последняя подобная уязвимость. Не от Лёни, так от кого-нибудь другого. Нефиг переусложнять софт, чтобы не огребать от его поведения.

mord0d ()

which is in every shitty Linux distro

Поправил и пошел обратно к генте

upcFrost ★★★★★ ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)