sideeffect42/rootpipetesterRootPipe (CVE-2015-1130) e Phoenix (CVE-2015-3673) utilitário de teste de vulnerabilidade para Mac OS X 10.2.8 e posteriores
O RootPipe Tester é um pequeno aplicativo que roda no seu Mac (Mac OS X 10.2.8 ou superior, tanto PowerPC quanto Intel) e tenta usar tanto o exploit RootPipe (CVE-2015-1130) quanto o Phoenix (CVE-2015-3673) para produzir uma escalada de privilégios.
Se o seu Mac está vulnerável depende da versão do Mac OS X que você está executando, mas seu sucesso também depende das preferências que você definiu.
Com o RootPipe Tester, criei uma solução de um clique para você verificar se está vulnerável sem precisar fazer testes extensivos e tentativas.
Baixe a imagem de disco da página de lançamentos deste repositório ou compile por conta própria, se preferir.
Monte a imagem de disco e execute o aplicativo contido nela (é seguro executar o RootPipe Tester a partir da imagem de disco).
Clique em "Iniciar Teste" e deixe o teste ser executado (você pode saber que terminou pelo "A executar…" no título da janela).
Para obter resultados precisos, recomendo reiniciar o Mac e executar o teste novamente em um "login novo".
Se pelo menos uma das execuções de teste detectou um sistema vulnerável, você pode querer conferir a seção PÂNICO.
Não! Mantenha a calma e leia o guia apropriado para a versão do seu sistema.
Nota: "Não vulnerável" em autorização de usuário significa que o sistema não concederá acesso ou exibirá uma caixa de diálogo de autorização solicitando que você se autentique como um usuário Administrador.
Até certo ponto, isso também é uma escalada de privilégios, porque o grupo admin não tem tantos direitos quanto o root, mas na configuração padrão do sudo, todo usuário no grupo "admin" pode obter root digitando sua senha, então o mesmo efeito também pode ser alcançado simplesmente executando sudo.
Atualize para 10.10.3 o mais rápido possível para garantir que o sistema aplique corretamente as entitlements no binário writeconfig. (pelo menos é o que a Apple diz)
Se por algum motivo você não puder atualizar para 10.10.3, consulte a seção para OS X 10.9 Mavericks.
O Mavericks permite que um invasor passe com autorização nula, então você está em uma situação muito mais difícil do que com versões mais antigas do Mac OS X.
Você pode querer dar uma olhada no can_I_suid.
Resultados dos testes:
Vulnerável
Você deve ativar "Exigir senha para desbloquear cada painel de Preferências do Sistema" no painel de preferências de Segurança.
Resultados dos testes:
Não vulnerável
Parabéns! Você tem uma das versões mais seguras do Mac OS X (pelo menos no que diz respeito ao RootPipe).
Nesses sistemas, a opção "Exigir senha para desbloquear cada painel de Preferências do Sistema" ("Exigir senha para desbloquear cada preferência segura do sistema" no Tiger) no painel de preferências de Segurança funciona corretamente e realmente deve estar ativada!
Nota: Se a caixa de seleção "Exigir senha" estiver desmarcada, o sistema desbloqueará os painéis de preferências seguras em cada login. Se você estiver usando uma conta de Administrador, isso tornará seu sistema vulnerável até que você feche manualmente o cadeado nas Preferências do Sistema após cada login.
Resultados dos testes:
Não vulnerável
Diferente de sistemas posteriores, no Panther, a caixa de seleção "Exigir senha para desbloquear cada preferência segura do sistema" no painel de preferências de Segurança não tem o efeito de impedir totalmente o funcionamento deste exploit. Ainda assim, recomendo marcá-la.
Para proteger seu sistema, recomendo fortemente que você mude para usar apenas uma conta de usuário padrão e sempre feche manualmente o "cadeado" após alterar as preferências nas Preferências do Sistema.
Apenas fechar as Preferências do Sistema não invalidará corretamente a autorização e este exploit funcionará até você sair da sessão, embora a GUI das Preferências do Sistema mostre um cadeado fechado como um usuário Padrão.
Resultados dos testes:
Não vulnerável
Diferente de sistemas posteriores, o Jaguar não fornece uma caixa de seleção "Exigir senha para desbloquear cada painel de Preferências do Sistema", mas ainda desbloqueia os painéis de preferências seguras no login para todos os usuários Administradores.
Para proteger seu sistema, recomendo fortemente que você mude para usar apenas uma conta de usuário padrão.
Nota: O Jaguar não bloqueia os painéis de preferências seguras quando as Preferências do Sistema são fechadas, portanto, sempre bloqueie os painéis seguros manualmente. Se você não fizer isso, o exploit funcionará até você sair da sessão.
Nota: Se você não puder mudar para uma conta de usuário padrão, um simples AppleScript que bloqueie os painéis de preferências seguras como um Item de Login pode resolver o problema.
Nota: A versão normal do RootPipe Tester não funcionará no Jaguar. Baixe a versão Legacy do RootPipe Tester se quiser executá-lo no Jaguar.
A versão Legacy do RootPipe Tester é equivalente em funcionalidade à versão normal, mas é compilada com GCC 3.1 em vez de GCC 4.0.
Resultados dos testes:
Não vulnerável
Um exploit para o Puma parece viável, porque ele usa os mesmos passos para autenticar as Preferências do Sistema e a maioria dos componentes necessários está presente.
A única coisa que impede um exploit é que o Puma não possui o SecurityFoundation.framework, que é usado em versões posteriores para autorizar.
Em vez disso, ele usa um PrivateFramework chamado NIInterface.framework, que precisa ser engenharia reversa primeiro.
Boas notícias de qualquer forma: Ninguém vai investir tempo em explorar uma base de usuários provavelmente quase inexistente.
Para aumentar a segurança, ainda é recomendado usar apenas uma conta de usuário padrão e bloquear manualmente os painéis de preferências seguras.
Nota: Leve este parágrafo com cautela. Tentei ao máximo entender o que realmente está acontecendo, mas como tudo são PrivateFrameworks, você nunca pode saber 100% o que esses métodos estão fazendo, especialmente em tantas versões do Mac OS X quanto estou tentando cobrir.
A forma como o exploit RootPipe funciona é basicamente a mesma que as Preferências do Sistema usam para escrever arquivos de configuração (daí o nome WriteConfig), com a exceção de que os usuários deste exploit não precisam ser o aplicativo Preferências do Sistema.
Até agora não é tão horrível, e na verdade o exploit inteiro também não é tão horrível.
Mas vamos olhar o código.
// Authorization
SFAuthorization auth = [SFAuthorization authorization];
id authenticator = [Authenticator sharedAuthenticator];
[authenticator authenticateUsingAuthorizationSync:auth];
// Profit?
id sharedLiaison = [ToolLiaison sharedToolLiaison];
id tool = [sharedLiaison tool];
Como você pode ver, este é um código "estilo antigo", mas o princípio para o novo estilo é mais ou menos o mesmo.
As três primeiras linhas neste trecho são de autorização e as duas últimas são a parte divertida.
Se um painel de preferências nas Preferências do Sistema precisa realizar operações que devem ser executadas com privilégios, ele colocará um SFAuthorizationView (o símbolo do cadeado) no canto inferior esquerdo. Esse SFAuthorizationView então cuidará da aquisição e destruição do direito system.preferences.
Até aqui tudo bem, mas o que é esse system.preferences?
Os direitos que a Apple usa e como eles são configurados mudaram ao longo do tempo, mas o princípio permaneceu o mesmo. Abaixo você vê um trecho do Banco de Dados de Políticas do Authorization Services.
system.preferences no 10.5.8
{
"allow-root" = 1;
class = user;
comment = "Checked by the Admin framework when making changes to certain System Preferences.";
group = admin;
shared = 1;
}
Como você pode ver, é um direito compartilhado. Isso significa que, uma vez que esse direito foi adquirido por qualquer processo, todos os outros processos podem usá-lo enquanto a sessão não for destruída (quando você sai da sessão).
Isso por si só não é tão ruim, porque você tem que autorizar na primeira vez que um aplicativo quiser usar system.preferences, infelizmente o sistema o autoriza automaticamente no login (para usuários Administradores).
Isso significa que nosso RootPipe Tester não precisará ser autorizado e poderá usar a autorização do sistema.
Usuários padrão estão seguros, porque o sistema não autoriza o direito system.preferences no login.
Com a autorização adequada adquirida, é um jogo bastante fácil escrever arquivos de configuração (ou qualquer outro arquivo, aliás) com direitos arbitrários.
O ToolLiaison vai alegremente configurar um NSDistantObject para writeconfig para você, e o writeconfig vai alegremente escrever o arquivo para você, porque, na mente deles, você se autorizou perfeitamente.
Marcar a opção "Exigir senha para desbloquear cada painel de Preferências do Sistema" nas Preferências do Sistema corrige o RootPipe em todas as versões do Mac OS X de 10.4 a 10.8.
Marcar essa opção modificará o direito system.preferences e definirá shared como false.
Se um direito não é compartilhado, isso significa que todo processo precisa obter sua própria autorização. Como obter autorização exige que o usuário digite a senha de um Administrador, o ataque pode ser percebido pelo usuário.
Além disso, simplesmente executar sudo terá o mesmo efeito, o que torna este ataque inútil.
Na verdade não. À primeira vista pode parecer, porque está em um PrivateFramework rodando como root e não fazendo a autenticação adequada.
Mas o problema real aqui é mais de design ruim. A Apple queria garantir que todo usuário Administrador tenha a capacidade de usar as Preferências do Sistema ao máximo e no Unix tudo precisa de um arquivo de configuração e eles precisam ser escritos (na maioria das vezes como root).
Alguém pode argumentar que isso é uma má ideia (eu concordaria), mas eu não consideraria um backdoor, já que a autenticação está funcionando corretamente e todo Administrador pode obter root via sudo de qualquer forma.
O principal problema aqui é que a Apple pesou conforto sobre segurança, mas isso também não é algo muito especial para eles fazerem.