Uma das coisas mais comuns nos portais de tecnologia nacionais é repercutir as coisas sem muita análise. Isto ocorre porque depois do advento do viver de blog, boa parte dos blogueiros por aí não tem grande conhecimento sobre o que estão falando e portanto, repercutem notícias que não sofreram grande análise.

Com isto, algumas coisas ganham o corpo que não deveriam. Principalmente porque virou moda agora dar nome aos bugs,  e com isto  o novo bug acabou ganhando o nome de Grinch , e a mídia , seguindo a cartilha do terrorismo digital atual,  alega que ele  tem grande impacto em todas as organizações que usam o Linux.

Com tudo isto, este foi o ano dos bugs de software e que muitas das vezes ganharam um corpo excessivo por causa da mídia, e, também principalmente porque  ganharam nomes bem fofos e acabaram ficando no imaginário popular. Os nomes foram  Shellshock, Heartbleed, POODLE e por aí vai.

O que leva a esta caça do Santo Graal é que  como tais bugs dão muita divulgação para as empresas que os descobrem, e aí,  todos querem achar o bug da vez. E infelizmente, parece que o pessoal que alega que o “Grinch” é um bug tal qual o Shellshock ou até o Heartbleed parece que está fazendo um pouco de FUD.

E o Louco Por Android está aqui para lhe ajudar a entender realmente os fatos reais por trás da falha Grinch e porque talvez gere  problemas tanto para o Android  quanto para o Linux ( mas nada que é tão ‘preocupante’ assim tal qual estão dizendo por aí ).

O PolicyKit não pede sua senha … porque foi projetado para não pedir sua senha

A coisa começa com problema porque parece que ou o pessoal não leu o relatório ou simplesmente reverberou algum texto qualquer.  No relatório a empresa alega que há uma falha com o framework PolicyKit no Linux ( que é sem dúvida uma parte muito importante do sistema operacional ).

O que é alegado é que a escalada de privilégios usando este framework não exige credenciais e por isto, haveria a possibilidade de haver uma “escalada de privilégios” por um software malicioso com credenciais válidas em um sistema.

O grande problema está aí. Na realidade o PolicyKit é feito para funcionar assim.

Por design podemos pensar nele como um setuid, ou o famoso “sudo NOPASSWD”.

Ele por projeto foi feito para permitir que aplicativos executados em contas normais do sistema possam executar algumas ações com privilégios de root ou administrador ( tal qual o sudo e o setuid ).

Esta foi uma idéia que foi implementada no Linux e herdada pelo Android ( pelo menos é o que alegam os portais, mas vamos entender mais tarde que não é bem assim ),  pois permite que haja uma melhor experiência de usuário em uma área de trabalho. Ou seja, coisas como montar uma unidade que antes você teria que entrar a senha de superusuário, não são mais necessárias.

Aliás, como pode ser visto os exemplos que dei são para tarefas de usuários e portando, tendem a ser um padrão quando falamos de desktops.

O pessoal do PolicyKit fala um pouco sobre isto em sua documentação.

Não é muito sábio exigir que os usuários tenham que autenticar para algumas tarefas básicas como adição de uma fila de impressão ( se o administrador realmente quer que o sistema operacional se comporte desta forma ele sempre pode implantar uma série de outras regras de autorização adequadas ).

O tal “exploit” que foi divulgado pela empresa referencia uma ferramenta chamada pkcon que é usada para efetuar a instalação de um pacote malicioso e faz uso do PolicyKit para evitar que sejam solicitadas credenciais para o usuário.

O que ocorre ( pelo menos na versão deles ) é que se as credenciais de um usuário foram roubadas e o repositório de gerenciamento contenha algum pacote malicioso o pkcon poderia ser utilizado para instalar este software sem a necessidade de confirmação por parte do utilizador.

Agora, pense só. Se você  é administrador e permite que um usuário comum consiga instalar softwares no seu servidor você precisa rever suas práticas.

E, veja só. Se há a permissão de instalação de softwares através da confiança nos seus usuários no seu sistema de softwares usand o PolicyKit você está de caso pensado ignorando a autenticação e o controle de acesso que existe no Linux.

Aliás, a Red Hat confirmou isto ao analisar a vulnerabilidade.

Não, o Grinch não é uma falha do Kernel do Linux

Houve um erro bem grande na maioria das divulgações por aí porque este não é um problema do Kernel do Linux. Este sim é um problema de uma aplicação que permite que um usuário burle os mecanismos de autenticação de controle e acesso construídos no Linux.

O que pode ser argumentado é quanto a existência ou não de limitações de projeto de controle de acesso no Linux que foi criado para melhorar a experiência do usuário no framework PolicyKit. Aliás uma falha bem estranha porque no fim o PolicyKit está fazendo aquilo para o qual ele foi criado.

O que eu acho é que deve-se realmente criar cenários mais aceitáveis e realmente ter uma melhor precisão do alcance real do bug e no fim, suas possíveis correções.

O que ocorre é que há 2 responsáveis que devem estar atentos a este tipo de falha. Primeiro os mantenedores de aplicativos e desenvolvedores que devem garantir que estão realmente utilizando o framework adequadamente.

