Artykuły dotyczące tematu: Java

dodany: 19.06.2013 | tagi: , , ,

Ważna aktualizacja Javy

0

Oracle wydało zapowiadany zestaw krytycznych poprawek dla Javy. Pakiet ten zawiera aż 40 poprawek. Nie zdziwi zatem nikogo fakt, że biuletyn ma status krytycznego. Aż 37 błędów wiąże się ze zdalnym eksplotitem, który może zostać przeprowadzony bez autentykacji! Zaledwie 3 stanowią lokalne zagrożenie.

Aktualizacji powinni dokonać użytkownicy wszystkich poniższych wersji:

  • JDK oraz JRE 7 w wersji 21 oraz wcześniejszych
  • JDK oraz JRE 6 w wersji 45 oraz wcześniejszych
  • JDK oraz JRE 5.0 w wersji 45 oraz wcześniejszych
  • JavaFX 2.2.21 i poprzednie

Pełna lista poprawek jest dostępna na stronie producenta. Kolejny ważny zestaw poprawek Javy zostanie wprowadzony 15 października tego roku.

 

dodany: 18.05.2013 | tagi: , ,

Nowy system wersjonowania Javy

0

Z powodu znacznej liczby poprawek bezpieczeństwa, które Oracle musiało wprowadzić do Javy, firma została zmuszona do zmiany sposobu wersjonowania aktualizacji. Początkowo przewidywalny system wersji stał się trudny do śledzenia po tym, jak każda krytyczna aktualizacja zwiększała liczbę przeznaczoną nań, w efekcie nachodząc na zaplanowane aktualizacje. Nowy sposób wersjonowania zostanie wprowadzony w JDK 7 i przeniesiony do JDK 5 i 6, jeżeli będzie to konieczne.

Zaplanowane aktualizacje otrzymają teraz wersje będące wielokrotnością liczby 20. Na przykład, następna aktualizacja JDK 7 przynosząca zmiany w funkcjonalności zostanie oznaczona jako 7U40, kolejna 7U60 i tak dalej. Jeżeli konieczne będzie wprowadzenie łatki bezpieczeństwa, wersja będzie obliczana przez dodanie wielokrotności liczby 5 do poprzedniego wydania, na przykład 7U45. Przerwy między wersjami wynikają z ewentualnych nieplanowanych wydań bezpieczeństwa (a znając szczęście Oracle możemy się ich spodziewać często).

Nowy sposób wersjonowania opisany jest jako kompromisowe  tymczasowe rozwiązanie. Długoterminowa wersja nadal jest w planach, ale prawdopodobnie zostanie wprowadzona dopiero w kolejnym wydaniu i ogłoszona wcześniej, aby umożliwić programistom aktualizacje narzędzi opartych na starym formacie wersji.

dodany: 25.04.2013 | tagi: , ,

Java 8 w 2014

0

Niektórzy mówią, że historia lubi się powtarzać. Biorąc pod uwagę fakt, że data premiery Javy 8 prawdopodobnie opóźni się, są to słowa bardzo prawdopodobne. Mark Reinhold wyjaśnia w swoim wpisie, że głównym czynnikiem, który wpłynął na kolejne przesunięcie premiery, jest praca nad łataniem krytycznych luk w obecnych wersjach Javy. Było to także przyczyną niepełnej implementacji Javy 8 Milestone 6, wydanej w styczniu bieżącego roku.

Siódmy kamień milowy również dostał więcej czasu, w nadziei, że pojawi się w nim obsługa lambd. W związku z tym oryginalny plan publikacji w listopadzie wydaje się niewykonalny. Reinhold proponuje wydać kompletne, testowe wydanie w czerwcu, a wersję poglądową dla programistów w listopadzie. W efekcie finalna wersja ukazałaby się w marcu 2014 roku.

Reinhold rozważa również inne opcje

