Como detecto processos em execução usando um pacote de biblioteca?

Question

Este comando está fazendo as rodadas para detectar processos atualmente em execução usando o glibc:

lsof | grep libc | awk '{print $2}' | sort | uniq

Eu acho isso extremamente irritante, já que /libc/ corresponde não apenas a libc , mas no meu sistema:

/lib/x86_64-linux-gnu/libcap.so.2.24
/lib/x86_64-linux-gnu/libcgmanager.so.0.0.0
/lib/x86_64-linux-gnu/libcom_err.so.2.1
/lib/x86_64-linux-gnu/libcrypt-2.19.so
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
/usr/lib/libcamel-1.2.so.45.0.0
/usr/lib/unity-settings-daemon-1.0/libcolor.so
/usr/lib/unity-settings-daemon-1.0/libcursor.so
/usr/lib/x86_64-linux-gnu/colord-plugins/libcd_plugin_camera.so
/usr/lib/x86_64-linux-gnu/colord-plugins/libcd_plugin_scanner.so
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libcanberra-gtk3-module.so
/usr/lib/x86_64-linux-gnu/libcairo-gobject.so.2.11301.0
/usr/lib/x86_64-linux-gnu/libcairo.so.2.11301.0
/usr/lib/x86_64-linux-gnu/libcanberra-0.30/libcanberra-pulse.so
/usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0.1.9
/usr/lib/x86_64-linux-gnu/libcanberra.so.0.2.5
/usr/lib/x86_64-linux-gnu/libcap-ng.so.0.0.0
/usr/lib/x86_64-linux-gnu/libck-connector.so.0.0.0
/usr/lib/x86_64-linux-gnu/libcolordprivate.so.1.0.23
/usr/lib/x86_64-linux-gnu/libcolord.so.1.0.23
/usr/lib/x86_64-linux-gnu/libcroco-0.6.so.3.0.1
/usr/lib/x86_64-linux-gnu/libcupsmime.so.1
/usr/lib/x86_64-linux-gnu/libcups.so.2
/usr/lib/x86_64-linux-gnu/samba/libcliauth.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_cldap.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli-ldap-common.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli-nbt.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_smb_common.so.0
/usr/lib/x86_64-linux-gnu/samba/libcli_spoolss.so.0
/usr/lib/x86_64-linux-gnu/samba/liblibcli_lsa3.so.0
/usr/lib/x86_64-linux-gnu/samba/liblibcli_netlogon3.so.0

Eu entendo que libc é usado por praticamente tudo, mas eu gostaria de refinar esse comando. Considere suas aplicações para outras bibliotecas. Como posso fazer isso?

A falha nesta abordagem, na minha opinião, é que o pacote que fornece libc pode incluir uma série de outros arquivos de biblioteca compartilhada (todos os quais podem ou não ser cobertos pelo termo genérico que é o nome da biblioteca). , como glibc ou libboost-python ). Usar um limite de palavra ou - para marcar o final de libc realmente não corrige isso. Isso pode não ser uma falha, talvez, como Braiam ressalta, já que muitos ou todos esses arquivos .so podem se vincular a um arquivo principal no qual a falha reside, como é o caso de libc6 no Debian.

Se um OS / distro específico for necessário, assuma o Debian Linux.

Também é irritante que este comando possa ser condensado em lsof | awk '/libc/{print $2}' | sort -u .

    

Answer 1

Essa é uma rotunda e um método grosseiramente impreciso. Você sabe a localização do arquivo da biblioteca, portanto, não é necessário usar a heurística para corresponder a ele. Você pode pesquisar o caminho exato.

Existe uma maneira muito simples de listar os processos com um arquivo aberto:

fuser /lib/x86_64-linux-gnu/libc.so.6

No entanto, isso lista os processos que abrem a versão atual do arquivo, ou seja, os processos que usam a nova cópia da biblioteca. Se você deseja listar os processos que possuem a cópia excluída, use lsof , mas procurando um caminho exato. Restringir lsof ao sistema de arquivos que contém o arquivo excluído para desempenho (e possivelmente para evitar o bloqueio, por exemplo, de sistemas de arquivos de rede temporariamente inacessíveis).

lsof -o / | awk '$4 == "DEL" && $8 == "/lib/x86_64-linux-gnu/libc-2.13.so" {print $2}'

Se o pacote atualizado contiver várias bibliotecas e você quiser detectar qualquer uma das bibliotecas, liste todos os arquivos de biblioteca do pacote. Aqui está uma maneira de fazer isso programaticamente (para um pacote Debian, ajuste de acordo com sua distribuição, por exemplo, rpm -ql glibc na Red Hat).

lsof -o / | awk '
   BEGIN {
       while (("dpkg -L libc6:amd64 | grep \\.so\$" | getline) > 0)
           libs[$0] = 1
   }
   $4 == "DEL" && $8 in libs {print $2}'

    

Answer 2

Use grep -w libc neste exemplo. Você também pode usar ldd para análise estática.

Para correspondência, você precisa jogar com expressões regulares. grep '/libc-' funciona aqui, mas se você quiser encontrar algo como libcan, você pode usar algo como '/libcan\>' , em que \> força uma correspondência no final da palavra.

    

Answer 3

Para testar a vulnerabilidade do GHOST (tudo que foi encontrado antes de nós):

wget https://gist.githubusercontent.com/koelling/ef9b2b9d0be6d6dbab63/raw/de1730049198c64eaf8f8ab015a3c8b23b63fd34/gistfile1.c
gcc gistfile1.c -o CVE-2015-0235
./CVE-2015-0235

Fonte