Wątek zablokowany 2015-09-28 08:59 przez Krolik.

Przyszłość Java i 0day - (rzekome) 460 odkrytych luk bezpieczeństwa w 2015 roku

0

Dzisiaj przejrzałem nowinki z 2015 dotyczące Java i przyznam szczerze, że jestem trochę zaskoczony, bo co głównie rzuca się w oczy to nagłówki, takie jak:

Java and Flash both vulnerable—again—to new 0-day attacks
http://arstechnica.com/security/2015/07/two-new-flash-exploits-surface-from-hacking-team-combine-with-java-0-day/

Oracle patches already-exploited Java zero-day flaw, over 190 other vulnerabilities
http://www.pcworld.com/article/2948592/security/oracle-fixes-zeroday-java-flaw-and-over-190-other-vulnerabilities.html

Oracle Critical Patch Update Advisory - July 2015
http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html
( tylko 193 luki i proszę zwrócić uwagę gdzie...)*

Is Java the Biggest Vulnerability on your PC? A data-driven answer
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/

Cytat:
As Java vulnerabilities piled up, Oracle released a Critical Patch Update Advisory this July, containing no less than 193 new security fixes! And there was the April 2015 Critical Patch Advisory (98 security fixes) and the January 2015 Patch Advisory before that (169 security fixes).

Luki w samym JRE, trochę tego jest, przynieście sobie ciasteczka i mleko na lekturę
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html

Java Zero-day vulnerability exploited in the Wild
http://thehackernews.com/2015/07/java-zero-day-vulnerability.html

Czy przyszłość Java to po pół tysiąca krytycznych luk w oprogramowaniu końcowym i serwerowym na pół roku? Czy można zaufać w ogóle takiej technologii? Z tych informacji maluje się przykry obrazek, który każe się zastanowić czy czasem mottem Java nie powinno być zdanie:

"Java - najkrótsza droga malware do twojego komputera i serwera"

Czy pisząc wasze rozwiązania enterprise w Java zastanawiacie się czy wasze oprogramowanie będzie podatne na jedną z 460 odkrytych luk (nie mówiąc o nieopublikowanych) w samym 2015 roku?

Czy programista Java zakłada klapki na oczy i ignoruje te prawie pół tysiąca potwierdzonych luk do swoich aplikacji i baz danych?

1

Czy pisząc wasze rozwiązania enterprise w Java zastanawiacie się czy wasze oprogramowanie będzie podatne na jedną z 460 odkrytych luk (nie mówiąc o nieopublikowanych) w samym 2015 roku?

Strzelam, że jakieś 98% oprogramowania enterprise w Javie to serwery, usługi, backendy. Czy któraś z tych luk pozwalała je atakować? Czy jak zwykle chodzi o wyjście z sandboxu w przeglądarkowym applecie? Ile lat temu ostatni raz uruchomiłeś jakiś applet?

4

Najpierw przeczytaj listę oprogramowania dotkniętego lukami, potem komentuj. Z tego co widzę na http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html to całkiem sporo tam rozwiązań enterprise dla Java.

I wciąż, jak się to odnosi do backendów w Javie?