Rezygnacja z wyrażeń lambda umożliwiłaby wydanie zgodne z pierwotnymi planami, ale nie zawierałoby ono wielu nowych funkcji, a same wyrażenia znalazłby się w Javie dopiero w 2016 roku. Pozostawienie lambd kosztem testowania zaowocowałoby powtórką z poprzednich błędów Oracle, takich jak problematyczne API. Jeszcze innym pomysłem jest opóźnienie premiery o rok, ale włączenie do wydania Projektu Jigsaw – Mark przypuszcza, że zajęłoby to wiele dłużej.

Najmniejszym złem będzie opóźnienie o co najmniej 3 miesiące, aby uniknąć premiery pod koniec 2013 roku. Reinhold wyjaśnia, że ta opcja nie otworzy drzwi nowym funkcjom, ale poprawi kwestie bezpieczeństwa.

dodany: 24.04.2013 | tagi: , , , ,

Adam znów atakuje Oracle

0

Oracle tradycyjnie nie naprawiło poprzednio zgłaszanych błędów przez Adama Gowdiaka wydając aktualizację Javy – niestety został spory peleton błędów, wysoce narażających bezpieczeństwo użytkowników.

Nowo odkryty problem niestety dotyczy nie tylko najnowszej wersji 1.7.0_21-b11, ale także poprzednich wydań 7 SE. To już 61 błąd odnaleziony przez Adama Gowdiaka – niestety jest on na tyle poważny, że pozwala na zupełne obejście sandboksa. Na pocieszenie pozostaje fakt, że do tego wymagana jest interakcja użytkownika, który musi zatwierdzić okno informujące o potencjalnie niebezpiecznej aplikacji.

Co ciekawe problem w przeciwieństwie do większości nie dotyczy wyłącznie środowiska uruchomieniowego Java, ale także samego serwera JRE. Oracle co prawda przyjęło zgłoszenie, ale z ich tempem trzeba będzie poczekać na stosowną reakcję. Firma ta nadal bada błędy o numerach 54 i 56 (zobacz newsa: Adam Gowdiak ujawnia szczegóły techniczne błędu w Javie).

dodany: 19.03.2013 | tagi: , , , ,

Adam Gowdiak ujawnia szczegóły techniczne błędu w Javie

0

Niecały miesiąc temu informowaliśmy Was o nowych błędach w Javie, które wykrył kolejny raz Adam Gowdiak (zobacz newsa: Java Second Error Edition raz jeszcze). Z braku reakcji firmy Oracle, Adam postanowił ujawnić szczegóły techniczne słabości numer 54 zgłoszonej firmie Oracle 25 lutego 2013 i uznanej jako „dozwolone zachowanie”, a nie „błąd bezpieczeństwa”. Na stronie firmowej Adama widzimy następującą informację:

Na dzień 18 marca 2013, firma Oracle nie przesłała żadnej informacji wskazującej na to, że słabość 54 jest traktowana przez firmę w kategoriach błędu bezpieczeństwa.

Security Explorations wierzy, że 3 tygodnie (od 25 Lut do 18 Mar) stanowią wystarczający okres, aby jeden z większych producentów oprogramowania ostatecznie potwierdził, bądź zaprzeczył istnieniu zgłoszonego błędu. W szczególności dotyczy to producenta, który był przedmiotem znaczącej krytyki w odniesieniu do prezentowanych kompetencji i szybkości odpowiedzi na błędy bezpieczeństwa odkryte w jego oprogramowaniu. 

Security Explorations opublikowało następujący materiał w nadziei, że szeroka publiczność będzie mogła poddać niezależnej analizie błąd numer 54, jak też ocenić stanowiska obu firm:

  • krótki raport techniczny prezentujący szczegóły błędu, jego znaczenie oraz podsumowanie odpowiedzi producenta, plik PDF, 300KB.

Referencje:

[1]SE-2012-01 Komunikacja z producentami (www.security-explorations.com/pl/SE-2012-01-status.html)

 

Miejmy nadzieję, że może to zmusi Oracle do działania, a nie ciągłej ignorancji na zgłaszane błędy.

