Empresa Qualys quatro no OpenBSD, um dos quais permite conectar-se remotamente sem autenticação a alguns serviços de rede, e os outros três aumentam seus privilégios no sistema. O relatório Qualys observou a resposta rápida dos desenvolvedores do OpenBSD - todos os problemas foram в и dentro de 40 horas após a notificação privada.
A vulnerabilidade explorável remotamente é causada por um erro ao chamar o manipulador de autenticação na biblioteca libc, que chama
programa /usr/libexec/auth/login_style passando argumentos na linha de comando. Inclusive ao chamar login_style utilizando o parâmetro opcional “-s service”, é possível transferir o nome do protocolo. Se você usar um caractere “-” no início de um nome de usuário, esse nome será tratado como uma opção ao executar login_style. Da mesma forma, se você especificar “-schallenge” ou “-schallenge:passwd” como o nome de usuário durante a autenticação, então login_style perceberá a solicitação como uma solicitação para usar o manipulador .
O problema é que o protocolo S/Key em login_style é suportado apenas formalmente, mas na verdade é ignorado com a saída de um sinal de autenticação bem-sucedida. Assim, um invasor pode, fazendo-se passar pelo usuário "-challenge", ignorar a autenticação e obter acesso sem fornecer senha ou chaves. Todos os serviços de rede que usam chamadas libc padrão para autenticação são potencialmente afetados pelo problema. Por exemplo, a capacidade de ignorar a autenticação é suportada em smtpd (AUTH PLAIN), ldapd e radiusd.
A vulnerabilidade não aparece no sshd, pois possui proteção adicional que verifica a presença do usuário no sistema. Porém, o sshd pode ser usado para testar a vulnerabilidade de um sistema - ao acessar o nome de usuário "-sresponse:passwd", a conexão trava, pois o sshd está aguardando o login_passwd retornar os parâmetros de desafio, e o login_passwd está aguardando os parâmetros ausentes para ser enviado (o nome "-sresponse" é tratado como uma opção). Um invasor local poderia tentar ignorar a autenticação no utilitário su, mas passar o nome "-sresponse" faz com que o processo trave, retornando um ponteiro nulo ao executar a função getpwnam_r("-schallenge", ...).
Outras vulnerabilidades:
- CVE-2019-19520 Escalonamento de privilégios locais por meio da manipulação do utilitário xlock fornecido com o sinalizador sgid alterando o grupo para "auth". No código xlock, a redefinição de caminhos para bibliotecas é proibida apenas quando o identificador do usuário (setuid) é alterado, o que permite ao invasor alterar a variável de ambiente “LIBGL_DRIVERS_PATH” e organizar o carregamento de sua biblioteca compartilhada, cujo código será executado depois de aumentar os privilégios para o grupo “auth”.
- CVE-2019-19522 - Permite que um usuário local que seja membro do grupo "auth" execute código como root quando a autenticação S/Key ou YubiKey estiver habilitada no sistema (não ativa por padrão). Juntar-se ao grupo “auth”, que pode ser acessado explorando a vulnerabilidade mencionada acima no xlock, permite gravar arquivos nos diretórios /etc/skey e /var/db/yubikey. Por exemplo, um invasor pode adicionar um novo arquivo /etc/skey/root para gerar chaves únicas para autenticação como usuário root via S/Key.
- CVE-2019-19519 - possibilidade de aumentar os limites de recursos por meio da manipulação do utilitário su. Quando a opção "-L" é especificada, o que faz com que as tentativas de autenticação sejam repetidas ciclicamente se não forem bem-sucedidas, a classe do usuário é definida apenas uma vez e não é redefinida nas tentativas subsequentes. Um invasor pode executar “su -l -L” na primeira tentativa de inserir o login de outra pessoa com uma classe de conta diferente, mas na segunda tentativa ele pode se autenticar com sucesso. Nesta situação, o usuário estará sujeito a limites baseados na classe de usuário especificada na primeira tentativa (por exemplo, o número máximo de processos ou tamanho de memória para um processo). O método só funciona para empréstimos de limites de usuários sem privilégios, já que o usuário root deve estar no grupo wheel).
Além disso, pode-se notar no OpenBSD, um novo método para verificar a validade das chamadas do sistema, o que complica ainda mais a exploração de vulnerabilidades. O método permite que chamadas de sistema sejam executadas somente se forem acessadas de áreas de memória previamente registradas. Para marcar áreas de memória nova chamada de sistema .
Fonte: opennet.ru