image

Linux systemd crasht met code van 48 karakters

dinsdag 4 oktober 2016, 16:32 door Redactie, 37 reacties

Slechts 48 karakters zijn genoeg om Linux systemd te laten crashen. Volgens Linux-admin Andrew Ayer is het commando: “NOTIFY_SOCKET=/run/systemd/notify systemd-notify” voldoende om het besturingssysteem te laten vastlopen.

De betreffende code veroorzaakt volgens hem een crash in systemd, een proces dat essentieel is bij het opstarten van veel Linux-distro’s. Dankzij deze code raakt de Linux identifier 1 (PID 1) in een soort pauzestand waarin het vervolgens blijft hangen. Volgens Ayer is dit commando ongeveer twee jaar geleden in systemd 209 geïntroduceerd. Hij noemt de bug serieus en heeft hem daarom als ernstig bestempeld.

De reacties zijn echter verdeeld. In een reactie laat David Strauss bijvoorbeeld weten dat hij niet zo onder de indruk is. “Niet alleen behoort dit tot het laagste risiconiveau omdat het alleen lokaal uitgevoerd kan worden en een denial-of-service genereert, maar bovenal kloppen de beweringen van Ayer niet”.

Ayer beweert bijvoorbeeld dat het systeem zal crashen, maar wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt’, aldus Strauss. Bepaalde processen die systemd gebruiken, zullen standaard na 30 seconden stoppen. Volgens hem is dit bewust in Linux gebouwd. “Het inbouwen van een kreukelzone in auto’s betekent toch ook niet dat ze slecht rijden.”

Reacties (37)
04-10-2016, 16:53 door Anoniem
"wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt’"

Dat gebeurt al op het moment dat je van sysv-init naar systemd overstapt!
04-10-2016, 16:54 door Anoniem
systemd-notify [OPTIONS...] [VARIABLE=VALUE...]


sudo NOTIFY_SOCKET=/run/systemd/notify systemd-notify

Notify the init system about service status updates.

-h --help Show this help
--version Show package version
--ready Inform the init system about service start-up completion
--pid[=PID] Set main pid of daemon
--status=TEXT Set status text
--booted Check if the system was booted up with systemd

systemd 231 heeft er kennelijk geen last van omdat er een parameter meegegeven moet worden.
04-10-2016, 17:08 door meinonA - Bijgewerkt: 04-10-2016, 17:09
Copy/past is blijkbeet niet jullie sterkste kant?

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

Overigens gebeurt er dan niets.
04-10-2016, 17:50 door Anoniem
Door meinonA: Copy/past is blijkbeet niet jullie sterkste kant?

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

Overigens gebeurt er dan niets.

Hier wel op een raspberry PI als NON root:

Broadcast message from systemd-journald@hostname (Tue 2016-10-04 17:48:52 CEST):

systemd[1]: Caught <ABRT>, dumped core as pid 1769.


Message from syslogd@hostname at Oct 4 17:48:52 ...
systemd[1]: Freezing execution.

Broadcast message from systemd-journald@hostname (Tue 2016-10-04 17:48:52 CEST):

systemd[1]: Freezing execution.
04-10-2016, 18:38 door Anoniem
"...maar wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt."

Oh, wat leuk. Zal het eens proberen. Grappig dat je met zo'n code je Linux-installatie net zo laat aanvoelen als Windows. :)
04-10-2016, 19:01 door Anoniem
Een Pi met raspbian (systemd 215) geen probleem, een Pi met Kali (systemd 231) 'crashed' zoals hierboven ook al te zien is.
04-10-2016, 20:46 door Anoniem
Vroeger had je in Windows ook /con/con om je PC te laten crashen ;-)
04-10-2016, 21:03 door Anoniem
Is een hdd erase commando in disk utility niet korter en gevaarlijker?
04-10-2016, 21:07 door Anoniem
Er zijn veel commando's die je systeem kunnen laten crashen, het bekendste voorbeeld is wel format c:/
04-10-2016, 22:01 door Anoniem
Te laat! De mijne hobbelt gewoon verder
04-10-2016, 22:17 door Anoniem
Door Anoniem: Is een hdd erase commando in disk utility niet korter en gevaarlijker?

