Как убедить моего Администратора, что Java ON A SERVER сама по себе небезопасна?

13

Приложение

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

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

Страх

Я сам Java Application Engineer, я пишу код JEE для жизни, обрабатывая транзакции B2B стоимостью в десятки тысяч евро в неделю. Но у меня есть проблемы с поиском надежных источников, которые опровергают миф о том, что Java сама по себе небезопасна.

Два основных аргумента администратора против установки JRE:

Java-приложения поглощают всю мою оперативную память
Java полна уязвимостей

Правда?

Когда дело доходит до приложений Java, съедающих оперативную память. Ну ... я бы сказал, что мы должны установить правильные значения для Xmx. Выполнено.

Сейчас есть много источников, говорящих о многих уязвимостях Java. Эти источники в основном предназначены для конечных пользователей, использующих определенную операционную систему от компании в Редмонде, США. Насколько нам известно, для непатентованных версий плагина Java-браузера, который настроен на автоматическое выполнение всех апплетов, существует большая вероятность того, что он станет жертвой заражения диска. Так же, как есть риск заразиться ЗППП при незащищенном сексе с кем-либо в вашем поезде во время поездок на работу.

Но я не смог найти никого на всемирной паутине, который бы говорил о серверных приложениях или JRE, работающих без головы. Это совсем другое.

Или я что-то здесь упускаю?

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

— lajuette
источник

7

Если оборудование, на котором оно установлено, явно недостаточно мощным и вызывает проблемы, то наряду с опасениями SA, безусловно, у вас есть экономическое обоснование для получения нового оборудования.

— user9517

4

Убедите его, что это не код вашей компании, который он только что увидел на thedailywtf.com.

— Майкл Хэмптон

9

У Java был трудный год в 2013 году. Был даже веб-сайт, отслеживающий 0-дневные эксплойты, поскольку они только продолжали разворачиваться. С середины прошлого года не было никаких 0-дневных эксплойтов, но исследователи все же обнаружили 107 CVE Java только в этом году. Это далеко от "безопасности".

— Крис С

5

Можно ли вызвать ошибку JVM, передав вредоносные данные в ваше приложение? Тебе лучше поверить в это. И многие из этих CVE относятся к запуску Java на серверах, а не к обычному плагину для браузера Windows.

— Майкл Хэмптон

3

@lajuette Я предоставил ссылку с номером 107 по какой-то причине - если бы вы щелкнули по нему, все те вопросы, которые вы только что задали, получили бы ответ. Некоторые из этих 107 относятся к реализациям не-Oracle, таким как Android Dalvak, но подавляющее большинство относится к реализации Oracle. По своей природе Java не является небезопасной, но JRE Sun / Oracle изобилует проблемами. PHP, Perl, Ruby тоже имеют уязвимости - ни одна из них не идеальна. Я не могу сказать, является ли Java лучше или хуже тех, что существуют в настоящее время, но за последний год это определенно был мальчиком для битья в индустрии безопасности.

— Крис С

18

Дополнительная поверхность безопасности, которую Java создает в вашей среде, сложна, и важно не игнорировать ее и не пытаться упростить ее.

Во-первых, у JRE есть ужасная запись об ошибках безопасности. Трудно указать конкретный, и это страшная часть - ошибки - это в значительной степени неуказанные уязвимости с неопределенными векторами.

Когда я, как консультант по безопасности, читаю предложения типа «разрешает удаленному злоумышленнику» без дополнительной уточнения их значения, я вижу, что это вполне может означать, что определенные параметры, попадающие в определенную функцию, могут вызвать уязвимое состояние, даже если вы работают только код, который вы написали. И, поскольку они не определены, вы не узнаете, были ли они затронуты.

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

Есть и другие проблемы с Java, которые я не буду здесь затрагивать, но на самом деле кажется, что это оправданное беспокойство, особенно для многоцелевого сервера. Если вам нужно запускать такие вещи, вы должны, по крайней мере, создать для этого виртуальную машину специального назначения и изолировать ее от других вещей.

В частности, если в JRE есть пульт, который позволяет злоумышленнику получить RCE, и другой в PHP, который делает то же самое, и другой в Ruby, который делает то же самое снова, вы должны исправить все три. Все эти три варианта кажутся довольно вероятными, и злоумышленник выбирает тот, который наиболее удобен, а затем владеет всем сервером. Вот почему мы должны использовать виртуальные машины для разделения программного обеспечения, особенно программного обеспечения с ошибками, такого как платформы управляемых языков, и особенно тех, которые связывают исправления безопасности только четыре раза в год и являются собственностью поставщика, который утверждает перед лицом всех доказательств того, что они являются образцом безопасность.

