Come convincere il mio amministratore che Java SU UN SERVER non è di per sé sicuro?

L'applicazione

Abbiamo una piccola applicazione Java che utilizza alcune rotte di Camel per raccogliere i file caricati da un server web, elaborarli e inviare alcune e-mail con i risultati.

Il server su cui era in esecuzione questa applicazione è stato sospeso. Per ora dobbiamo eseguirlo su hardware sottodimensionato, perché non riesco a convincere l'amministratore a installare un JRE sul server web (che in realtà è un server multiuso).

Il timore

Sono un tecnico delle applicazioni Java, scrivo codice JEE per vivere, gestendo transazioni B2B per decine di migliaia di € uro a settimana. Ma ho problemi a trovare fonti credibili che confutano il mito che Java non è sicuro di per sé.

I due principali argomenti dell'amministratore contro l'installazione di un JRE:

1. Le applicazioni Java consumano tutta la mia RAM
2. Java è piena di vulnerabilità

La verità?

Quando si tratta di applicazioni Java che mangiano ariete. Bene ... direi che dobbiamo impostare i valori corretti per Xmx. Fatto.

Ora ci sono molte fonti che parlano delle molte vulnerabilità di Java. Queste fonti mirano principalmente agli utenti finali che gestiscono un determinato sistema operativo da una società di Redmond / USA. AFAIK potrebbe essere vero per le versioni senza patch del plug-in Java Browser che è configurato per eseguire automaticamente tutte le applet, che ci sono abbastanza grandi probabilità di essere vittima di un'unità da infezione. Proprio come c'è il rischio di contrarre un STD quando si fa sesso non protetto con un veicolo elettronico sul treno mentre si reca al lavoro.

Ma non sono riuscito a trovare nessuno nel mondo interwebz che parla di applicazioni server o JRE senza testa. Questa è un'altra cosa.

O mi sto perdendo qualcosa qui?

[modifica 2014-08-28] chiarimento: sono preoccupato solo per Java sui server. Non mi interessano i problemi con il plugin Java e / o il software specifico sviluppato in Java.

La superficie di sicurezza aggiuntiva che java mette nel tuo ambiente è complessa ed è importante non ignorarlo o cercare di semplificarlo.

In primo luogo, c'è l'orribile record che JRE ha per avere bug di sicurezza. È difficile indicarne uno specifico, e questa è la parte spaventosa: i bug sono vulnerabilità straordinariamente non specificate con vettori non specificati.

Quando io, in qualità di consulente per la sicurezza, leggo clausole come "consente a un utente malintenzionato remoto" senza ulteriori qualifiche sul loro significato, vedo che potrebbe benissimo significare che alcuni parametri che entrano in una determinata funzione potrebbero invocare la condizione vulnerabile, anche se tu stanno eseguendo solo il codice che hai scritto. E, poiché non sono specificati, non puoi sapere se sei stato colpito.

Ancora meglio, il canonico JRE pubblicato da Oracle ha un ciclo di aggiornamento trimestrale dichiarato per gli aggiornamenti critici, inclusi quasi tutti gli aggiornamenti di sicurezza. Hanno creato patch fuori ciclo per un totale di 11 volte negli ultimi quattro anni. Ciò significa che esiste la possibilità che tu possa essere vulnerabile a un bug di sicurezza fino a tre mesi dopo che è stato segnalato prima che tu abbia modo di risolverlo.

Ci sono altri problemi con Java che non entrerò qui, ma in realtà sembra che ci sia una preoccupazione giustificabile, specialmente per un server multiuso. Se devi eseguire tali cose, dovresti almeno creare una VM monouso e isolarla da altre cose.

In particolare, se nel JRE c'è un telecomando che consente a un attaccante di ottenere RCE, e un altro in PHP che fa lo stesso, e un altro in Ruby che fa di nuovo lo stesso, devi patchare tutti e tre. Tutti e tre sembrano alquanto probabili, man mano che queste cose vanno, e l'attaccante può scegliere quello che è più conveniente e quindi possedere l'intero server. Ecco perché dovremmo usare le macchine virtuali per separare il software, in particolare i software difettosi come i framework dei linguaggi gestiti e in particolare quelli che raggruppano le patch di sicurezza solo quattro volte l'anno e sono proprietari di un fornitore che afferma di fronte a tutte le prove che sono un esempio di sicurezza.

Per aggiornare, ecco alcuni CVE che ho scelto dalla ricerca CVE collegata di ChrisS, a titolo dimostrativo.

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5884
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5910
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-5456
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-3007
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2454
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2447
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1557

E il mio preferito, da quando ero lì:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1488

Questo è solo un piccolo campionamento, comunque.

Le applicazioni Java consumano tutta la mia RAM

L'alternativa all'utilizzo della RAM è lo spreco di RAM. Non puoi salvarlo per dopo.

Java è piena di vulnerabilità

Non importa davvero perché non hai intenzione di esporre la JVM al mondo. Presumo che non eseguirai alcun programma ostile e, se lo sei, Java è più sicuro della maggior parte delle altre lingue. Ciò che conta è se le tue applicazioni presentano vulnerabilità.

Assumi un'azienda per eseguire analisi statiche sul tuo programma. Veracode, ad esempio, è una società che ho usato in passato per il controllo della sicurezza del codice dei programmi Java, in particolare.

Fatturare il codice di addebito del team di amministrazione, ovviamente.

Spiega che tutti gli altri linguaggi (o macchine virtuali) possono essere resi non sicuri dal codice che viene distribuito su di essi, proprio come con Java. Se pensa che le altre piattaforme siano intrinsecamente sicure (o più sicure di Java) senza affrontare correttamente la sicurezza, allora è delirante.

La tua azienda ovviamente ha investito nell'assunzione di uno sviluppatore Java, perché l'amministratore di sistema si rifiuta di supportare una tecnologia che l'azienda ha deciso di utilizzare?

Capovolgere la domanda e chiedergli quali alternative propone e come sono più sicure rispetto all'ultimo Server JRE disponibile, in termini molto specifici. Nel frattempo, lavora per mostrarti di capire la tua tecnologia, la possibile superficie di attacco e che hai lavorato per minimizzarla (ad esempio framework non necessari, codice di terze parti, ecc.). Fai verificare il tuo codice, cerca le vulnerabilità pubblicate per i framework su cui fai affidamento negli ultimi X anni, confrontalo con altre lingue / framework (assicurati di includere anche la condivisione del mercato, i framework oscuri senza vulnerabilità pubblicate non significano nulla).

Non possiamo assolutamente sapere come sia avvenuta l'intera conversione tra voi due, ma se fossero i suoi due argomenti, credo che abbiate a che fare con un amministratore di sistema junior. Ha esperienza con i server delle applicazioni Java? Forse non è a suo agio con la tecnologia e ha paura di mettere qualcosa in produzione senza comprenderlo a fondo (buona attitudine da amministratore di sistema allora).