locally-exploitable vulnerabilities

Не интересно

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

где-то такое уже было

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.»

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

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

Ясно.

GuixSD

in every modern Linux distro

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

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

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

Конечно не виноват. Это всё кривой си.

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

Да на джаве его сразу.

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

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

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

obligatory

https://www.youtube.com/watch?v=tas0O586t80

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

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

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

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

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

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

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

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

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

Та вы все просто завистники и хейторы.

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

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

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

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

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

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

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

И 2008 года :)

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

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

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

Он один в один

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

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

Если по сути, для сферического локалхоста 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:*

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

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

:)))

Можно на 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 напрямую, но так читать удобнее.

locally-exploitable vulnerabilities

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

Ява не компилируется.

Так а что не так с тегами?

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

systemd запустить

Уязвимость 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).

Не интересно

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

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

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

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

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

А дальше?

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

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

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

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

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

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

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

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

Ну вот и расходимся.

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

TL;DR.

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

ШЕРЕТО!

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

which is in every shitty Linux distro

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