Het verschil is dat je voor een hdd erase commando gewoonlijk maximale privileges nodig hebt (genoeg om op tig andere manieren een systeem te kunnen crashen), en het laten hangen van systemd als reguliere user kon.

De 'slechts 48 bytes' claim is niet het bijzondere, dat is 'gewone user laat systeem hangen'
04-10-2016, 22:24 door Anoniem
Door Anoniem: Er zijn veel commando's die je systeem kunnen laten crashen, het bekendste voorbeeld is wel format c:/
Verrek, je zegt het. Bij mij start die dan helemaal niet meer op!!!!
04-10-2016, 23:25 door Anoniem
Aha, als je vroeger een file genaamd "-rf" aanmaakte, en dan typte "rm *" in die directory, ideale test of je backups goed waren!
05-10-2016, 05:29 door bertjes
Door Anoniem: "wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt’"

Dat gebeurt al op het moment dat je van sysv-init naar systemd overstapt!

Voorlopig draaien mijn servers nog op Debian Wheezy. Dat is gelukkig nog zonder systemd. Jessie is ook mogelijk zonder systemd. Ik zou het niet op mijn servers willen hebben.
05-10-2016, 07:38 door Anoniem
RHEL 7, systemd 219 geen probleem.
05-10-2016, 08:41 door linuxpro
Dus, als je,als root, een commando intikt kan je een linux systeem laten 'crashen' . wouw... I'm impressed...
05-10-2016, 08:50 door Anoniem
Door linuxpro: Dus, als je,als root, een commando intikt kan je een linux systeem laten 'crashen' . wouw... I'm impressed...

Als je niet kunt lezen reageer dan ook niet.

Het is als normale user ZONDER extra rechten uitvoerbaar.

LinuxPro .....
05-10-2016, 09:11 door [Account Verwijderd]
[Verwijderd]
05-10-2016, 11:07 door Anoniem
Allemaal weer lichtelijk overdreven. Wat er gebeurt is dat het init systeem hangt zodat er bijvoorbeeld geen nieuwe services gestart kunnen worden en bepaalde beheertaken niet meer (goed) kunnen worden uitgevoerd. Afhankelijk van de mate van initialisatie en implementatie van systemd-onderdelen zullen bijvoorbeeld het Inloggen en het wisselen naar VT's niet meer werken.

Kortom Linux crasht niet en de gebruiker kan de desktop blijven gebruiken zonder al te veel problemen. De kans is groot dat er na een tijdje problemen ontstaan doordat geplande services niet meer draaien en processen problemen ondervinden omdat het init systeem niet reageert. Ook is veilig afsluiten niet meer mogelijk.

Het is zeker iets dat niet mogelijk zou moeten zijn, maar het besturingssysteem loopt niet vast, enkel het init systeem loopt vast (wat overigens wel grote gevolgen kan hebben doordat systemd een zeer uitgebreid init systeem is). Hopelijk zorgt dit voor betere QA en een meer modulair systeem zodat de impact verkleind kan worden.
05-10-2016, 11:10 door Anoniem
Door meinonA:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""

Overigens gebeurt er dan niets.
Gisteren uitgevoerd op Debian stable. Op het moment zelf gebeurde er niets, na 'sudo poweroff' bleef Debian hangen tijdens het afsluiten.
Door linuxpro: Dus, als je,als root, een commando intikt kan je een linux systeem laten 'crashen' . wouw... I'm impressed...
Nee, niet als root, als gewone user.
05-10-2016, 11:39 door linuxpro
Door Anoniem:
Door linuxpro: Dus, als je,als root, een commando intikt kan je een linux systeem laten 'crashen' . wouw... I'm impressed...

Als je niet kunt lezen reageer dan ook niet.

Het is als normale user ZONDER extra rechten uitvoerbaar.

LinuxPro .....

Het was te vroeg.. niet goed gelezen.. excuus ;-)
05-10-2016, 12:02 door Anoniem
Door linuxpro:

Het was te vroeg.. niet goed gelezen.. excuus ;-)

