Jak przekonać mojego administratora, że ​​Java ON A SERVER nie jest niebezpieczna per se?

Aplikacja

Mamy małą aplikację Java, która wykorzystuje niektóre trasy wielbłądów do pobierania przesłanych plików z serwera WWW, przetwarzania ich i wysyłania wiadomości e-mail z wynikami.

Serwer, na którym działała ta aplikacja, został wycofany z eksploatacji. Na razie musimy go uruchomić na słabo wyposażonym sprzęcie, ponieważ nie mogę przekonać administratora do zainstalowania środowiska JRE na serwerze internetowym (który jest tak naprawdę serwerem wielofunkcyjnym).

Strach

Sam jestem inżynierem aplikacji Java, piszę kod JEE dla żywych, obsługujących transakcji B2B wartych dziesiątki tysięcy euro tygodniowo. Ale mam problemy ze znalezieniem wiarygodnych źródeł, które obalą mit, że java jest niepewna per se.

Dwa główne argumenty administratora przeciwko instalacji środowiska JRE:

1. Aplikacje Java pochłaniają całą moją pamięć RAM
2. Java jest pełna luk w zabezpieczeniach

Prawda?

Jeśli chodzi o aplikacje Java zjadające pamięci RAM. Cóż ... Powiedziałbym, że musimy ustawić odpowiednie wartości dla Xmx. Gotowy.

Teraz istnieje wiele źródeł mówiących o wielu lukach w Javie. Źródła te są głównie skierowane do użytkowników końcowych korzystających z określonego systemu operacyjnego firmy z Redmond / USA. AFAIK może być prawdą, że w przypadku niepakowanych wersji wtyczki Java Browser Plugin, która jest skonfigurowana do automatycznego uruchamiania wszystkich apletów, istnieje duże prawdopodobieństwo, że padnie ofiarą dysku z powodu infekcji. Podobnie jak ryzyko zachorowania na choroby przenoszone drogą płciową podczas seksu bez zabezpieczenia z każdym w pociągu podczas dojazdów do pracy.

Ale nie mogłem znaleźć nikogo w interwebzie na całym świecie, który mówi o aplikacjach serwerowych lub środowiskach JRE działających bezgłowo. To zupełnie inna sprawa.

A może coś tu brakuje?

[edycja 28.08.2014] Wyjaśnienie: Martwię się tylko o Javę na serwerach. Nie dbam o problemy z wtyczką Java i / lub konkretnym oprogramowaniem opracowanym w Javie.

Dodatkowa powierzchnia zabezpieczeń, którą Java umieszcza w twoim środowisku, jest złożona i ważne jest, aby jej nie ignorować ani nie próbować upraszczać.

Po pierwsze, istnieje okropny rekord JRE za błędy w zabezpieczeniach. Trudno wskazać konkretny, a to jest przerażające - błędy to w przeważającej mierze nieokreślone podatności na nieokreślone wektory.

Kiedy jako konsultant ds. Bezpieczeństwa czytam takie klauzule, jak „zezwala na atakującego zdalnego” bez dalszych kwalifikacji co do ich znaczenia, widzę, że może to bardzo dobrze oznaczać, że pewne parametry wchodzące w pewną funkcję mogą wywołać stan zagrożenia, nawet jeśli używają tylko kodu, który napisałeś. A ponieważ nie są one określone, nie wiesz, czy to dotyczyło Ciebie.

Co więcej, kanoniczne środowisko JRE opublikowane przez Oracle ma kwartalny cykl aktualizacji krytycznych aktualizacji, w tym prawie wszystkich aktualizacji bezpieczeństwa. W ciągu ostatnich czterech lat utworzyli łaty poza cyklem 11 razy. Oznacza to, że istnieje możliwość narażenia się na błąd bezpieczeństwa do trzech miesięcy po zgłoszeniu, zanim będzie można go naprawić.

