Faz pouco informações importantes sobre a identificação de uma vulnerabilidade (listado como CVE-2021-27365) no código do subsistema iSCSI Kernel Linux que Permite que um usuário local sem privilégios execute código no nível do kernel e obtenha privilégios de root no sistema.
O problema é causado por um bug no módulo iscsi_host_get_param () da libiscsi, introduzido em 2006 durante o desenvolvimento do subsistema iSCSI. Devido à falta de controles de dimensionamento adequados, alguns atributos de string iSCSI, como nome de host ou nome de usuário, podem exceder o valor PAGE_SIZE (4KB).
A vulnerabilidade pode ser explorada enviando mensagens do Netlink por um usuário sem privilégios que define os atributos iSCSI para valores maiores que PAGE_SIZE. Ao ler dados de atributo por meio de sysfs ou seqfs, o código é chamado para passar os atributos para sprintf para que sejam copiados em um buffer de tamanho PAGE_SIZE.
O subsistema específico em questão é o transporte de dados SCSI (Small Computer System Interface), que é um padrão de transferência de dados feito para conectar computadores a dispositivos periféricos, originalmente por meio de um cabo físico, como discos rígidos. SCSI é um padrão venerável originalmente publicado em 1986 e era o padrão ouro para configurações de servidor, e iSCSI é basicamente SCSI sobre TCP. O SCSI ainda é usado hoje, especialmente em certas situações de armazenamento, mas como isso se torna uma superfície de ataque em um sistema Linux padrão?
Explorando vulnerabilidade nas distribuições depende do suporte para carregamento automático do módulo do kernel scsi_transport_iscsi ao tentar criar um socket NETLINK_ISCSI.
Em distribuições onde este módulo carrega automaticamente, o ataque pode ser realizado independentemente do uso da funcionalidade iSCSI. Ao mesmo tempo, para o uso bem-sucedido da exploração, o registro de pelo menos um transporte iSCSI é adicionalmente necessário. Por sua vez, para registrar um transporte, você pode usar o módulo de kernel ib_iser, que é carregado automaticamente quando um usuário sem privilégios tenta criar um socket NETLINK_RDMA.
Carregamento automático de módulos necessários para usar o exploit suporta CentOS 8, RHEL 8 e Fedora instalando o pacote rdma-core no sistema, que é uma dependência de alguns pacotes populares e é instalado por padrão em configurações para estações de trabalho, sistemas de servidor com GUI e virtualização de ambientes host.
Ao mesmo tempo, o rdma-core não é instalado ao usar uma compilação de servidor que funciona apenas no modo de console e ao instalar uma imagem de instalação mínima. Por exemplo, o pacote está incluído na distribuição Fedora 31 Workstation base, mas não está incluído no Fedora 31 Server.
Debian e Ubuntu são menos suscetíveis ao problemajá que o pacote rdma-core carrega apenas os módulos do kernel necessários para um ataque se o hardware RDMA estiver disponível. No entanto, o pacote Ubuntu do lado do servidor inclui o pacote open-iscsi, que inclui o arquivo /lib/modules-load.d/open-iscsi.conf para garantir que os módulos iSCSI sejam carregados automaticamente em cada inicialização.
Um protótipo funcional do exploit está disponível para tente no link abaixo.
A vulnerabilidade foi corrigida nas atualizações do kernel do Linux 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260 e 4.4.260. As atualizações do pacote do kernel estão disponíveis no Debian (oldstable), Ubuntu, SUSE / openSUSE, Arch Linux e distribuições Fedora, enquanto para RHEL nenhuma correção foi lançada ainda.
Além disso, no subsistema iSCSI duas vulnerabilidades menos perigosas foram corrigidas que pode levar ao vazamento de dados do kernel: CVE-2021-27363 (informações vazadas sobre o descritor de transporte iSCSI via sysfs) e CVE-2021-27364 (leitura de uma região fora dos limites do buffer).
Essas vulnerabilidades podem ser exploradas para se comunicar por meio de um soquete de link de rede com o subsistema iSCSI sem os privilégios necessários. Por exemplo, um usuário sem privilégios pode se conectar ao iSCSI e enviar um comando de logoff.
fonte: https://blog.grimm-co.com