Como convencer meu Administrador de que o Java ON A SERVER não é inseguro por si?

Question

O aplicativo

Temos um pequeno aplicativo Java que usa algumas rotas Camel para pegar arquivos enviados de um servidor web, processá-los e enviar alguns e-mails com os resultados.

O servidor no qual este aplicativo estava sendo executado foi desmobilizado. Por enquanto, temos que executá-lo em hardware com pouca potência, porque não consigo convencer o administrador a instalar um JRE no servidor da Web (que, na verdade, é um servidor multiuso).

O medo

Eu mesmo sou engenheiro de aplicações Java, escrevo código JEE para ganhar a vida, lidando com transações B2B no valor de dezenas de milhares de euros por semana. Mas tenho problemas em encontrar fontes confiáveis que refutem o mito de que o java é inseguro por si só.

Os dois argumentos principais do administrador contra a instalação de um JRE:

1. As aplicações Java consomem toda a minha RAM
2. Java está cheio de vulnerabilidades

A verdade?

Quando se trata de aplicativos java comendo ram. Bem ... eu diria que temos que definir valores apropriados para o Xmx. Feito.

Agora, há muitas fontes falando sobre as muitas vulnerabilidades do Java. Essas fontes são principalmente destinadas a usuários finais que executam um determinado sistema operacional de uma empresa em Redmond / EUA. AFAIK pode ser verdade para versões não corrigidas do Java Browser Plugin que é configurado para executar todos os applets automaticamente, que há grandes chances de ser vítima de uma unidade por infecção. Assim como existe o risco de pegar uma doença sexualmente transmissível ao fazer sexo desprotegido com eveyone em seu trem enquanto viaja para o trabalho.

Mas não consegui encontrar ninguém no mundo inteiro que fala sobre aplicativos de servidor ou JREs executando sem cabeça. Isso é uma outra coisa.

Ou estou sentindo falta de alguma coisa aqui?

[editar 2014-08-28] esclarecimento: estou preocupado apenas com o Java nos servidores. Eu não me importo com problemas com o Plugin Java e / ou software específico desenvolvido em java.

    

Answer 1

A superfície de segurança adicional que o java coloca no seu ambiente é complexa, e é importante não ignorá-la ou tentar simplificá-la.

Primeiramente, há o registro horrível que o JRE tem para ter bugs de segurança. É difícil apontar uma específica, e essa é a parte assustadora - os bugs são vulnerabilidades esmagadoramente não especificadas com vetores não especificados.

Quando eu, como consultor de segurança, leio cláusulas como "permite um atacante remoto" sem mais qualificação quanto ao seu significado, vejo que isso pode muito bem significar que certos parâmetros que entram em uma determinada função podem invocar a condição vulnerável. mesmo se você estiver executando apenas o código que você escreveu. E, como eles não são especificados, você não fica sabendo se foi afetado.

Melhor ainda, o JRE canônico publicado pela Oracle tem um ciclo de atualização trimestral para atualizações críticas, incluindo quase todas as atualizações de segurança. Eles criaram patches do ciclo num total de 11 vezes nos últimos quatro anos. Isso significa que existe a possibilidade de você estar vulnerável a um bug de segurança até três meses depois de ser relatado antes de ter alguma forma de solucioná-lo.

Existem outros problemas com o java que não entendo aqui, mas, na verdade, parece que existe uma preocupação justificável, especialmente para um servidor multiuso. Se você tiver que executar essas coisas, você deve pelo menos criar uma VM de finalidade única e isolá-la de outras coisas.

Em particular, se houver um controle remoto no JRE que permita que um atacante ganhe RCE, e outro no PHP faça o mesmo, e outro em Ruby que faça o mesmo novamente, você terá que corrigir todos os três. Todos os três parecem um pouco prováveis, à medida que essas coisas acontecem, e o invasor escolhe o que for mais conveniente e, em seguida, possui o servidor inteiro. É por isso que devemos usar VMs para separar softwares, especialmente softwares com bugs, como frameworks de linguagem gerenciada, e especialmente aqueles que agrupam patches de segurança apenas quatro vezes por ano e são proprietários de um fornecedor que afirma em face de todas as evidências de que eles são um paradigma de segurança. segurança.

Para atualizar, aqui estão alguns CVEs que eu escolhi da pesquisa CVE vinculada do ChrisS, por meio de demonstração.

• link
• link
• link
• link
• link
• link
• link

E meu favorito, desde que eu estava lá:

• link

Isso é apenas uma pequena amostra, a propósito.

    

Answer 2

Java applications eat up all my RAM

A alternativa ao uso de RAM está perdendo memória RAM. Você não pode salvá-lo para mais tarde.

Java is full of vulnerabilities

Isso realmente não importa, porque você não vai expor a JVM ao mundo. Eu presumo que você não vai rodar nenhum programa hostil, e se você estiver, o Java é mais seguro que a maioria das outras linguagens. O que importa é saber se seus aplicativos têm vulnerabilidades.

    

Answer 3

Contrate uma empresa para fazer análises estáticas no seu programa. O Veracode, por exemplo, é uma empresa que eu usei no passado para auditar a segurança de código de programas Java, especificamente.

Anote o código de cobrança da sua equipe de administração, obviamente.

    

Answer 4

Explique que todos os outros idiomas (ou máquinas virtuais) podem ser tornados inseguros pelo código que é implementado neles, assim como com o Java. Se ele acha que as outras plataformas são inerentemente seguras (ou mais seguras que o Java) sem endereçar corretamente a segurança, então ele é delirante.

Sua empresa obviamente investiu na contratação de um desenvolvedor Java, por que o administrador de sistema se recusa a suportar uma tecnologia que a empresa decidiu usar?

Eu colocaria a pergunta e perguntaria a ele quais alternativas ele propõe e como elas são mais seguras do que o último Servidor JRE disponível, em termos muito específicos. Nesse meio tempo, trabalhe para mostrar que você entende sua tecnologia, a possível superfície de ataque e que trabalhou para minimizá-la (por exemplo, estruturas desnecessárias, código de terceiros etc.). Tenha seu código verificado, procure por vulnerabilidades publicadas para os frameworks nos quais você confia nos últimos X anos, compare-o com outras linguagens / frameworks (certifique-se de incluir marketshare também, frameworks obscuros sem vulnerabilidades publicadas não significam nada).

Não podemos saber como aconteceu toda a conversão entre vocês dois, mas se foram seus dois argumentos, acredito que você esteja lidando com um administrador de sistema júnior. Ele tem experiência com servidores de aplicativos Java? Talvez ele esteja desconfortável com a tecnologia e tenha medo de colocar algo em produção sem entendê-la completamente (boa atitude do administrador).