Чтобы обновить, вот несколько CVE, которые я выбрал из поиска CVS, связанного с ChrisS, в качестве демонстрации.

И мой любимый, так как я был там:

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

Кстати, это всего лишь небольшая выборка.

— Сокол Момот
источник

6

Java-приложения поглощают всю мою оперативную память

Альтернативой использованию ОЗУ является ее потеря. Вы не можете сохранить его на потом.

Java полна уязвимостей

Это не имеет большого значения, потому что вы не собираетесь показывать JVM миру. Я предполагаю, что вы не собираетесь запускать какие-либо враждебные программы, и если да, то Java безопаснее, чем большинство других языков. Важно то, есть ли в ваших приложениях уязвимости.

— Дэвид Шварц
источник

3

Итак, причина не работает. Какие другие инструменты есть в вашем наборе инструментов убеждения? У вас есть ржавые плоскогубцы?

— Дэвид Шварц

1

@FalconMomot Да, ядро может использовать его для кэширования файлов. Ядро может отнять память у JVM, если оно будет лучше использоваться. Вот так почти все современные ОС работают. Альтернативой использованию ОЗУ является ее потеря. В ОС имеется диспетчер памяти, специально предназначенный для обеспечения оптимального использования оперативной памяти. Аргументы типа «Java-приложения поглощают всю мою оперативную память» почти всегда указывают на администратора, который не понимает, как современные операционные системы используют оперативную память.

— Дэвид Шварц

1

Если JVM не освобождает память, она должна поменять ее в пространство подкачки (если оно есть), чтобы сделать это, что медленно. Ядро не может вызвать сборщик мусора. Кроме того, кеширование файлов обычно имеет более низкий приоритет, чем распределение пространства пользователя, даже если они используются редко (насколько ядро может сказать, что они используются редко, что не очень хорошо).

— Сокол Момот

3

Я хочу узнать больше о том, как Linux может одновременно использовать блок оперативной памяти для кэширования, в то время как процесс все еще думает, что ему принадлежит. Я никогда не слышал об этом раньше.

— Майкл Хэмптон

1

@FalconMomot Ядро не должно знать, что оперативная память «свободна». Ядро всегда контролирует использование оперативной памяти, если только приложение не блокирует страницы. Это просто должно сделать отображаемые страницы непригодными для возврата ОЗУ. Если данные не изменяются и не используются в течение определенного периода времени, а пропускная способность ввода-вывода не насыщена, они могут произвольно записать их в своп, что делает страницы непригодными для использования, позволяя им восстанавливать ОЗУ, как только оно более эффективно используется для этого. (Это пространство недостаточно велико, чтобы объяснить, как работает современное управление памятью, но, похоже, у вас есть некоторые очень распространенные заблуждения.)

— Дэвид Шварц

2

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

Разумеется, выставьте счет за код вашей команды администратора.

— mfinni
источник

1

Объясните, что все другие языки (или виртуальные машины) могут быть небезопасными из-за кода, развернутого на них, как и в Java. Если он считает, что другие платформы по своей природе безопасны (или более безопасны, чем Java) без правильного решения проблемы безопасности, то он бредит.

Ваша компания, очевидно, инвестировала в наем Java-разработчика. Почему системный администратор отказывается поддерживать технологию, которую компания решила использовать?

Я бы перевернул вопрос и спросил его, какие альтернативы он предлагает и насколько они более безопасны, чем последняя доступная JRE для сервера, в очень конкретных терминах. В то же время постарайтесь показать, что вы понимаете свою технологию, возможную поверхность атаки и то, что вы работали, чтобы минимизировать ее (например, ненужные платформы, сторонний код и т. Д.). Проверьте свой код, найдите опубликованные уязвимости для фреймворков, на которые вы полагаетесь в последние X лет, сравните его с другими языками / фреймворками (не забудьте также включить markethare, неясные фреймворки без опубликованных уязвимостей ничего не значат).

Мы не можем знать, как произошло полное преобразование между вами, но если бы это были его два аргумента, я думаю, вы имеете дело с младшим системным администратором. Имеет ли он опыт работы с серверами приложений Java? Возможно, он не знаком с технологией и боится запускать что-то в производство, не разбираясь в этом (в таком случае, хорошее отношение сисадмина).

— Джованни Тирлони
источник

Благодарю. Мы не говорим о компании. Скорее некоммерческая ассоциация. У нашего системного администратора есть доктор в области информационных технологий и маркетинга, но он не является «настоящим» системным администратором. И да: я верю, что он боится Java, чего он не до конца понимает.

— lajuette