dodany: 11.03.2013 | tagi: , , , , ,

Firefox i Chrome załatane dwa dni po odkryciu nieznanych eksploitów na Pwn2Own

0

6 marca rozpoczął się konkurs Pwn2Own, który oferuje ponad pół miliona dolarów w gotówce oraz inne nagrody dla pierwszej osoby, która odkryje słabość wybranego celu. Pierwszego dnia w menu znalazły się  przeglądarki Firefox na Windowsie 7, Internet Explorer na Windowsie 7 (9) i 8 (10), Firefox na Windowsie 7 oraz Safari na OS X Mountain Lion oraz wtyczki w IE 9  Adobe Reader IX i Adobe Flash oraz Java od Oracle.  Jeszcze tego samego dnia padły przeglądarki Firefox, Internet Explorer 10, Chrome i wtyczka Java. Safari została ostatnim, jeszcze niezdobytym bastionem wśród przeglądarek.

Drugiego dnia padły wtyczki Adobe Reader IX i Adobe Flash oraz ponownie Java.

8 marca Mozilla i Google wypuściły aktualizacje naprawiające znalezione dzień wcześniej eksploity.

Firefox przeszedł do wersji 19.0.2 naprawiając Use-after-free w edytorze HTML:

mozilla_advisory

Exploit występował tylko na komputerach z systemem operacyjnym Windows, dlatego jeśli jesteście użytkownikami Firefoksa na Linuksie czy Macu nie musicie niczego aktualizować.

Chrome przeszło do wersji 25.0.1364.160 naprawiając Type confusion in WebKit.

chrome-update

Microsoft nie był tak szybki z aktualizacją swoich wersji przeglądarek i zapowiedział, że aktualizacja, która pojawi się jutro  z przyczyn oczywistych nie będzie zawierać eksploitów znalezionych w czasie konkursu. Najprawdopodobniej poprawki znajdą się w następnych Patch Tuesday – w kwietniu.

Gdyby jednak udało się im wypuścić poprawkę przed kolejnym Patch Tuesday, Microsoft mógłby na tym dużo zyskać. Byłby to fantastyczny manewr marketingowy. Ale jedynym, co nam pozostaje, to czekać.

dodany: 08.03.2013 | tagi: , , ,

Uwaga na podpisany malware w Javie

2

Mało tego, że samo posiadanie zainstalowanej maszyny Java jest wysoce niebezpieczne, to na dodatek pojawił się cwany malware zaszyty w pliku JAR. Ma on oczywiście celowo mylną nazwę – ClearWeb Security Update. Drugim aspektem zwiększającym jego wiarygodność jest podpisanie certyfikatem istniejącej firmy CLEARESULT CONSULTING INC. Zawarty malware pochodzi prawdopodobnie z zestawu eksploitów o nazwie g01pack.

Złośliwy podpisany aplet

Podpisany złośliwy aplet.

Niestety Java „w trosce” o bezpieczeństwo podczas uruchamiania pliku sprawdza jedynie, czy jest podpisany – to czy certyfikat jest ważny wg Oracle nie ma znaczenia. Zważywszy na to, że zdecydowana większość użytkowników nie sprawdza szczegółów certyfikatu, część użytkowników uruchomi aplet, instalując tym samym malware w swoim systemie.

Ów certyfikat został prawdopodobnie skradziony. Z tego też powodu został odwołany 7 grudnia 2012 roku. Skradziony klucz był prawdopodobnie prywatnym.

Zapewne nie mamy co liczyć, że Oracle zmieni zasady uruchamiania apletów, dlatego pozostaje nam zdrowy rozsądek i dokładne przejrzenie certyfikatu przed kliknięciem przycisku RUN.

dodany: 05.03.2013 | tagi: , , ,

Puk, puk. Kto tam? Java update!

0