Masz pod ręką 460 odkrytych luk bezpieczeństwa (i pewnie szybko znajdziesz zaraz jakiegoś zero-day'a), Google ma ponad miliard linii kodu w Javie w swoich enterprajsowych rozwiązaniach - kiedy włamujesz się do Gmaila czy Youtube'a?

2

Znowu temat do flame'u. Nie ze względu na brak bezpieczeństwa Javy - bo o tym już wiadomo od dłuższego czasu. Ale ze względu na ewidentny brak znajomości tego tematu.

  1. Wszystkie te listy nie dotyczą jednej wersji Javy, tylko wielu wersji, na różne środowiska.
  2. Dodatkowo do pierwszej, największej liczby doliczane są dziury w aplikacjach Oracle, nie wynikające z samej Javy.
  3. Tak jak napisano wcześniej - głównym zastosowaniem Javy są aplikacje schowane za serwerami. Znaczy to mniej więcej tyle, że większość tych błędów nawet nie będzie miało szansy zadziałać.
  4. "Vulnerability" nie jest tożsame z "mam całkowity dostęp do wszystkiego na Twoim kompie i mogę włączyć sobie Twoją kamerkę i oglądać Ciebie jak kodujesz". Czasami takie "vulnerability" to możliwość uzyskania informacji, który port jest otwarty. Jasne, takie rzeczy nie powinny się dziać - ale też nie jest tak, że uruchomienie pluginu daje wszystkim dostęp do wszystkich Twoich danych.
1

@Bartosz Wójcik jak już wspomniano, większość tych "luk" nijak sie ma do softu pisanego w Javie bo ten w przeważającej większości stanowią wewnętrzne aplikacje biznesowe firm schowane na serwerach. Żeby cokolwiek z nimi zrobić potrzebowałbyś na przykład dostęp do maszyny na której to jest uruchomione, a wtedy to masz znacznie większy problem niż dziura w javie...
Poza tym nie ma softu bez bugów. A im więcej softu powstaje w javie tym więcej błędów się znajduje, bo więcej osób szuka / wpada na nie przypadkiem.

0

Odpowiedź typu - nie znam się to się wypowiem.

@Shalom ma rację, że każda aplikacja ma dziury, czy tez nawet języki programowania i w takich przypadkach - jak znamy problem, stosujemy innego typu zabezpieczenia by dostanie się do luki w bezpieczeństwie było trudne i zniechęciło atakującego. Dodatkowo, takie tematy są co jakiś czas poruszane - jak by przed chwilą odkryto wadliwą aplikacje, przecież każdy język ma dziury zobacz na glibc: https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-767/GNU-Glibc.html
Teraz przez to będę zmuszony do wyłączenia Linuxa, bo są luki bezpieczeństwa ?
Czy mam np. przestać korzystać z aplikacji webowej, bo wśród zgłoszonych błędów znalazły się luki bezpieczeństwa (np. strona jest podatna na ataki typu CSRF, czy też XSSy) ?

1
Madaoo napisał(a):

(...)Czy mam np. przestać korzystać z aplikacji webowej, bo wśród zgłoszonych błędów znalazły się luki bezpieczeństwa (np. strona jest podatna na ataki typu CSRF, czy też XSSy) ?

No, w tym wypadku akurat wypadałoby przestać z niej korzystać :D

3

Widzę, że terminy takie jak Remote Exploit niewiele Ci mówią i nie rozumiesz powagi sytuacji.

O defense-in-depth słyszał? Pracownik ma dostęp do backofficowego frontendu, ten frontend ma dostęp do bazy danych. W sensownie skonfigurowanym środowisku nikt poza adminem nie ma dostępu bezpośrednio do bazy danych.

Frontend dla pracowników serwuje Ci CRUDa do przeglądania bazy klientów z paroma dodatkowymi bajerami. Czekam na propozycje w jaki sposób wykorzystasz remote exploit na bazę danych, nawet ten "niewymagający dodatkowych uprawnień". Jeżeli frontend dobrze formuje zapytania, a sieć jest skonfigurowana zgodnie z właściwymi praktykami to wykorzystanie większości z tych podatności jest niemożliwe.

Nie jestem pewien czy rozumiesz co oznaczają te wszystkie tabelki w bazach podatności i że "easy to exploit" + "without authentication" czasem nadal oznacza lukę niemożliwą do wykorzystania.

2

ty tak na serio? czyzbys mial jakis interes w tym zeby siac nieuzasadniona panike posrod uzytkownikow javy? nie ma oprogramowania bez luk, chyba ze mowisz o takim ktorego nikt nie uzywa ;) martwienie sie takimi rzeczami w wypadku pewnie 99% aplikacji javowych ma taki sens jak martwienie sie wydajnoscia for vs while

Bartosz Wójcik napisał(a):

Czy przyszłość Java to po pół tysiąca krytycznych luk w oprogramowaniu końcowym i serwerowym na pół roku?
takie 'krytyczne' te luki ze mamy serwisy javowe dzialajacy bez przerwy od 3 lat, uzywane przez setki zewnetrznych userow

