Segurança Java - Java security

A plataforma Java fornece vários recursos projetados para melhorar a segurança dos aplicativos Java. Isso inclui impor restrições de tempo de execução por meio do uso da Java Virtual Machine (JVM), um gerenciador de segurança que protege códigos não confiáveis ​​do resto do sistema operacional e um conjunto de APIs de segurança que os desenvolvedores Java podem utilizar. Apesar disso, as críticas têm sido dirigidas à linguagem de programação e à Oracle, devido ao aumento de programas maliciosos que revelaram vulnerabilidades de segurança na JVM, que posteriormente não foram devidamente abordadas pela Oracle em tempo útil.

Recursos de segurança

O JVM

A forma binária de programas executados na plataforma Java não é um código de máquina nativo, mas um bytecode intermediário . A JVM executa a verificação neste bytecode antes de executá-lo para evitar que o programa execute operações não seguras, como ramificação para locais incorretos, que podem conter dados em vez de instruções. Também permite que a JVM aplique restrições de tempo de execução, como verificação de limites de matriz . Isso significa que os programas Java são significativamente menos propensos a sofrer com falhas de segurança de memória , como estouro de buffer, do que programas escritos em linguagens como C, que não oferecem tais garantias de segurança de memória.

A plataforma não permite que programas executem certas operações potencialmente inseguras, como aritmética de ponteiro ou conversão de tipo não verificada . Também não permite controle manual sobre a alocação e desalocação de memória; os usuários devem contar com a coleta de lixo automática fornecida pela plataforma. Isso também contribui para a segurança do tipo e da memória.

Gerente de segurança

A plataforma fornece um gerenciador de segurança que permite aos usuários executar bytecode não confiável em um ambiente "sandbox" projetado para protegê-los de softwares mal-intencionados ou mal escritos, evitando que códigos não confiáveis ​​acessem certos recursos e APIs da plataforma. Por exemplo, código não confiável pode ser impedido de ler ou gravar arquivos no sistema de arquivos local, executar comandos arbitrários com os privilégios do usuário atual, acessar redes de comunicação, acessar o estado privado interno de objetos usando reflexão ou fazer com que a JVM saia.

O gerenciador de segurança também permite que programas Java sejam assinados criptograficamente ; os usuários podem optar por permitir que o código com uma assinatura digital válida de uma entidade confiável seja executado com todos os privilégios em circunstâncias em que, de outra forma, não seria confiável.

Os usuários também podem definir políticas de controle de acesso refinadas para programas de diferentes fontes. Por exemplo, um usuário pode decidir que apenas as classes do sistema devem ser totalmente confiáveis, que o código de certas entidades confiáveis ​​pode ter permissão para ler certos arquivos específicos e que todos os outros códigos devem ser totalmente protegidos.

APIs de segurança

A Java Class Library fornece várias APIs relacionadas à segurança, como algoritmos criptográficos padrão , autenticação e protocolos de comunicação seguros.

Fontes potenciais de vulnerabilidades de segurança em aplicativos Java

Existem várias fontes possíveis de vulnerabilidades de segurança em aplicativos Java, algumas das quais são comuns a aplicativos não Java e outras específicas da plataforma Java. (Observe que se referem a fontes potenciais de vulnerabilidades que precisam ser mantidas em mente por programadores preocupados com a segurança: isso não se destina a ser uma lista de vulnerabilidades reais .)

Exemplos de fontes potenciais de vulnerabilidade comuns a aplicativos Java e não Java são:

  • Vulnerabilidades nos mecanismos de proteção fornecidos pelo hardware ou sistema operacional em que o aplicativo depende para sua segurança
  • Vulnerabilidades em bibliotecas nativas, como a biblioteca padrão C , que pode ser usada para implementar o aplicativo e / ou tempo de execução
  • Vulnerabilidades causadas puramente por erros em programas do usuário (por exemplo, construção inadequada de consultas SQL que levam a vulnerabilidades de injeção de SQL )

No entanto, muitas discussões sobre a segurança Java se concentram nas fontes potenciais de vulnerabilidade específicas da plataforma Java. Esses incluem:

  • Vulnerabilidades no mecanismo de sandbox que permitem bytecode não confiável contornar as restrições impostas pelo gerenciador de segurança
  • Vulnerabilidades na biblioteca de classes Java das quais um aplicativo depende para sua segurança

Uma vulnerabilidade na plataforma Java não tornará necessariamente todos os aplicativos Java vulneráveis. Quando vulnerabilidades e patches são anunciados, por exemplo pela Oracle, o anúncio normalmente conterá uma análise de quais tipos de aplicativos são afetados ( exemplo ).

