Na última década, a comunidade OpenJDK tornou o Java significativamente mais seguro para os usuários, ao mesmo tempo em que simplificou o processo de desenvolvimento para engenheiros de software. Essa combinação resultou em menos problemas de segurança e um processo mais claro para lidar com os inevitáveis problemas de segurança que acontecem com todos os softwares.
Um Java Development Kit (JDK) seguro que corrige vulnerabilidades de forma rápida e lança conforme o planejado
O Java Development Kit é lançado quatro vezes por ano, seguindo um cronograma pré-publicado. Cada lançamento faz melhorias padrão, bem como corrige quaisquer novos riscos de segurança. O dedicado OpenJDK Vulnerability Group ajuda a triar e priorizar vulnerabilidades para que elas possam ser corrigidas com a rapidez apropriada. Essa coordenação com pesquisadores que relatam vulnerabilidades garante que a correção seja realizada em tempo hábil.
Um JDK seguro não significa aquele em que não ocorrem vulnerabilidades; significa que, quando ocorrem, elas são tratadas prontamente e corretamente.
Patches agendados
Segurança e melhorias são lançadas quatro vezes por ano, todas em datas pré-publicadas. Essas datas permitem que gerentes de projeto e outros programem patches Java como uma atividade trimestral conhecida. Em vez de assinar uma lista de e-mail e reagir a alertas, os usuários podem reservar um tempo na terceira terça-feira ou depois dela a cada três meses: janeiro, abril, julho e outubro.
Uma parte crucial para abordar e corrigir vulnerabilidades é manter o controle do que elas são e contar às pessoas sobre elas. Uma parte fundamental do trabalho comunitário é atribuir crédito aos pesquisadores que encontram problemas de segurança e os divulgam adequadamente para ajudar projetos de código aberto.
Avisos sobre Vulnerabilidades e Exposições Comuns (CVEs)
O OpenJDK Vulnerability Group mantém uma lista dos CVEs corrigidos em cada versão Java , com reconhecimentos aos diferentes pesquisadores que se envolveram em divulgação responsável. Isso oferece aos usuários Java downstream a capacidade de responder a uma pergunta simples: Se eu usar uma versão anterior do Java, que risco aceito ao fazer isso?
Outro aspecto excelente que o OpenJDK Vulnerability Group faz nesses avisos é rastrear CVEs por componente, já que nem todos os usuários Java aproveitam todos os componentes.
Resumindo, simplesmente dizer que uma instalação mais antiga do Java contém um CVE não é suficiente para indicar que a vulnerabilidade existe naquele sistema.
Nomeação consistente
No início de 2019, a distribuição primária do OpenJDK no Docker estava servindo " mystery meat Java ", uma compilação do código-fonte tirada de sincronia com o cronograma de patches que perdeu vários patches de segurança, mas ainda usava o número da versão do JDK que continha as falhas de segurança. Como resultado, os usuários da imagem do Docker ficaram inseguros, enquanto os usuários de distribuições Java downstream conhecidas ficaram seguros.
Ao reconhecer a necessidade de divulgação de vulnerabilidades e usar a cadência de patch trimestral pré-publicada, os fornecedores Java que trabalham no OpenJDK giram em torno do mesmo esquema de numeração via JEP 322 (time-based release versioning). Por meio da coordenação de números de versão centralizados em torno do cronograma de patch trimestral, a maioria dos fornecedores Java usa os mesmos números de uma forma que podem ser compreendidos e comparados entre si para saber qual foi lançado depois e quais patches de segurança estão presentes naquela versão.
A alternativa a essa coordenação seria uma situação de números semiprevisíveis, mas sem sentido, que exigiriam tabelas de consulta especiais para saber quais patches de segurança estavam presentes onde.
Um JDK baseado em módulo diminui a superfície de ataque
A documentação original para Java 8 e abaixo fornece um diagrama conceitual de onde certos recursos estão. De uma perspectiva de modelagem de ameaças, esse é o mesmo local onde as vulnerabilidades vivem.
Algumas fatias são facilmente identificáveis:
- O risco de downloads ou execuções drive-by concentra-se apenas no Plug-in de Implantação, que não está mais disponível em ambientes de execução Java (JREs) modernos.
- A injeção de SQL só pode ocorrer se o aplicativo usar Java Database Connectivity (JDBC). Aplicativos que não usam SQL não são vulneráveis à injeção de SQL.
- Ataques contra XML, como XXE, ocorrem dentro da área XML JAXP.
- Ataques de desserialização derivam do componente de desserialização e das estruturas de IO.
O benefício para desenvolvedores e aqueles que executam aplicativos é que se torna possível olhar para um aplicativo e reduzir as coisas com as quais você deve se preocupar para as coisas que você usa. Isso enfatiza a importância das informações do módulo dentro dos avisos de segurança trimestrais do OpenJDK Vulnerability Group.
Reduzindo o risco removendo módulos
Hackers não podem atacar o que não está lá. Em vez de defender aplicativos contra inúmeras ameaças, simplesmente remover módulos desnecessários fornece 100% de mitigação de qualquer ameaça que exija aquele módulo.
Um diagrama conceitual define a aparência desses módulos e como eles se relacionam entre si. Desenvolvedores que criam um aplicativo ou serviço podem usar ferramentas como jlink para criar JREs personalizados que removem certos módulos.
Removendo JDBC (banco de dadosconectividade) impedirá que ataques de injeção de SQL funcionem porque as consultas ao banco de dados não estarão mais lá. A remoção do ImageIO evitará quaisquer vulnerabilidades relacionadas à imagem, como CVE-2020-14562. Esse CVE estava no ImageIO, então quando o ImageIO é removido, não há mais superfície de ataque. A remoção da área XML JAXP atenua as vulnerabilidades do XXE, pois o XML não está mais presente.
Quando a modularidade é usada, a segurança padrão de um JDK é muito mais forte. Uma versão do JDK que é sinalizada como "vulnerável" pode não ser realmente vulnerável.
Uma comunidade gerenciada possui claramente bibliotecas de software
A maioria das dependências Java vem do Maven Central, onde as bibliotecas são compostas de três partes: um grupo, um artefato e uma versão. Ao fornecer um nível claro de propriedade, a Sonatype, que executa o Maven Central, criou um ambiente onde os desenvolvedores Java não precisam realmente se preocupar com ataques como confusão de dependência que ocorrem em outras comunidades.
Todas as dependências do Maven são identificadas por uma combinação de três coisas: grupo, artefato e versão. O grupo representa um namespace, geralmente usando o estilo DNS reverso do Java. Para publicar um artefato, os desenvolvedores precisam de algum nível de conexão com o namespace. Por exemplo, um desenvolvedor que trabalha para example.com não poderia publicar artefatos em um grupo estabelecido (não com.example) onde não tinha afiliação.
Além disso, ter uma fonte primária de bibliotecas bloqueia outra série de obter componentes de lugares aleatórios na internet, onde os domínios expiram e são vendidos. Isso aconteceu na comunidade JavaScript, onde uma empresa comprou a Polyfill e substituiu a biblioteca original por um novo código que foi imediatamente servido a centenas de milhares de sites. Quando o código é trocado ou os grupos não correspondem, o Java torna muito fácil de detectar.
