Comment convaincre mon administrateur que Java ON A SERVER n'est pas non sûr en soi?

L'application

Nous avons une petite application Java qui utilise des routes Camel pour récupérer les fichiers téléchargés d'un serveur Web, les traiter et envoyer des e-mails avec les résultats.

Le serveur sur lequel cette application s'exécutait a été mis hors service. Pour l'instant, nous devons l'exécuter sur du matériel sous-alimenté, car je ne peux pas convaincre l'administrateur d'installer un JRE sur le serveur Web (qui est en fait un serveur polyvalent).

La peur

Je suis moi-même ingénieur d'application Java, j'écris du code JEE pour une vie, en gérant des transactions B2B d'une valeur de plusieurs dizaines de milliers d'euros par semaine. Mais j'ai du mal à trouver des sources crédibles qui réfutent le mythe selon lequel java n'est pas sûr en soi.

Les deux principaux arguments de l'administrateur contre l'installation d'un JRE:

1. Les applications Java mangent toute ma RAM
2. Java regorge de vulnérabilités

La vérité?

En ce qui concerne les applications Java, manger de la RAM. Eh bien ... je dirais que nous devons définir des valeurs appropriées pour Xmx. Terminé.

Maintenant, de nombreuses sources parlent des nombreuses vulnérabilités de Java. Ces sources visent principalement les utilisateurs finaux exécutant un certain système d'exploitation d'une entreprise de Redmond / USA. AFAIK, il peut être vrai pour les versions non corrigées du plug-in de navigateur Java qui est configuré pour exécuter automatiquement toutes les applets, qu'il y a de grandes chances d'être victime d'un lecteur par infection. Tout comme il y a un risque d'attraper une MST lorsque vous avez des relations sexuelles non protégées avec tout le monde dans votre train en vous rendant au travail.

Mais je n'ai trouvé personne sur l'interwebz mondial qui parle d'applications serveur ou de JRE fonctionnant sans tête. C'est une toute autre chose.

Ou est-ce que je manque quelque chose ici?

[modifier le 2014-08-28] clarification: je ne m'inquiète que de Java sur les serveurs. Je ne me soucie pas des problèmes avec le plugin Java et / ou un logiciel spécifique développé en java.

La surface de sécurité supplémentaire que java place dans votre environnement est complexe, et il est important de ne pas l'ignorer ou d'essayer de la simplifier.

Premièrement, il y a le bilan horrible du JRE pour avoir des bogues de sécurité. Il est difficile d'en signaler un spécifique, et c'est la partie effrayante - les bogues sont des vulnérabilités extrêmement non spécifiées avec des vecteurs non spécifiés.

Lorsque je, en tant que consultant en sécurité, lis des clauses comme "autorise un attaquant distant" sans autre qualification quant à leur signification, je vois que cela pourrait très bien signifier que certains paramètres entrant dans une certaine fonction pourraient invoquer la condition vulnérable, même si vous exécutez uniquement le code que vous avez écrit. Et, comme ils ne sont pas spécifiés, vous ne savez pas si vous avez été touché.

Encore mieux, le JRE canonique publié par Oracle a un cycle de mise à jour trimestriel déclaré pour les mises à jour critiques, y compris presque toutes les mises à jour de sécurité. Ils ont créé 11 patchs hors cycle au total 11 fois au cours des quatre dernières années. Cela signifie qu'il est possible que vous soyez vulnérable à un bogue de sécurité jusqu'à trois mois après son signalement avant que vous ayez un moyen de le corriger.

Il y a d'autres problèmes avec Java que je n'entrerai pas ici, mais vraiment, il semble qu'il y ait une préoccupation justifiable, en particulier pour un serveur polyvalent. Si vous devez exécuter de telles choses, vous devez au moins créer une machine virtuelle à usage unique et l'isoler des autres choses.

En particulier, s'il existe une télécommande dans le JRE qui permet à un attaquant de gagner RCE, et un autre en PHP qui fait de même, et un autre en Ruby qui fait de même, vous devez patcher les trois. Tous les trois semblent quelque peu probables, au fur et à mesure que ces choses se passent, et l'attaquant peut choisir celui qui convient le mieux, puis posséder l'ensemble du serveur. C'est pourquoi nous devrions utiliser des machines virtuelles pour séparer les logiciels, en particulier les logiciels bogués comme les frameworks de langage géré, et en particulier ceux qui regroupent les correctifs de sécurité seulement quatre fois par an et sont la propriété d'un fournisseur qui affirme devant toutes les preuves qu'ils sont un parangon de Sécurité.

Pour mettre à jour, voici quelques CVE que j'ai sélectionnés à partir de la recherche CVE liée de ChrisS, à titre de démonstration.

• 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

Et mon préféré, depuis que j'y étais:

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

Soit dit en passant, ce n'est qu'un petit échantillon.

Les applications Java mangent toute ma RAM

L'alternative à l'utilisation de RAM est le gaspillage de RAM. Vous ne pouvez pas l'enregistrer pour plus tard.

Java regorge de vulnérabilités

Cela n'a pas vraiment d'importance car vous n'allez pas exposer la JVM au monde. Je suppose que vous n'allez exécuter aucun programme hostile, et si vous l'êtes, Java est plus sûr que la plupart des autres langages. L'important est de savoir si vos applications présentent des vulnérabilités.

Embauchez une entreprise pour effectuer une analyse statique de votre programme. Veracode, par exemple, est une entreprise que j'ai utilisée dans le passé pour auditer la sécurité du code des programmes Java, en particulier.

Facturez le code de facturation de votre équipe d'administration, évidemment.

Expliquez que tous les autres langages (ou machines virtuelles) peuvent être rendus non sécurisés par le code qui y est déployé, tout comme avec Java. S'il pense que les autres plates-formes sont intrinsèquement sécurisées (ou plus sécurisées que Java) sans sécurité d'adresse correcte, alors il est délirant.

Votre entreprise a évidemment investi dans l'embauche d'un développeur Java, pourquoi l'administrateur système refuse-t-il de prendre en charge une technologie que l'entreprise a décidé d'utiliser?

Je retournerais la question et lui demanderais quelles alternatives il propose et comment elles sont plus sûres que le dernier Server JRE disponible, en termes très spécifiques. En attendant, essayez de montrer que vous comprenez votre technologie, la surface d'attaque possible et que vous avez travaillé pour la minimiser (par exemple, les cadres inutiles, le code tiers, etc.). Faites vérifier votre code, recherchez les vulnérabilités publiées pour les frameworks sur lesquels vous avez compté au cours des X dernières années, comparez-le à d'autres langages / frameworks (assurez-vous d'inclure également la part de marché, les frameworks obscurs sans vulnérabilités publiées ne veulent rien dire).

Nous ne pouvons pas savoir comment s'est déroulée la conversion entre vous deux, mais s'il s'agissait de ses deux arguments, je pense que vous avez affaire à un administrateur système junior. At-il de l'expérience avec les serveurs d'applications Java? Peut-être qu'il est mal à l'aise avec la technologie et a peur de mettre quelque chose en production sans bien le comprendre (bonne attitude d'administrateur système alors).