Bartosz Wójcik napisał(a):

Czy można zaufać w ogóle takiej technologii?
chyba mozna, skoro pozwala na tworzenie wydajnych, bezawaryjnych programow zarabiajacych miliardow dolarow rocznie

Bartosz Wójcik napisał(a):

Z tych informacji maluje się przykry obrazek, który każe się zastanowić czy czasem mottem Java nie powinno być zdanie:
"Java - najkrótsza droga malware do twojego komputera i serwera"
pewnie, dostep do serwerow tylko dla admina i firewalle sie nie licza

Bartosz Wójcik napisał(a):

Czy pisząc wasze rozwiązania enterprise w Java zastanawiacie się czy wasze oprogramowanie będzie podatne na jedną z 460 odkrytych luk (nie mówiąc o nieopublikowanych) w samym 2015 roku?
nie mam paranoi, ani ambicji zeby martwic sie o nieistniejace problemy

Bartosz Wójcik napisał(a):

Czy programista Java zakłada klapki na oczy i ignoruje te prawie pół tysiąca potwierdzonych luk do swoich aplikacji i baz danych?
nie, mysle ze przecietny programista java ma inne sprawy na glowie niz martwienie sie exploitami gdy jest to bezzasadne

2

Czy mam np. przestać korzystać z aplikacji webowej, bo wśród zgłoszonych błędów znalazły się luki bezpieczeństwa (np. strona jest podatna na ataki typu CSRF, czy też XSSy) ?

nie, mysle ze przecietny programista java ma inne sprawy na glowie niz martwienie sie exploitami gdy jest to bezzasadne

Autor wątku BW chyba dopiął swego, bo każdy tutaj potwierdza, że klepacze javy mają w głębokim poważaniu exploity :-), taki był cel? Jeśli tak to gratuluję taktyki :-P

0

Wszystko ma błędy i przez to są one zgłaszane i naprawiane - każda znaleziona luka, nie zostanie od razu naprawiona, trzeba też zanalizować jakie jest ryzyko stworzenia takiego scenariusza by ktoś się włamał i mógł przejąc kontrolę. Firmy które wytwarzają oprogramowanie, po przeprowadzeniu pen testów są świadome tego co może im zagrażać i tak ta luka będzie naprawiona.

2

Tutaj widzę przegięcia w dwie strony.

Z jednej strony listowanie luk bezpieczeństwa w Javie.
Dla mnie najbardziej wiarygodne w tym wątku źródło to Oracle. Listing zawiera luki w różnych technologiach, w tym JDeveloper(!) i Oracle Database Server. Ile z tych luk dotyczy Javy serwerowej, bo chyba o takich można dyskutować?

Odpowiedź: 23.

Pytanie: czy dobrze że te luki zostały opublikowane i naprawione? (retoryczne)

Pytanie kolejne: który z produkcyjnie stosowanych języków programowania (lub środowisk) nie pozwala na stworzenie luki bezpieczeństwa?

Pytanie kolejne: jaką mamy bardziej bezpieczną alternatywę dla Javy?

Druga strona:

Shalom napisał(a):

jak już wspomniano, większość tych "luk" nijak sie ma do softu pisanego w Javie bo ten w przeważającej większości stanowią wewnętrzne aplikacje biznesowe firm schowane na serwerach. Żeby cokolwiek z nimi zrobić potrzebowałbyś na przykład dostęp do maszyny na której to jest uruchomione, a wtedy to masz znacznie większy problem niż dziura w javie..

Nie analizowałem tych luk, ale nie sądzę żeby soft Javovy w większości był niedostępny przez Internet. To raczej wyraz nadziei programisty niż realia. Realia są takie że biznes chce mieć aplikacje gdziekolwiek pracownik się znajduje - na spotkaniu, w trasie, w kawiarni. Programiści nawet nie muszą o tym wiedzieć, mogą jedynie potem "wyrazić zaskoczenie" :)

katelx napisał(a):
Bartosz Wójcik napisał(a):