Por exemplo, uma falha de segurança hipotética que afeta apenas o mecanismo de sandbox do gerenciador de segurança de uma implementação JVM particular significaria que apenas os aplicativos Java que executam bytecode arbitrário não confiável seriam comprometidos: aplicativos onde o usuário confia totalmente e controla todos os bytecodes sendo executados não. Isso significaria que, digamos, um plug-in de navegador da web baseado nessa JVM seria vulnerável a miniaplicativos maliciosos baixados de sites públicos, mas um aplicativo da web do lado do servidor executado na mesma versão da JVM onde o administrador tem controle total sobre o classpath não seria afetado. Como ocorre com os aplicativos não Java, as vulnerabilidades de segurança podem originar-se de partes da plataforma que podem inicialmente não parecer relacionadas à segurança. Por exemplo, em 2011, a Oracle lançou uma correção de segurança para um bug no Double.parseDoublemétodo. Este método converte uma string como "12,34" no número de ponto flutuante de precisão dupla equivalente . O bug fazia com que esse método entrasse em um loop infinito quando chamado em uma entrada específica. Este bug tinha implicações de segurança, porque, por exemplo, se um servidor web converte uma string digitada em um formulário pelo usuário usando este método, um usuário malicioso pode digitar a string que dispara o bug. Isso faria com que o thread do servidor da Web que está processando a solicitação maliciosa entre em um loop infinito e se torne indisponível para atender às solicitações de outros usuários. Fazer isso repetidamente em um servidor da web vulnerável seria um ataque de negação de serviço fácil : todos os threads do servidor da web para responder às solicitações do usuário logo ficariam presos no loop infinito e o servidor da web seria incapaz de atender a qualquer usuário legítimo em tudo.

Críticas ao gerente de segurança

O gerenciador de segurança na plataforma Java (que, como mencionado acima, é projetado para permitir que o usuário execute bytecode não confiável) foi criticado nos últimos anos por tornar os usuários vulneráveis ​​a malware , especialmente em plug-ins de navegador da web que executam miniaplicativos Java baixados de sites públicos, mais informalmente conhecidos como "Java no navegador".

Os esforços da Oracle para resolver essas vulnerabilidades resultaram em um atraso no lançamento do Java 8.

2012

Um cavalo de Troia do OS X conhecido como Flashback explorava uma vulnerabilidade em Java, que não havia sido corrigida pela Apple , embora a Oracle já tivesse lançado um patch. Em abril, a Apple lançou posteriormente uma ferramenta de remoção para usuários do Lion sem Java. Com o Java 7 Update 4, a Oracle começou a lançar o Java diretamente para o Lion e posteriores .

Em outubro, a Apple lançou uma atualização que removeu o plugin Java de todos os navegadores . Isso foi visto como um movimento da Apple para distanciar o OS X do Java.

2013

Em janeiro, uma vulnerabilidade de dia zero foi encontrada em todas as versões do Java 7, incluindo a versão mais recente do Java 7 Update 10, que já foi explorada em liberdade. A vulnerabilidade foi causada por um patch para corrigir uma vulnerabilidade anterior. Em resposta, a Apple colocou na lista negra a versão mais recente do plug-in Java. A Oracle lançou um patch (atualização 11) em três dias. A Microsoft também lançou um patch para as versões 6 , 7 e 8 do Internet Explorer .

O malware Cyberespionage Red October foi encontrado explorando uma vulnerabilidade Java corrigida em outubro de 2011. O site do Reporters Without Borders também foi comprometido por uma vulnerabilidade Java em versões anteriores à atualização 11.

Após o lançamento da atualização 11, outra vulnerabilidade começou a circular online, o que foi confirmado posteriormente. Também foi descoberto que o próprio modo de segurança do Java era vulnerável devido a um bug. Em resposta, a Mozilla desativou o Java (bem como o Adobe Reader e o Microsoft Silverlight ) no Firefox por padrão, enquanto a Apple colocou na lista negra o plugin Java mais recente novamente.

Em fevereiro, o Twitter informou que havia encerrado um ataque. O Twitter aconselhou os usuários a desabilitar o Java, embora não explicasse o porquê. No final do mês, o Facebook relatou que havia sido hackeado por um ataque Java de dia zero. A Apple também relatou um ataque. Foi descoberto que uma violação de um fórum de desenvolvedores do iPhone foi usada para atacar o Twitter, o Facebook e a Apple. O próprio fórum desconhecia a violação. Seguindo o Twitter, Facebook e Apple, a Microsoft relatou que também estava comprometido da mesma forma.

Outra vulnerabilidade descoberta permitiu que a sandbox de segurança do Java fosse completamente contornada no lançamento original do Java 7, bem como nas atualizações 11 e 15. Em março, um trojan chamado McRat foi encontrado explorando uma vulnerabilidade de dia zero do Java. A Oracle então lançou outro patch para resolver a vulnerabilidade.

Veja também

Referências

links externos