Oracle wydało poprawkę adresowaną do najnowszego exploita kierowanego w oprogramowanie. Firma sugeruje użytkownikom jak najszybsze jej zainstalowanie. Jest ona dostępna do pobrania za pośrednictwem strony Oracle lub przez auto-aktualizację oprogramowania na komputerach.

Luka, która wymaga załatania jest wykorzystywana do instalacji trojana zdalnego dostępu McRat. Ataki kierowane są na wersje Javy 1.6  Update 41 i 1.7 Update 15, które są najnowszymi dostępnymi wersjami oprogramowania.

Kolejne aktualizacje Javy powoli przestają śmieszyć. Bezpieczeństwo Javy pozostawia wiele do życzenia. Nie wspominając już o ostatnich atakach na Facebooka, Apple czy Twittera.

Dołączamy się do apelu Oracle – instalujcie aktualizacje najszybciej, jak to możliwe. Albo – jeszcze lepiej – jeśli Java nie jest Wam potrzebna, włączajcie ją tylko w stanie absolutnej konieczności.

dodany: 01.03.2013 | tagi: , ,

Powiązanie zero-day Javy z wpadką Bit9

0

Pamiętacie ostatnią wpadkę firmy Bit9? Zgadnijcie co  wykorzystano w najnowszym błędzie zero-day Javy. Wszystko to powiązano z luką opisaną pod CVE-2013-1493. W rezultacie tego błędu możliwe jest wykonanie dowolnego kodu – w tym celu podrzucany jest trojan.Naid (nazwa zdefiniowana przez Symanteca). Jest on zawarty w złośliwej bibliotece DLL. W następstwie jego działania zainfekowana maszyna nawiązywała komunikację z serwerem Command-and-control (C&C), który był zlokalizowany pod adresem IP 110.173.55.187.

Jak się okazało owy trojan został podpisany wykradzionym certyfikatem od Bit9. Na poniższej grafice przedstawiono schemat działania:

 

symantec Bit 9

Atak rozpoczyna się odwiedzeniem strony z złośliwym plikiem JAR, który został ochrzczony przez Symanteca jako Trojan.Maljava.B. Złośliwiec ten wykorzystuje lukę opisaną w/w CVE-2013-1493. Jeśli inicjalizacja trojana się powiedzie, to następnie jest pobierany plik svchost.jpg, który w rzeczywistości jest dropperem. W rezultacie jego działania na komputerze umieszczana jest złośliwa biblioteka appmgmt.dll, która zawiera właśnie owego trojana Naid.

Ten sam rodzaj ataku stwierdziła firma FireEye – badacze zauważyli, że problem ten występuje w przypadku Javy v1.6 z aktualizacją nr 41 i Javą v1.7 z aktualizacją nr 15.

dodany: 27.02.2013 | tagi: , , ,

Java Second Error Edition raz jeszcze

0

Ledwo 19 lutego wyszła nowa Java (zobacz newsa: Oracle aktualizuje Javę), a już Adam Gowdiak znalazł w niej dwie poważne luki. Niestety z uwagi na krótki czas od ich wykrycia nie są podane szczegóły problemu, gdyż groziło by to kolejnymi szeroko zakrojonymi atakami. Niewykluczone, że ma to związek z ostatnim atakiem na Facebooka. Wiadomo jedynie, że wiąże się to z możliwością obejścia sandboksa Javy, czyli podstawy prawie każdego środowiska programu JRE.

Adam przedstawił dwa błędy ze stosownymi dowodami na ich istnienie. Są to już odpowiednio 54 i 55 wykryte przez firmę Gowdiaka nieprawidłowości w produkcie Oracle.

Na razie wiadomo jedynie, że firma potwierdziła przyjęcie zgłoszenia wspomnianych luk przez Security Explorations oraz podjęła dochodzenie przyczyny tych problemów. Niestety firma wręcz z tradycją zwleka z ich naprawianiem – na razie udało im się naprawić błąd ze zgłoszenia nr 51.

Jak tylko coś będzie wiadomo w tej kwestii, to na pewno Was poinformujemy.