Z tych informacji maluje się przykry obrazek, który każe się zastanowić czy czasem mottem Java nie powinno być zdanie:
"Java - najkrótsza droga malware do twojego komputera i serwera"

pewnie, dostep do serwerow tylko dla admina i firewalle sie nie licza

W większości wypadków pomaga jedynie porada prawnika. Zabezpieczenia typu "hasło tylko dla admina" czy firewall są dobre dla pracowników firmy.

Jakiś czas temu był taki żart, który jednak obrazuje jak ominąć to co napisałaś:
http://niebezpiecznik.pl/post/fotoradar-injection/

Nie byłbym taki pewien czy działające systemy (ten nawet z etykietką "Enterprise") nie są podatne na takie bzdurne ataki (abstrahując od technologii).

katelx napisał(a):

nie, mysle ze przecietny programista java ma inne sprawy na glowie niz martwienie sie exploitami gdy jest to bezzasadne

Myślę że przeciętny programista Javy zbyt łatwo ufa temu że jest bezpieczny.

Nie chcę się zajmować analizą bezpieczeństwa w danym obszarze - to aktualizuję często software i... używam analizy statycznej kodu online (a nie raz w roku).
Kilka narzędzi: http://samate.nist.gov/index.php/Source_Code_Security_Analyzers.html

3

Nie analizowałem tych luk, ale nie sądzę żeby soft Javovy w większości był niedostępny przez Internet.

Chyba za bardzo nie zrozumiałeś Shaloma. Bezpośrednio niedostępna przez internet usługa w Javie w znaczeniu takim, że schowana za firewallem i wystawiona przez webserver po HTTP w postaci strony internetowej czy innego serwisu REST-owego. Dostęp bezpośredni to dostęp do filesystemu czy procesu na maszynie, która uruchamia aplikację.

Tyle luk i tyle zero-dayów z tak dużą ilością softu napisanego w Javie powinno się łączyć bezpośrednio z ilością włamań. Dlaczego w takim razie tych włamań nie ma? Przecież hasła użytkowników Gmaila i Youtube'a powinny wyciekać chyba co tydzień.

1
Rev napisał(a):

Nie analizowałem tych luk, ale nie sądzę żeby soft Javovy w większości był niedostępny przez Internet.

Chyba za bardzo nie zrozumiałeś Shaloma. Bezpośrednio niedostępna przez internet usługa w Javie w znaczeniu takim, że schowana za firewallem i wystawiona przez webserver po HTTP w postaci strony internetowej czy innego serwisu REST-owego. Dostęp bezpośredni to dostęp do filesystemu czy procesu na maszynie, która uruchamia aplikację.

To że aplikacja jest dostępna przez webserver czy firewall utrudnia ale nie uniemożliwia włamanie. Nie oszukujmy się - zabezpieczenia tego typu są tylko elementem wymaganym ale nie wystarczającym.

A jeśli mam się odnieść do włamań przy dostępie bezpośrednim (czytaj do filesystemu czy procesów), to jest to już problem bezpieczeństwa systemu, ssl, ssh i innych warstw pośredniczących a nie Javy - więc nie o tym dyskusja. W praktyce jest tak, że udowodnienie możliwości uruchomienia procesu kończy dowód (nie)bezpieczeństwa systemu.

Ja osobiście nie odbieram tego wątku jako atak - raczej jako przypomnienie że nie żyjemy w idealnym świecie.

6

Dużo osób zapomina w tym wątku, że wiele nieoczekiwanych własności Javy uznawanych za lukę nie jest uznawane za lukę w innych technologiach. Java ma dużo wyżej postawioną poprzeczkę jeśli chodzi o bezpieczeństwo.

Przykład: możliwość pominięcia Security Managera w Javie przez odpowiednio spreparowany kod z pewnością byłaby uznana za krytyczną lukę. Tymczasem C++, PHP, Delphi czy wiele innych środowisk w ogóle nie ma czegoś takiego jak Security Manager i jakiegokolwiek systemu uprawnień. Ich poziom bezpieczeństwa jest z definicji niższy, ale nie uważa się tego za lukę.