En ik reageeerde te sacherijnig.
05-10-2016, 12:23 door ph-cofi
Dus... als de IoT camera's uit dat grote botnet van afgelopen week hier gevoelig voor zijn, dan kunnen we hiermee het botnet langzaam om zeep helpen. Tijd voor een tegenbot? Klein beetje de C code aanpassen en software-roulette op andermans IoT device draaien...
05-10-2016, 12:57 door Anoniem
Je kan ook 'reboot' intikken of 'kill -9 0' wat je ook kan doen is op de uit knop drukken en buiten gaan spelen, next...
05-10-2016, 13:51 door Anoniem
Door ph-cofi: Dus... als de IoT camera's uit dat grote botnet van afgelopen week hier gevoelig voor zijn, dan kunnen we hiermee het botnet langzaam om zeep helpen. Tijd voor een tegenbot? Klein beetje de C code aanpassen en software-roulette op andermans IoT device draaien...


Als je de code doorgelezen had, had je gezien dat als de bot een busybox krijgt, een van de dingen die het gelijk doet is alle processen afschieten die op poort 80 22 en 23 luisteren. Dit om herinfectie door de concurent te voorkomen en de eigenaar buiten te sluiten. ik denk niet dat je tegenbot dan gaat werken.
05-10-2016, 14:57 door Anoniem
Door Anoniem: Je kan ook 'reboot' intikken of 'kill -9 0' wat je ook kan doen is op de uit knop drukken en buiten gaan spelen, next...

Wat blijft lezen toch een lastig iets, begrijpend lezen al helemaal.

Je hebt als normale user helemaal geen rechten om een Linux systeem te rebooten op welke manier dan ook.
05-10-2016, 15:33 door Anoniem
Door Anoniem:
Het is zeker iets dat niet mogelijk zou moeten zijn, maar het besturingssysteem loopt niet vast, enkel het init systeem loopt vast (wat overigens wel grote gevolgen kan hebben doordat systemd een zeer uitgebreid init systeem is). Hopelijk zorgt dit voor betere QA en een meer modulair systeem zodat de impact verkleind kan worden.

Yes say that well!
Misschien een idee om niet 1 uitgebreid init systeem te maken maar een veel simpeler systeem wat niet probeert
alles te regelen in 1 enkele omgeving?
Zeg maar, hoe het werkte voor dit onzalige ding werd uitgevonden?
05-10-2016, 18:16 door Anoniem
Door Anoniem:
Je hebt als normale user helemaal geen rechten om een Linux systeem te rebooten op welke manier dan ook.

Dat is waar, maar dan installeren we 'polkit' om ons leven makelijker te maken, voila, user rechten om te rebooten.
06-10-2016, 10:27 door Anoniem
Door Anoniem:
"...maar wat er feitelijk gebeurt is dat het systeem ‘in het algemeen onstabiel aanvoelt."

Oh, wat leuk. Zal het eens proberen. Grappig dat je met zo'n code je Linux-installatie net zo laat aanvoelen als Windows. :)

Interessante bewering : met welke code van 48 karakters kan je een Windows installatie met gewone user laten crashen?
06-10-2016, 11:20 door Anoniem
Niet grappig. Werk inderdaad goed als aangegeven.

OS Debian jessie amd64.

Vanuit console run dit command:
NOTIFY_SOCKET=/run/systemd/notify systemd-notify

Dan even wachten...

