En ny sårbarhet upptäcktes i Systemd

En sårbarhet hittades i systemd som redan beskrivs i (CVE-2019-6454), än gör att kontrollinitieringsprocessen (PID1) kan blockeras när du skickar ett speciellt utformat meddelande till en icke-privilegierad användare via D-Bus.

mycket Red Hat-utvecklare utesluter inte heller möjligheten att använda sårbarheten för att organisera kodkörning med root-behörigheter., men den slutliga möjligheten till en sådan attack har ännu inte fastställts.

Om systemd

För dem som inte känner till Systemd Jag kan säga dig det detta är ett Linux-initieringssystem och servicechef som inkluderar funktioner som on-demand-start av demon, automatiskt underhåll och montering av punkt, stöd för ögonblicksbild och spårning av processer med hjälp av Linux-kontrollgrupper.

SYSTEMD tillhandahåller en registerdemon och andra verktyg och verktyg som hjälper till med vanliga systemadministrationsuppgifter. Lennart Poettering och Kay Sievers skrev SystemD, inspirerad av macOS launchd och Upstart, med målet att skapa ett modernt och dynamiskt system.

I synnerhet ger systemd aggressiva parallelliseringsfunktioner och beroendebaserad logistik för tjänstekontroll, vilket gör att tjänster kan starta parallellt och leda till snabbare starttider. Dessa två aspekter var närvarande i Upstart, men förbättrades av systemd.

Systemd är standardsystemet för större Linux-distributioner, men det är bakåtkompatibelt med SysV-startskript.

SysVinit är ett initialiseringssystem som föregår systemd och använder en förenklad metod för att starta tjänsten. Systemd hanterar inte bara systeminitiering, utan ger också alternativ till andra välkända verktyg som cron och syslog.

Om den nya sårbarheten i systemet

Genom att manipulera storleken på meddelandet som skickas via D-bussen, en angripare kan flytta pekaren utöver gränserna för minne som tilldelats stacken, kringgå skyddet av "stack guard-page", som är baserat på att en minnessida ersätts vid kanten som kallar ett undantag (sidfel).

Den framgångsrika attacken demonstreras på Ubuntu 18.10 med systemd 239 och på CentOS 7.6 med systemd 219.

Som en lösning kan kompilering användas i GCC med alternativet "-fstack-clash-protection", som används som standard i Fedora 28 och 29.

Det bör noteras att författaren till MUSL-systembiblioteket 2014 påpekade bland de viktigaste arkitektoniska problemen i systemet för överdriven inflation PID1-hanterare och ifrågasatte möjligheten att implementera ett PID1-nivåkontroll-API för Link with the Bus, eftersom det är en seriös vektor för attacker och kan påverka tillförlitligheten för hela systemet negativt

Enligt en säkerhetsforskare som avslöjade en sårbarhet, en ändring av stackpekaren är endast möjlig för oanvända minnessidor (ej tilldelad), som inte tillåter att organisera kodkörning i samband med PID1-processen, men tillåter en angripare att initiera PID1-låset med en efterföljande övergång av Linux-kärnan till "panik" -tillstånd (i fallet med PID-kontroller 1-fel, hela systemet hänger).

I systemd installeras en signalhanterare som försöker fånga felen i PID1-processen (segmenteringsfel) och startar skalet för återställning.

Men eftersom ett samtal görs till icke-duplicerade (icke allokerade) minnessidor under attacken kan kärnan inte ringa denna signalhanterare och avslutar bara processen med PID 1, vilket i sin tur Det är omöjligt att fortsätta arbeta och gå in i "panik" -tillstånd, så det krävs en omstart av systemet.

Det finns redan en lösning på problemet

Liksom alla säkerhetsproblem som redan beskrivits och rapporterats kan publiceringen inte göras förrän problemet har lösts och sårbarhetsuppdateringar för SUSE / openSUSE, Fedora har redan släppts, även för Ubuntu och delvis för Debian (Endast Debian Stretch).
Även om problemet fortfarande är okorrigerat i RHEL.