Przykład 2: Możliwość napisania kodu, który przechodzi poprawnie weryfikację, a mimo to prowadzi do przepełniona bufora lub innego poważnego błędu byłaby uznana za krytyczny błąd weryfikatora bajtkodu i podatność. Tyle, że w C++ i Delphi taka podatność znowu występuje z definicji, bo tam nie ma weryfikatora, nie ma kontroli dostępu do pamięci, nie ma praktycznie nic co chroni przed tego typu błędami.

Ostatnia poważna luka mająca wpływ na bezpieczeństwo aplikacji serwerowych dotyczyła parsowania doubli i najgorsze co powodowała to Dos. Praktycznie wszystko miało tę lukę, łącznie z glibcem i PHP, więc Java nie była wyjątkiem.

I wisienka na torcie:
Jeśli Java byłaby mniej bezpieczna i bardziej dziurawa niż inne środowiska uruchamiania kodu, to zapewne giełda nowojorska nie przeniosłaby na nią systemu tradingowego, tylko pozostalaby przy starym systemie napisanym w C++. Choć tu nie jestem pewien, czy tylko bezpieczeństwo było powodem tej decyzji, bo słyszałem, że system Javowy jest znacznie wydajniejszy niż ten poprzedni, który się nie wyrabiał z rosnącą ilością zleceń.

0
Krolik napisał(a):

Dużo osób zapomina w tym wątku, że wiele nieoczekiwanych własności Javy uznawanych za lukę nie jest uznawane za lukę w innych technologiach. Java ma dużo wyżej postawioną poprzeczkę jeśli chodzi o bezpieczeństwo.

Tobie nawet jakby nawet się włamali przez remote exploita bez żadnych dodatkowych uprawnień do systemu to byś mówił, że to zlecony pentest

W skrócie:

  • Luki dla Javy to nie są luki!, nawet remote, nawet te z ocena 10 w CVE! Nie znacie się!
  • Luki bezpieczeństwa dla Javy i aplikacji Oracle i tak nie działają, bo wszystko jest niedostępne przez sieć!
  • Luki dla Javy to wymyślone rzeczy przez hejterów Javy takich jak ja.
    Czyli rozejść się, nie wymyślać, nie hejtować Javy, żadnych luk nie ma i nie było nigdy, a nawet jak były to nie działały!
0

Załóżmy, że Java nie ma przyszłości.
To co ma?

0

Hijah,

Ktoś mówił, że nie ma gotowych exploitów?

https://www.exploit-db.com/platform/?p=java

I co doktorku :>

1
Krwawy Terrorysta napisał(a):

https://www.exploit-db.com/platform/?p=java

Pro hint: To są gotowe exploity na soft napisany w Javie, a nie "standalone remote exploit" działające na wszystkie apki napisane w Javie. Takie gotowe exploity masz na każdy, powtarzam, każdy soft, niezależnie od tego w czym byłby napisany.

PS. Co Ty w ogóle podlinkowałeś:

VBulletin 2.0/2.2.x - Cross-Site Scripting Vulnerabilities
PHP-Nuke 6.x/7.x FAQ Module categories Parameter XSS
Wolfram Research webMathematica 4.0 File Disclosure Vulnerability
HP AutoPass License Server File Upload

Rzeczywiście, super exploity na Javę. Gdyby to chociaż były produkty Suna/Oracle. I gdyby chociaż połowa rzeczy z listy była przynajmniej napisana w Javie :D

2
Bartosz Wójcik napisał(a):

Java and Flash both vulnerable—again—to new 0-day attacks
http://arstechnica.com/security/2015/07/two-new-flash-exploits-surface-from-hacking-team-combine-with-java-0-day/

Tak bardzo applety

Bartosz Wójcik napisał(a):

Oracle patches already-exploited Java zero-day flaw, over 190 other vulnerabilities
http://www.pcworld.com/article/2948592/security/oracle-fixes-zeroday-java-flaw-and-over-190-other-vulnerabilities.html

"Go ahead and update Java—or disable it if you don’t remember the last time you actually used it on the Web"
Ręce opadają

