O Google Project Zero censura a Samsung e outros fornecedores por adicionar recursos que prejudicam a segurança do Android. A tentativa da Samsung de impedir ataques aos telefones Galaxy modificando o código do kernel acabou expondo a mais bugs de segurança, de acordo com o Google Project Zero (GPZ). Portanto, segurança do kernel no Android está em risco.
Sendo o maior OEM do Android, a Samsung e o Google geralmente são parceiros próximos. O Project Zero, do Google, tem a tarefa de encontrar bugs e explorações de segurança. Nesta semana, o Google está chamando a Samsung para um problema no Galaxy A50, mencionando especificamente as “mudanças desnecessárias” da Samsung no núcleo do Android.
Não apenas os fabricantes de smartphones como a Samsung estão criando mais vulnerabilidades adicionando drivers personalizados para acesso direto ao hardware do kernel Linux do Android. No entanto, os fornecedores estariam usando recursos de segurança que já existem no kernel Linux, de acordo com o pesquisador da GPZ Jann Horn.
Jann Horn, do Google, explica essa preocupação com o kernel Android da Samsung no Galaxy A50. Todo dispositivo Android faz alterações no kernel Linux do Android para funcionar corretamente, pois as alterações específicas do dispositivo são importantes e até necessárias em muitos casos. No entanto, algumas das mudanças da Samsung aparentemente estão criando mais vulnerabilidades.
Foi esse tipo de erro que Horn encontrou no kernel do Android no Samsung Galaxy A50. Porém, como ele observa, o que a Samsung fez é bastante comum entre todos os fornecedores de smartphones. Ou seja, é comum adicionar mais código ao kernel Linux que os desenvolvedores do kernel ainda não revisaram.
Google apela para Samsung parar de mexer com o código do kernel Linux
Mesmo quando essas personalizações posteriores pretendem adicionar segurança a um dispositivo, elas também introduzem bugs de segurança. As mitigações de segurança de kernel pretendidas pela Samsung introduziram um bug de corrupção de memória que o Google relatou à Samsung em novembro.
Foi corrigido na recém-lançada atualização de fevereiro da Samsung para os telefones Galaxy. O problema afeta o subsistema de segurança extra da Samsung chamado PROCA ou Process Authenticator.
A Samsung descreve o bug, SVE-2019-16132, como um problema moderado que consiste em vulnerabilidades de uso após livre e dupla liberação no PROCA que permitem “possível execução arbitrária de código” em alguns dispositivos Galaxy com Android 9.0 e 10.0.
Aliás, a atualização de fevereiro também inclui um patch para uma falha crítica nos “dispositivos TEEGRIS”, referindo-se ao Trusted Execution Environment (TEE) em telefones Galaxy mais recentes que contêm o sistema operacional TEE proprietário da Samsung. O Galaxy S10 está entre os dispositivos TEEGRIS.
Mexer demais atrapalha
Um novo post do Horn está focado nos esforços do Android para reduzir o impacto na segurança dos fornecedores que adicionam código exclusivo ao kernel.
O Android reduz o impacto na segurança desse código, bloqueando quais processos têm acesso a drivers de dispositivos, geralmente específicos de cada fornecedor, explica Horn.
Um exemplo é que os telefones Android mais recentes acessam o hardware por meio de processos auxiliares dedicados, conhecidos coletivamente como HAL (Hardware Abstraction Layer) no Android. No entanto, Horn diz que os fornecedores que modificam o funcionamento das partes principais do kernel Linux prejudicam os esforços para “bloquear o ataque”.
Em vez disso, ele sugere que os fabricantes de celulares usem recursos de acesso direto ao hardware já suportados no Linux, em vez de personalizar o código do kernel do Linux.
Horn diz que alguns dos recursos personalizados adicionados pela Samsung são “desnecessários” e não afetariam o dispositivo se fossem removidos.
Mais eficiência
Ele especulou que o PROCA deveria restringir um invasor que já obteve acesso de leitura e gravação no kernel. Mas ele acha que a Samsung poderia ser mais eficiente direcionando recursos de engenharia para impedir que um invasor obtenha esse acesso em primeiro lugar.
Acredito que as modificações do kernel específicas do dispositivo estariam melhor sendo lançadas ou movidas para os drivers do usuário, onde elas podem ser implementadas em linguagens de programação mais seguras e/ou em área restrita e, ao mesmo tempo, não complicam as atualizações das versões mais recentes do kernel, explicou Horn.
Fonte: ZDNet
