Se exploradas, essas falhas podem permitir que invasores ganhem acesso não autorizado a informações confidenciais ou geralmente causa problemas
Correu a notícia de que uma vulnerabilidade foi identificada d (já catalogado sob CVE–) em systemd-coredump, que lida com arquivos principais gerado após falhas de processo e que pode permitir que um usuário local sem privilégios inspecione o conteúdo da memória de processos privilegiados em execução com o prompt root suid.
systemd-coredump é um driver de coredump de espaço de usuário para Linux que faz parte de do pacote systemd. A vulnerabilidade se deve à falta de manipulação correta do parâmetro sysctl fs.suid_dumpable no systemd-coredump que, com o valor padrão de 2, permite a geração de core dumps .kernel para processos marcados como suid.
Entende-se que os arquivos principais de processos suid escritos pelo kernel devem receber direitos de acesso que permitem a leitura apenas pelo usuário root. La utilidad systemd-coredump, a la que llama el kernel para guardar archivos principales, guarda el archivo principal como root, pero además otorga acceso basado en ACL a los archivos principales que se pueden leer según la ID del propietario que inició originalmente el proceso.
Esta función le permite cargar archivos centrales sin tener en cuenta el hecho de que el programa puede cambiar la ID de usuario y ejecutarse con privilegios elevados. El ataque se reduce al hecho de que el usuario puede iniciar una aplicación suid y enviarle una señal SIGSEGV, luego de lo cual carga el contenido del archivo central, que incluye una porción de la memoria del proceso en el momento del bloqueo.
En el correo donde se informa sobre el problema se comenta lo siguiente:
A questão
=========
sy stemd-coredump define sysctl fs.suid_dumpable por padrão como 2 usando
um arquivo de configuração push sysctl.d. Para o despejo de núcleo integrado do kernel
lidar com esta configuração significa que o core dumps para setuid (ou de outra forma
Processos privilegiados) gravarão no disco, mas apenas
acessível para usuário root para evitar vazamento de dados confidenciais para
contas de usuários não privilegiados. Veja também `man 5 proc` para o
documentação para este sysctl.
systemd-coredump no userspace, porém não respeita este kernel
em sua implementação de tratamento de despejo de núcleo. O ID de usuário real
de um processo de despejo receberá acesso de leitura ao despejo principal por meio de um
Entrada LCA
Por exemplo, o usuário pode executar “/usr/bin/su” e terminar sua execução em outro terminal com o comando “kill -s SIGSEGV `pidof su`”, após o qual systemd-coredump irá salve o arquivo principal no diretório /var /lib/systemd/coredump definindo uma ACL para ele que permite que o usuário atual o leia.
É mencionado que, como o utilitário suid ‘su’ lê o conteúdo de /etc/shadow na memória, um invasor pode acessar informações sobre os hashes de senha de todos os usuários no sistema. O utilitário sudo não é suscetível a ataques, pois proíbe a geração de arquivos principais via ulimit.
Quanto ao problema, foi confirmado na configuração padrão do openSUSE, Distribuições Arch, Debian, Fedora e SLES. De acordo com os desenvolvedores do systemd, a vulnerabilidade se manifesta a partir da versão 246 do systemd (lançado em novembro ), mas segundo o pesquisador que identificou o problema, a versão 246.
A vulnerabilidade se manifesta se o systemd for compilado com a biblioteca libacl (padrão em todas as distribuições populares). A correção ainda está disponível como um patch.
Para os interessados em rastrear a correção nas distribuições, você pode fazê-lo nas seguintes páginas: Debian, Ubuntu, Gentoo, RHEL , SUSE, Fedora, Gentoo, Arch.
Finalmente, como uma solução de segurança temporária, os usuários podem definir sysctl fs.suid_dumpable como 0, o que desativa a transferência de dados. coredump driver.
Se você quiser saber mais sobre isso, você pode verificar os detalhes no seguinte link.
O conteúdo do artigo adere aos nossos princípios de ética editorial. Para notificar um erro clique aqui.