Stukje uit log:
[Thu Oct 6 11:13:19 2016] systemd-journald[160]: Received SIGTERM from PID 1 (systemd).
[Thu Oct 6 11:13:19 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:13:20 2016] systemd-journald[1126]: Received request to flush runtime journal from PID 1
[Thu Oct 6 11:14:26 2016] systemd[1]: systemd-logind.service watchdog timeout (limit 1min)!
[Thu Oct 6 11:14:26 2016] systemd[1]: Unit systemd-logind.service entered failed state.
[Thu Oct 6 11:15:50 2016] systemd[1]: systemd-journald.service stop-sigterm timed out. Killing.
[Thu Oct 6 11:15:50 2016] systemd[1]: systemd-journald.service: main process exited, code=killed, status=9/KILL
[Thu Oct 6 11:15:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:16:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:27 2016] systemd[1]: Unit systemd-logind.service entered failed state.
[Thu Oct 6 11:17:50 2016] systemd[1]: systemd-journald.service watchdog timeout (limit 1min)!
[Thu Oct 6 11:17:50 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: systemd-journald.service start request repeated too quickly, refusing to start.
[Thu Oct 6 11:17:51 2016] systemd[1]: Failed to start Journal Service.
[Thu Oct 6 11:17:51 2016] systemd[1]: Dependency failed for Trigger Flushing of Journal to Persistent Storage.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.service entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: systemd-journald.service start request repeated too quickly, refusing to start.
[Thu Oct 6 11:17:51 2016] systemd[1]: Failed to start Journal Service.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald.socket entered failed state.
[Thu Oct 6 11:17:51 2016] systemd[1]: Unit systemd-journald-dev-log.socket entered failed state.
06-10-2016, 11:29 door Anoniem
Alleen mijn systeem gaat niet plat. ik kan nog steeds via ssh inloggen op het systeem via het netwerk.

Commando:

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

systemd gaat naar een zogenaamde degraded status.

Na een kwartier:
$ systemctl status

gefliptehost
State: degraded
Jobs: 1 queued
Failed: 3 units
Since: Thu 2016-10-06 11:00:18 CEST; 24min ago
CGroup: /
??1 /sbin/init
??system.slice
? ??avahi-daemon.service
? ? ??438 avahi-daemon: running [africa.local
? ? ??487 avahi-daemon: chroot helpe
? ??dbus.service
? ? ??440 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
? ??ModemManager.service
? ? ??426 /usr/sbin/ModemManager
? ??cron.service
? ? ??425 /usr/sbin/cron -f
? ??nfs-common.service
? ? ??409 /sbin/rpc.statd
? ? ??423 /usr/sbin/rpc.idmapd
? ??exim4.service
? ? ??725 /usr/sbin/exim4 -bd -q30m
? ??lightdm.service
? ? ??706 /usr/sbin/lightdm
? ? ??730 /usr/bin/X :0 -seat seat0 -auth /var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
? ? ??848 lightdm --session-child 13 20
? ??atd.service
? ? ??428 /usr/sbin/atd -f
? ??minissdpd.service
? ? ??454 /usr/sbin/minissdpd -i 0.0.0.0
? ??cups.service
? ? ??698 /usr/sbin/cupsd -f
? ??ssh.service
? ? ?? 429 /usr/sbin/sshd -D
? ? ??1249 sshd: student [priv]
? ? ??1255 sshd: student@pts/1
? ? ??1256 -bash
? ? ??1267 systemctl status
? ? ??1268 pager
? ??systemd-logind.service
? ? ??1254 /lib/systemd/systemd-logind
? ??systemd-udevd.service
? ? ??168 /lib/systemd/systemd-udevd
? ??polkitd.service
? ? ??702 /usr/lib/policykit-1/polkitd --no-debug
? ??rpcbind.service
? ? ??400 /sbin/rpcbind -w
? ??cups-browsed.service
? ? ??699 /usr/sbin/cups-browsed
? ??NetworkManager.service
? ? ??431 /usr/sbin/NetworkManager --no-daemon
? ? ??748 /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/nm-dhcp-helper -pf /var/run/dhclient-eth0.pid -lf /var/lib/Network
? ??rsyslog.service
? ? ??696 /usr/sbin/rsyslogd -n
? ??acpid.service
? ??697 /usr/sbin/acpid
??user.slice
??user-1000.slice
? ??session-1.scope
? ? ??704 /bin/login --
? ? ??855 -bash
? ??user@1000.service
? ? ??852 /lib/systemd/systemd --user
? ? ??853 (sd-pam)
? ??session-2.scope
? ??1109 sshd: student [priv]
? ??1111 sshd: student@pts/0
? ??1112 -bash
??user-117.slice
??user@117.service
? ??827 /lib/systemd/systemd --user
? ??828 (sd-pam)
??session-c1.scope
??824 lightdm --session-child 17 20
??830 /usr/sbin/lightdm-gtk-greeter
??835 /usr/bin/dbus-launch --autolaunch 09ea9df544e6b54e8d9a8abf2fae69d1 --binary-syntax --close-stderr
??836 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
??838 /usr/lib/at-spi2-core/at-spi-bus-launcher
??842 /usr/bin/dbus-daemon --config-file=/etc/at-spi2/accessibility.conf --nofork --print-address 3
??845 /usr/lib/at-spi2-core/at-spi2-registryd --use-gnome-session
06-10-2016, 11:41 door [Account Verwijderd]
[Verwijderd]
06-10-2016, 11:54 door Anoniem
Trek het systeem weer vlot:

#Ga na wat er aan de hand is

$ sudo systemctl --failed
UNIT LOAD ACTIVE SUB DESCRIPTION
? systemd-journald.service loaded failed failed Journal Service
? systemd-journald-dev-log.socket loaded failed failed Journal Socket (/dev/log)
? systemd-journald.socket loaded failed failed Journal Socket

LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.

3 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.
student@africa:~$ systemctl reset-failed
Failed to execute operation: Access denied

#Maak failed services weer actief
$ systemctl status systemd-journald.service
? systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: inactive (dead) since Thu 2016-10-06 11:17:51 CEST; 31min ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 1203 (code=killed, signal=USR1

$ sudo systemctl start systemd-journald.service
$ systemctl status systemd-journald.service
? systemd-journald.service - Journal Service
Loaded: loaded (/lib/systemd/system/systemd-journald.service; static)
Active: active (running) since Thu 2016-10-06 11:49:59 CEST; 1s ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 1541 (systemd-journal)
Status: "Processing requests..."
CGroup: /system.slice/systemd-journald.service
??1541 /lib/systemd/systemd-journald

#Doe dit voor alle "failed" services

# Maak schoon
$ sudo systemctl reset-failed

Veel plezier.

Detail: het systeem ging nooit plat. Kon het gewoon remote beheren. En de log geeft het euvel mooi weer, dus je kan nagaan wat er aan hand was.
Jammer is wel dat een willekeurige gebruiken met beperkte rechten het systeem in een minder leuke staat kan zetten door een simpel commando uit te voeren.
07-10-2016, 02:35 door Anoniem
Door Anoniem:
Door Anoniem:
Het is zeker iets dat niet mogelijk zou moeten zijn, maar het besturingssysteem loopt niet vast, enkel het init systeem loopt vast (wat overigens wel grote gevolgen kan hebben doordat systemd een zeer uitgebreid init systeem is). Hopelijk zorgt dit voor betere QA en een meer modulair systeem zodat de impact verkleind kan worden.

Yes say that well!
Misschien een idee om niet 1 uitgebreid init systeem te maken maar een veel simpeler systeem wat niet probeert
alles te regelen in 1 enkele omgeving?
Zeg maar, hoe het werkte voor dit onzalige ding werd uitgevonden?

Jammer genoeg lijken dit soort incidenten nodig om de ogen te openen van de grote distributies. Het kalf moet eerst verdrinken, zeg maar.

Voor degene die op safe willen spelen, enkele Linux distributies die niet vatbaar zijn:
- Slackware
- Gentoo (tenzij bewust voor Systemd is gekozen)
- Void
- Debian Jessie (systemd kan eenvoudig verwijderd worden)
- Devuan (nieuwe distributie van een Nederlandse stichting. Systemd-loze Debian fork)

Is dus ook niet echt een Linux probleem, dus vind het netjes dat de kop van het artikel "systemd" noemt.
07-10-2016, 09:06 door [Account Verwijderd] - Bijgewerkt: 07-10-2016, 09:08
[Verwijderd]
07-10-2016, 16:16 door SPlid
Door Anoniem: Vroeger had je in Windows ook /con/con om je PC te laten crashen ;-)

Vroeger update ik mijn BIOS door met een schroevendraaier de BIOS rom van het moederbord te wippen, de pootjes van de nieuwe BIOS recht te buigen en in de lege DIL-socket te duwen. Ging dit mis dan kon je altijd nog de oude BIOS terug zetten (als de pootje rechts stonden) Bij het inbouwen van een nieuwe MFM schijf van 10 MB even met DEBUG de bad-sector table invoeren.....


Maar vroeger is vroeger , het is nu wat geld.
07-10-2016, 16:17 door SPlid
Vroeger had ik ook een UNIX mini staan die met een rs232 verbinding naar mijn VT100 emulatie ging, ja vroeger ;-)
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.