Coisa que aliás é obrigatório para boa parte dos programas do Linux que ganham privilégios de superusuário.

Exemplos destas aplicações são aquelas do setuid bit  para rodar como superusuário ( root ) que devem ter as permissões configuradas de modo correto ( um exemplo é o passwd de mudança de senha ).

E estas aplicações tem sempre que possuir uma forte análise de impacto pois como trabalham com privilégios de superusuário podem causar grandes problemas.

E o segundo, é o elemento humano. Ou seja, o cara que fica entre a cadeira e o teclado. Se você é SysAdmin ou seja, administrador de sistemas tome a responsabilidade nas suas mãos, evite o excessivo uso das facilidades gráficas e implemente melhores práticas de segurança e autenticação no sistemas que administra.

Se você é usuário tome cuidado com os repositórios que adiciona ao seu sistema e sempre observe tudo que esta sendo feito no seu Desktop ( por você e pelo que você instala ) .

Não, o Grinch não pode ser comparado ao ShellShock

Estava agora a pouco lendo muitos blogs que falam sobre esta falha e é um pouco assustador notar o nível de sensacionalismo que isto alcançou. Aliás, ficou cool falar sobre falhas de modo a gerar muito medo por parte dos usuários.

E, portanto, vamos lá. Não há como comparar o Grinch ao Shellshock por exempo. Sabe porque ? Porque o bash ( /bin/bash ) está instalado em praticamente 100% dos servidores, desktops e sistemas operacionais baseados no Linux ( para não dizer praticamente todos os Unix Like ) .

Portanto, qualquer falha em algo que está tão ligado ao Linux é um grande problema não é ?

Já o PolicyKit não é bem assim. Ele não tende a estar instalado em servidores e sim em Desktops que possuem a interface gráfica já que os usuários precisam interagir com diversas coisas que no servidor só serão feitas por um administrador de sistemas.

Assim, em servidores o PolicyKit não terá um impacto tão grande e portanto, não  pode ser nunca comparado as outras reais falhas que apareceram nos últimos tempos.

Analisando sua possível vulnerabilidade ao Grinch

1. Vendo se você está realmente usando o PolicyKit no seu sistema

Em geral você deverá estar utilizando muito pouco o PolicyKit no seu sistema operacional Linux mas é facil mapear quais os software utilizam o PolicyKit.

Se você usa distros Debian based tal qual o Ubuntu:

E estes comandos são para quem usa distribuições baseadas no Red Hat e que usam o Yum:

2. Utilizar outros softwares já conhecidos pelos Administradores de Sitemas para fazer o que o PolicyKit faz

Sim, na maioria dos casos é possível usar outros aplicativos para realizar as mesmas tarefas do PolicyKit e ainda fazer tudo de modo que ele peça as credenciais antes de executar qualquer tarefa.

Por exemplo, ao invés de usar o pkcon ( o tal software explorável ) você pode usar o antigo e sempre útil “sudo” com uma configuração que irá pedir a senha e um gerenciador de pacotes padrão para instalar o software ( e no sudo limitar os comandos que aquele usuário poderá executar).

Só com isto boa parte dos problemas que são alegadamente possíveis irão ser resolvidos ( mas devo lembrar que até agora não entendi aonde acharam tanto motivo para tanto alarde ).

Concluindo  …

A conclusão final é que o PolicyKit está funcionando do jeito pelo qual ele foi projetado para funcionar, ou seja, ele é realmente um projeto que foi feito para contornar os mecanismos de autenticação do Linux.

Portanto, é importante que um dos elementos mais importantes deste processo, o administrador de sistemas ou usuário esteja ciente dos riscos que se está introduzindo ( bem como as benesses ) de tomar estes atalhos ( facilidades ) que burlam algumas das camadas de segurança para tornar o processo mais amigável em estações de trabalho e servidores Linux.

Na minha opinião a falha foi um pouco valorizada demais e no fim, não é tudo o que foi prometido.

Como eu disse no iníco do artigo me parece somente uma empresa tentando ganhar fama com uma falha e valorizando isto através do sensacionalismo da imprensa

E no Android ?

Eu deixei o Android para o final porque ele não é vulnerável ao Grinch. Sim, crianças, ao contrário do que você leu em boa parte dos blogs e sites especializados esta falsa  falha não ataca o Android.

Isto porque o Android não usa o PolicyKit e muito menos o grupo “wheel”, mas ele faz uso extensivo do group auth.

Ou seja, particularmente acredito que boa parte do erro de envolver o Android neste tipo de vulnerabilidade ocorreu do erro de reverberar o mantra de que esta falha era uma falha do Kernel do Linux.

Sendo assim, espero que tenhamos resolvido as dúvidas que possam ter ficado em relação ao Grinch e deixar os usuários de Android tranquilos já que a falha só irá mesmo dar uma pequena dor de cabeça  para os usuários de Linux e Administradores de estruturas que utilizem este sistema operacional ( apesar de que, para os SysAdmins a maior dor de cabeça mesmo será explicar para os seus gerentes que a falha na realidade não é bem uma falha ).

Via ThreatStack