Va ser descoberta una nova vulnerabilitat en systemd

systemd

Va ser trobada una vulnerabilitat en systemd la qual ja està descrita en (CVE-2019-6454), Que permet provocar el bloqueig de l'procés d'inicialització de control (PID1) a l'enviar un missatge especialment dissenyat a un usuari sense privilegis a través de l'D-Bus.

Els desenvolupadors de Red Hat tampoc exclouen la possibilitat d'utilitzar la vulnerabilitat per organitzar l'execució de l'codi amb privilegis de root, Però encara no s'ha determinat la possibilitat final de tal atac.

sobre systemd

Per als qui no coneguin systemd els puc dir que aquest és un sistema d'inicialització de Linux i administrador de serveis que inclou funcions com l'inici a comanda de dimonis, el manteniment de punts de muntatge i muntatge automàtic, el suport d'instantànies i el seguiment de processos utilitzant grups de control de Linux.

Systemd proporciona un dimoni de registre i altres eines i utilitats per ajudar amb les tasques comunes d'administració de sistema. Lennart Poettering i Kay Sievers van escriure systemd, inspirat per macOS launchd i Upstart, amb l'objectiu de crear un sistema modern i dinàmic.

En particular, systemd proporciona capacitats de paral·lelització agressives i una lògica de control de servei basada en la dependència, permetent que els serveis s'iniciïn en paral·lel i el que porta a un temps d'arrencada més ràpid. Aquests dos aspectes eren presents en Upstart, però millorats per systemd.

Systemd és el sistema d'inici per defecte per a les principals distribucions de Linux, Però és compatible amb versions anteriors dels scripts d'inici SysV.

Sysvinit és un sistema d'inicialització que precedeix systemd i utilitza un enfocament simplificat per iniciar el servei. Systemd no només administra la inicialització de el sistema, sinó que també proporciona alternatives per a altres utilitats ben conegudes, com cron i syslog.

Sobre la nova vulnerabilitat de systemd

A l'manipular la mida de l'missatge enviat a través de l'D-Bus, un atacant pot moure el punter més enllà dels límits de la memòria assignada per a la pila, Ometent la protecció de «stack guard-page», que es basa en la substitució d'una pàgina de memòria a la vora que diu una excepció (fallada de pàgina).

L'atac reeixit es demostra en Ubuntu 18.10 amb systemd 239 i en CentOS 7.6 amb systemd 219.

Com a solució alternativa, la compilació es pot usar en GCC amb l'opció «-fstack-clash-protection», que s'usa per defecte a Fedora 28 i 29.

Cal assenyalar que en 2014 l'autor de la MUSL biblioteca d'sistema assenyalat entre els principals problemes arquitectònics systemd inflació excessiva gestor PID1 i va posar en dubte la viabilitat d'implementar un nivell PID1 controlador d'API d'Enllaç amb el Bus, ja que és un vector seriosa per als atacs i pot afectar negativament a la fiabilitat de la totalitat sistema

D'acord amb un investigador de seguretat que va revelar una vulnerabilitat, un canvi de el punter de pila és possible només per a pàgines de memòria no utilitzades (No assignades), el que no permet organitzar l'execució de codi en el context de l'procés PID1, però permet que un atacant iniciï el bloqueig de PID1 amb una subsegüent transició de el nucli de Linux a l'estat de «panic» (en el cas de una fallada de l'controlador PID 1, es bloqueja el sistema complet).

En systemd, s'instal·la un controlador de senyals que intenta interceptar les falles de l'procés PID1 (segmentation fault) i inicia el shell per a la recuperació.

Però ja que, durant l'atac, es realitza una crida a pàgines de memòria no duplicades (no assignades), el nucli no pot trucar a aquest controlador de senyals i simplement finalitza el procés amb PID 1, el que, al seu torn, fa impossible continuar treballant i passar a l'estat de «panic», de manera que es requereix d'un reinici de sistema.

Ja hi ha una solució per al problema

Com tot problema de seguretat ja descrit i informat, la seva publicació no pot ser realitzada fins a haver solucionat el problema i actualització de pegats de vulnerabilitat per SUSE / openSUSE, Fedora ja van ser alliberats, així mateix també per Ubuntu i en part per a Debian (Només per a Debian Stretch).
Tot i que el problema roman sense corregir en RHEL.


Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   juliosao va dir

    És que systemd té tota la pinta d'anar a convertir-se en un enorme cavall de Troia. Trenca amb la filosofia UNIX de «Fes una sola cosa i fes-ho bé» i això acabarem pagant-ho.

    1.    David Taronger va dir

      Penso el mateix ...

  2.   Pau Matilla va dir

    Jo personalment sóc bastant conservador amb el sistema d'inici, penso com els més antics i tradicionals usaris de l'UNIX tradicional i primitiu: JO PREFEREIXO SYSTEM V INIT O SIGUI EL TRADICIONAL sysvinit DE SEMPRE. Systemd (LO TENIA INSTAL·LAT AL LIMUX DEBIAN 8.3 QUE QUEDO A LA THINKPAD T450 QUE EM van robar AL MARÇ DE 2017) systemd MAI em va convèncer

  3.   Luix va dir

    systemd EMPESTA !!