Bartosz Wójcik napisał(a):

Oracle Critical Patch Update Advisory - July 2015
http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html

Och nie, firma X znajduje i łata bugi w swoich produktach. Szybko, przerzućmy się na produkty firmy Y - oni nie łatają bugów, więc jest bezpieczniej.
A właśnie, w JRE znowu same luki dotyczące appletów. Kogo to obchodzi.

Bartosz Wójcik napisał(a):

Is Java the Biggest Vulnerability on your PC? A data-driven answer
https://heimdalsecurity.com/blog/java-biggest-security-hole-your-computer/

Kto takie głupoty pisze?

Andra Zaharia, Marketing & Communication Specialist

Istny autorytet

Bartosz Wójcik napisał(a):

Luki w samym JRE, trochę tego jest, przynieście sobie ciasteczka i mleko na lekturę
https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html

"Unspecified vulnerability in Oracle Java SE 6u95, 7u80, and 8u45 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to 2D. "
I nawet ciastka ugryźć nie zdążyłem, tak szybko się okazało, że nic ciekawego się tam nie znajdzie.

Bartosz Wójcik napisał(a):

Java Zero-day vulnerability exploited in the Wild
http://thehackernews.com/2015/07/java-zero-day-vulnerability.html

Zero day który działa tylko na starszej wersji softwaru? Na prawdę, ludzi którzy takie rzeczy piszą można leczyć tylko poprzez strzał w łeb.

Bartosz Wójcik napisał(a):

Czy przyszłość Java to po pół tysiąca krytycznych luk w oprogramowaniu końcowym i serwerowym na pół roku? Czy można zaufać w ogóle takiej technologii? Z tych informacji maluje się przykry obrazek, który każe się zastanowić czy czasem mottem Java nie powinno być zdanie:

"Java - najkrótsza droga malware do twojego komputera i serwera"

Zjem buta, jesli jakikolwiek malware dostanie się na mój komputer lub serwer z winy JRE.

Bartosz Wójcik napisał(a):

Czy pisząc wasze rozwiązania enterprise w Java zastanawiacie się czy wasze oprogramowanie będzie podatne na jedną z 460 odkrytych luk (nie mówiąc o nieopublikowanych) w samym 2015 roku?
Na pewno, moje oprogramowanie serwerowe oraz desktopowe i na to androida, będą tak bardzo podatne prez te wszystkie luki na applety, że aż sram cegłami w minecrafcie ze strachu.

Bartosz Wójcik napisał(a):

Czy programista Java zakłada klapki na oczy i ignoruje te prawie pół tysiąca potwierdzonych luk do swoich aplikacji i baz danych?

Pół tysiąca załatanych bugów w setkach różnych produktów, jak mam z tym żyć?

0

460 błędów w samym 2015 roku?
@Bartosz Wójcik dlaczego manipulujesz?

Nie było żadnych 460 błędów odkrytych w 2015 roku. Lista, którą podlinkowałesś dotyczy wszystkich zarejestrowanych podatności i znajdują się na niej podatności np. z 2012 roku, które zostały załatane dawno temu i które dotyczą jakiś archaicznych wersji JRE 6 i 7, które już są dawno EOL (end-of-life). To tak jakbys się podniecał bugami w Windows XP i IE6.

Proszę, oto tabelka podsumowująca podatności z samego 2015 roku:
https://www.cvedetails.com/top-50-products.php?year=2015

  1. iOS: 267
  2. MAC OS X: 241
  3. Flash: 190
  4. IE: 167
  5. Chrome: 141
  6. Firefox: 134
  7. Windows Server 2012: 129
    ....
  8. JRE / JDK: 55

All time leaders też wygląda ciekawie:
https://www.cvedetails.com/top-50-products.php?year=0
Firefox: 1258
Chrome: 1152
...
JRE: 413

Skoro cała dyskusja została oparta na manipulacji rodem z Faktu, kontynuowanie jej to bezsensowne bicie piany i dlatego zamykam wątek. Idźcie sobie do Flame.

1 użytkowników online, w tym zalogowanych: 0, gości: 1