Як переконати мого адміністратора в тому, що Java НА СЕРВЕРА сама по собі не є небезпечною?

Додаток

У нас є невеличка програма Java, яка використовує деякі маршрути Camel, щоб збирати завантажені файли з веб-сервера, обробляти їх та надсилати кілька електронних листів з результатами.

Сервер, на якому працює ця програма, був розведений. Наразі нам доведеться запускати його на недостатньому харчуванні, тому що я не можу переконати адміністратора встановити JRE на веб-сервері (який насправді є багатоцільовим сервером).

Страх

Я сам інженер додатків Java, пишу код JEE для проживання, обробляючи B2B транзакції вартістю десятків тисяч євро уросів на тиждень. Але у мене виникають проблеми з пошуку достовірних джерел, які спростовують міф про те, що Java сама по собі небезпечна.

Два основні аргументи адміністратора проти встановлення JRE:

1. Програми Java з'їдають всю мою оперативну пам'ять
2. Java повна вразливості

Правда?

Коли мова заходить про додатки Java, з'їдаючи баран. Ну ... я б сказав, що ми повинні встановити правильні значення для Xmx. Зроблено.

Зараз існує багато джерел, які говорять про безліч вразливих версій Java. Ці джерела здебільшого націлені на кінцевих користувачів, які керують певною операційною системою від компанії в Редмонд / США. AFAIK це може бути правдою для непакетних версій плагін браузера Java, який налаштований автоматично виконувати всі аплети, що є досить великі шанси стати жертвою зараження інфекцією. Так само, як є ризик захворіти на ЗПСШ під час незахищеного сексу з евеонідом у вашому поїзді під час поїздок на роботу.

Але я не міг знайти когось у всьому світі interwebz, який розповідає про серверні програми або JRE, що працюють без голови. Це зовсім інша справа.

Або я щось тут пропускаю?

[редагувати 2014-08-28] уточнення: Мене хвилює лише Java на серверах. Мене не хвилюють проблеми з Java-плагіном та / або конкретним програмним забезпеченням, розробленим у Java.

Додаткова поверхня безпеки, яку java вводить у ваше середовище, є складною, і важливо не ігнорувати її та не намагатися спростити її.

По-перше, є жахливий запис, який має JRE щодо помилок безпеки. Важко вказати конкретну, і це страшна частина - помилки є надзвичайно не визначеною вразливістю з не визначеними векторами.

Коли я, як консультант з питань безпеки, читаю пункти на зразок "дозволяє віддаленому зловмиснику" без додаткової кваліфікації щодо їхнього значення, я бачу, що це може цілком означати, що певні параметри, що потрапляють у певну функцію, можуть викликати вразливий стан, навіть якщо ви запускають лише написаний вами код. А оскільки вони не визначені, ви не дізнаєтесь, чи вплинули на вас.

Ще краще, що канонічний JRE, опублікований Oracle, має щоквартальний цикл оновлення критичних оновлень, включаючи майже всі оновлення безпеки. За останні чотири роки вони створили патчі з циклу загалом 11 разів. Це означає, що ви можете бути вразливими до помилок безпеки до трьох місяців після повідомлення про нього, перш ніж у вас є спосіб виправити це.

Є інші проблеми з java, з якими я не потраплятиму сюди, але насправді, здається, існує виправдана проблема, особливо для багатоцільового сервера. Якщо вам доведеться запускати такі речі, вам слід принаймні створити для нього одноцільовий VM та ізолювати його від інших речей.

Зокрема, якщо в JRE є пульт, який дозволяє зловмиснику отримати RCE, і ще один в PHP, який робить те саме, і інший в Ruby, який робить те ж саме знову, вам доведеться виправити всі три. Усі троє здаються дещо ймовірними, оскільки ці речі йдуть, і зловмисник отримує вибір того, що найзручніше, а потім володіє всім сервером. Ось чому ми повинні використовувати VM для розділення програмного забезпечення, особливо програмного забезпечення, таких як керовані мовні рамки, і особливо тих, які постачають патчі безпеки лише чотири рази на рік і є власником постачальника, який стверджує, що перед усіма доказами того, що вони є парагоном безпека.

Для оновлення, ось деякі CVE, які я вишнево вибрав із пов'язаного пошуку CVE ChrisS, шляхом демонстрації.

• 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

І мій улюблений, оскільки я був там:

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

Це, до речі, невеликий вибірки.

Програми Java з'їдають всю мою оперативну пам'ять

Альтернативою використанню оперативної пам’яті є витрачання оперативної пам'яті. Ви не можете зберегти його на потім.

Java повна вразливості

Це насправді не має значення, тому що ви не збираєтесь виставляти СВМ світу. Я припускаю, що ви не збираєтеся запускати жодних ворожих програм, а якщо є, то Java безпечніша, ніж більшість інших мов. Важливо, чи мають ваші програми вразливі місця.

Найміть компанію, яка буде робити статичний аналіз вашої програми. Наприклад, Veracode - це компанія, яку я раніше використовував для аудиту безпеки коду програм Java.

Очевидно, виставити рахунок заряджання вашої команди адміністратора.

Поясніть, що всі інші мови (або віртуальні машини) можуть бути захищені кодом, який розгорнуто на них, як і Java. Якщо він вважає, що інші платформи за своєю суттю захищені (або більш безпечні, ніж Java), без правильної адреси безпеки, то він впадає в оману.

Ваша компанія, очевидно, інвестувала в наймання Java-розробника, чому sysadmin відмовляється підтримувати технології, які компанія вирішила використовувати?

Я б перевернув питання і запитав його, які альтернативи він пропонує і наскільки вони більш безпечні, ніж найновіший доступний JRE сервера, в дуже конкретних умовах. Тим часом працюйте, щоб показати, що ви розумієте свою технологію, можливу поверхню атаки та що ви працювали над тим, щоб мінімізувати її (наприклад, непотрібні рамки, сторонній код тощо). Перевірте свій код, знайдіть уразливості, опубліковані для фреймворків, на які ви покладаєтесь протягом останніх X років, порівняйте їх з іншими мовами / фреймворками (обов'язково включіть також і ринкове спільне використання, незрозумілі рамки без опублікованих уразливостей нічого не означають).

Ми не можемо знати, як відбулося ціле перетворення між вами двома, але якщо це два його аргументи, я вважаю, що ви маєте справу з молодшим системним адміністратором. Чи має він досвід роботи з серверами додатків Java? Можливо, йому незручно з технологією і боїться вкласти щось у виробництво, не ретельно розуміючи це (тоді добре ставлення до системи).