Istnieją inne problemy z Javą, o których tu nie będę wspominał, ale tak naprawdę wydaje się, że istnieje uzasadniona obawa, szczególnie w przypadku serwera wielofunkcyjnego. Jeśli musisz uruchomić takie rzeczy, powinieneś przynajmniej utworzyć maszynę wirtualną do jednego celu i odizolować ją od innych rzeczy.

W szczególności, jeśli w środowisku JRE znajduje się pilot, który pozwala atakującemu uzyskać RCE, i inny w PHP, który robi to samo, i inny w Ruby, który robi to samo, musisz załatać wszystkie trzy. Wszystkie trzy wydają się nieco prawdopodobne, ponieważ te rzeczy idą, a atakujący może wybrać najbardziej dogodne, a następnie posiadać cały serwer. Właśnie dlatego powinniśmy używać maszyn wirtualnych do oddzielania oprogramowania, w szczególności błędnego oprogramowania, takiego jak frameworki zarządzanego języka, a zwłaszcza tych, które łączą poprawki zabezpieczeń tylko cztery razy w roku i są własnością dostawcy, który twierdzi wbrew wszelkim dowodom, że są wzorem bezpieczeństwo.

Aby zaktualizować, oto niektóre CVE, które wybrałem z połączonego wyszukiwania CVE ChrisS, w celach demonstracyjnych.

• 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

I mój ulubiony, odkąd tam byłem:

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

Nawiasem mówiąc, to tylko małe próbkowanie.

Aplikacje Java pochłaniają całą moją pamięć RAM

Alternatywą dla korzystania z pamięci RAM jest marnowanie pamięci RAM. Nie możesz zapisać tego na później.

Java jest pełna luk w zabezpieczeniach

To naprawdę nie ma znaczenia, ponieważ nie zamierzasz narażać JVM na świat. Zakładam, że nie będziesz uruchamiał żadnych wrogich programów, a jeśli tak, Java jest bezpieczniejsza niż większość innych języków. Liczy się to, czy twoje aplikacje mają luki.

Zatrudnij firmę do wykonania analizy statycznej Twojego programu. Na przykład Veracode to firma, z której korzystałem w przeszłości do kontroli bezpieczeństwa kodu programów Java.

Oczywiście rozliczaj kod opłat swojego zespołu administracyjnego.

Wyjaśnij, że wszystkie inne języki (lub maszyny wirtualne) mogą być zagrożone przez kod, który jest na nich wdrażany, tak jak w Javie. Jeśli uważa, że ​​inne platformy są z natury bezpieczne (lub bardziej bezpieczne niż Java) bez prawidłowego rozwiązania kwestii bezpieczeństwa, to ma złudzenia.

Twoja firma oczywiście zainwestowała w zatrudnienie programisty Java, dlaczego sysadmin odmawia wsparcia technologii, z której firma zdecydowała się skorzystać?

Przerzuciłbym pytanie i zapytałbym go, jakie alternatywy proponuje i w jaki sposób są one bezpieczniejsze niż najnowsza dostępna wersja JRE serwera, pod bardzo konkretnymi warunkami. W międzyczasie staraj się pokazać, że rozumiesz swoją technologię, możliwą powierzchnię ataku i że starałeś się ją zminimalizować (np. Niepotrzebne ramy, kod innej firmy itp.). Zweryfikuj kod, poszukaj luk opublikowanych dla środowisk, na których polegasz w ciągu ostatnich X lat, porównaj go z innymi językami / ramami (pamiętaj, aby uwzględnić również udział w rynku, niejasne struktury bez opublikowanych luk nic nie znaczą).

Nie możemy wiedzieć, jak przebiegła cała konwersja między wami dwoma, ale gdyby to były jego dwa argumenty, uważam, że macie do czynienia z młodszym administratorem systemu. Czy ma doświadczenie z serwerami aplikacji Java? Być może czuje się niekomfortowo z technologią i boi się wprowadzić coś do produkcji bez dogłębnego zrozumienia (wtedy dobre nastawienie sysadmin).