How to Crash Systemd in One Tweet

HUP cikkturkáló

The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

After running this command, PID 1 is hung in the pause system call. You can no longer start and stop daemons. inetd-style services no longer accept connections. You cannot cleanly reboot the system. The system feels generally unstable (e.g. ssh and su hang for 30 seconds since systemd is now integrated with the login system).

https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet

  • 3810 megtekintés

( WG | 2016. 09. 29., cs – 14:11 )

# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
Failed to notify init system: No such file or directory
# uname -a
Linux opensuse 4.7.5-1.gc7aed11-default #1 SMP PREEMPT Sat Sep 24 11:41:43 UTC 2016 (c7aed11) x86_64 x86_64 x86_64 GNU/Linux

A hiba az én készülékemben van?

A systemctl --version mit mond? A 209 fölöttiek érintettek.
Pl. 219-es verziójú redhat 7.1-nél van ilyen file, és ki is lehet kényszeríteni a hibát.
A 7.0 esetén még nincs notify file (systemd version 208), így a hiba sem érinti.

A 210 hibás verzió. A redhat systemd 209-nél csak így sikerült előcsikarni, előfordulhat, hogy nem fog menni elsőre:
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done

Edit:
Lentebb is írták, hogy az openSuse esetén nincs notify file, a socket file hiányában nem lehet előidézni a hibát, ill. ezzel a módszerrel biztos nem.

( istju | 2016. 09. 29., cs – 17:19 )

Sziasztok.
Ez csak vaklárma, vagy a rendszeresen frissített rolling disztrókat nem érinti.
Vagy az én gépem is rossz:-)

19:12:52istju ~ $ NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
19:13:33istju ~ $ uname -a
Linux arch 4.7.4-1-ARCH #1 SMP PREEMPT Thu Sep 15 15:24:29 CEST 2016 x86_64 GNU/Linux
19:13:49istju ~ $ systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
19:14:24istju ~ $

Superuserként:
[root@arch istju]# NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
[root@arch istju]# systemctl --version
systemd 231
+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN
[root@arch istju]#

( szegecs | 2016. 09. 29., cs – 18:10 )

Vigyázat, aki nem tud angolul az ne kísérletezzen vele!

Akkor idézek, és fordítok neked:
"The following command, when run as any user, will crash systemd:

NOTIFY_SOCKET=/run/systemd/notify systemd-notify "" "

Tehát: "A következő parancsot ha futtatja bármely elhasználó a systemd összeomlik(tehát nem működik tovább)"
Párszor leírtam, hogy a rendszeremen a leírt parancs (másolva szőröstül bőröstül, persze # jel nélkül:-)) nem okoz systemd problémát. Az egy más kérdés, hogy kardinálisan tiltakozom a systemd bevezetése ellen, és terveztem egy sysvinit rendszerre történő visszaállást, (ami lehetséges) de ezt nem tettem meg, mert nem okozott nekem eddig nagy problémát.
Tehát, még egyszer leírom: a jelölt parancs bármilyen jogosultsággal futtatva sem okoz törést a rendszeremben.
Persze a rendszerem nem szegecselt.

Nem használok asztali környezetet. Tiling WM-el dolgozom (FrankenWm) . Az asztalom egy nem klikkelhető fekete üresség. Az eszközeim és egyéb cuccaim felhúzására (appletek és egyéb segédprogik hiányában) sajna ezt az új xart, a systemd-t használom parancssoros környezetben. Utoljára írom, hogy a topicban szereplő parancs nincs hatással az eszközeimre, se a folyamataimra. Ezek továbbra is ki, és bekapcsolhatóak maradnak a systemctl parancsmegfelelően paraméterezett kiadásával. Ha ezt nem érted meg, nagyon sajnálom. Ez a dolog nálam igaz, Arch linux alatt asztali rendszeren, és otthoni hálózatban egyaránt.

ja, mert nehéz lett volna az aki nem tud angolul kezdetű fikázásod, meg az olyan értelmetlen faszságok, mint a systemd userek szintjén való szórakozás -- miközben azt ugye leginkább a disztró dönti el, de nem baj, bizonyára mindenki hülye, aki systemdt használ -- és az egyéb masszív, zeró információt tartalmazó személyeskedésed helyett benyögni, annyit, mint pl zitev, hogy nézd már meg a cikkben, hogy nem determinisztikus, futtasd ciklusban. Nem, neked ehelyett a másik angoltudásába kell minden alap nélkül belekötni, aztán meg jönni azzal, hogy a másik csak védekező frázisokat puffogtat a stílusodról. Az barátom azért van, mert a stílusodon kívül semmit nem mondtál.

nem determinisztikus, futtasd ciklusban

Arról nem is beszélve, hogy már okafogyott, megoldották. Sőt, Fedorához az általam linkelt után jött még egy frissítés az alábbi changelog megjegyzéssel:

- Better fix for #1380286

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( SzBlackY | 2016. 09. 29., cs – 18:16 )

openSUSE Leap 43.1: 


foo@bar:~> NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""
Failed to notify init system: No such file or directory
foo@bar:~> systemctl --version
systemd 210
+PAM +LIBWRAP +AUDIT +SELINUX -IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP +APPARMOR

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Sajnos valóban nincs, mert az évek megmutatták, hogy az igazi kérdés:
"The immediate question raised by this bug is what kind of quality assurance process would allow such a simple bug to exist for over two years (it was introduced in systemd 209). Isn't the empty string an obvious test case? "
gyakorlatilag bármelyik fontos szoftverre igaz, láttuk, hogy mind tele vannak banális hibákkal, szóval sajnos valóban nincs itt semmi látnivaló, pedig jobb lenne, ha ez az lenne.

Tény, hogy ciki, s ha már egyszer kitalálták, hogy legyen systemd, mert van egy rakás feature benne a párhuzamos szolgáltatás indítástól kezdve a függőség kezelésen át az egyszerű konfigurációs file-okig, akkor viszont illene megfelelő minőségben kódolni egy ilyen alapvető komponenst, amely nélkül éppen úgy megáll a gép, mintha a kernel lenne beteg.

Azt azért hozzátenném, hogy a System V scriptjeinek biztonságossága véleményem szerint hamis biztonságérzet. Egyrészt jól el lehet azt szúrni a függőségek nehézkes kezelhetősége, helyben gányolt kezelése miatt. Valamint szerintem soha senki nem mondta, hogy a bash, vagy az a shell, amelyik ezeket a scripteket futtatja majd, hibátlan, s nem akad majd bele egy kifejezésbe. Csak, hogy alátámasszam a mondanivalómat, az utóbbi 10 napban két javítás jött Fedorához, amely a bash-t érinti:

* Fri Sep 30 2016 Siteshwar Vashisht <xxxxx@redhat.com> - 4.3.42-7
- CVE-2016-7543: Fix for arbitrary code execution via SHELLOPTS+PS4 variables
Resolves: #1379634

* Wed Sep 21 2016 David Kaspar [Dee'Kej] <xxxx@redhat.com> - 4.3.42-6
- CVE-2016-0634 - Fix for arbitrary code execution via malicious hostname
Resolves: #1377614

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Depoetterization phase 1 completed. 


# systemd -v
bash: systemd: a parancs nem található...
# openrc --version
openrc (OpenRC) 0.22.2 (Gentoo Linux)
# nm-cli
bash: nm-cli: a parancs nem található...

phase 2: pulseaudio removal - meg kell néznem, hogy milyen mélyen van beágyazva a rendszerbe.

Az eudev egyelőre megfelelő alternatívának tűnik - továbbra is net.ifnames=0-val...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."