English

SE-2014-02 Komunikacja z producentami

Ta strona prezentuje informacje dot. przebiegu komunikacji z producentami oprogramowania w których produktach Security Explorations wykryło błędy bezpieczeństwa.

Podsumowanie procesu komunikacji:

  • 06-Gru-2014
- W rezultacie niemożności (zawieszone konto) zakończenia swoich badań, Security Explorations informuje firmę Google i opinię publiczną o projekcie badawczym SE-2014-02 oraz o odkryciu wielu błędów bezpieczeństwa w usłudze Google App Engine for Java.
- Google odpowiada, że firma jest zainteresowana informacją o odkrytych błędach.
- Security Explorations informuje Google, że potrzebowałoby kilku dodatkowych dni pracy nad projektem w celu doprowadzenia jego jakości do poziomu jaki zwykle mają raporty firmy przesyłane producentom. Firma pyta Google, o możliwość zniesienie blokady z jej konta GAE.
  • 07-Gru-2014
- Google odpowiada, że doceniłoby otrzymanie jakichkolwiek informacji o błędach jakie Security Explorations aktualnie posiada. Firma informuje, że zwykle zachęca zewnętrznych badaczy do zaprzestania testów w momencie odkrycia słabości bezpieczeństwa w jej systemach i umożliwienia kontynuacji pracy przez Google. Google informuje również, że zbada możliwość odblokowania konta GAE.
- Informacja o błędach wraz z towarzyszącymi kodami ilustrującymi zostają przesłana do Google (błędy 1-22, niepotwierdzone błędy 23-35).
  • 08-Gru-2014
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji. Firma informuje, że przeprowadzi dochodzenie zgłoszonych błędów w oparciu o dostarczone materiały i odezwie sie w przypadku pojawienia się nowych informacji.
- Oracle przesyła zapytanie, czy jakiekolwiek błędy odkryte w Google App Engine dotyczą jej produktów.
- Security Explorations informuje Oracle, że większość błędów jest specyficzna dla środowiska Google. Firma przesyła Oracle informacje oraz kod ilustrujący dla mało znaczącej słabości, która ma swoje źródło w kodzie Oracle Java (błąd 2).
  • 09-Gru-2014
- Oracle przesyła numer śledzący dla zgłoszonej słabości.
  • 10-Gru-2014
- Google informuje, że firma sprawdza otrzymane informacje oraz że udało jej się potwierdzić zgłoszone słabości lokalnie, jednakże w środowisku produkcyjnym, część z nich nie wydaje sie działać. Google pyta Security Explorations o metodologię użytą do testów w środowisku produkcyjnym.
- Security Explorations informuje Google, iż nie zdołało przetestować wszystkich kodów ze swojego lokalnego środowiska GAE w warunkach produkcyjnych. Firma przesyła Google informacje dotyczące metodologii użytej do utworzenia lokalnego środowiska GAE w celu opracowania kodów ilustrujących. Security Explorations prosi Google o przesłanie wyniku wykonania prostego programu w Javie w środowisku produkcyjnym GAE.
  • 11-Gru-2014
- Google informuje Security Explorations, że zgadza sie na kontynuację badań jeśli będą one ograniczone do JVM i nie będą dotyczyły następnej warstwy zabezpieczeń. Google nadmienia, że nie chciałoby, aby szczegóły kolejnej warstwy zabezpieczeń oraz szczegóły dot. monitoringu środowiska GAE stanowiły wiedzę publiczną.
- Google przesyła wynik wykonania programu w Javie w środowisku produkcyjnym GAE.
- Security Explorations zgadza się na propozycję Google i informuje firmę, że będzie kontynuować swoje badania w zakresie ograniczonym do warstwy Java VM środowiska GAE.
- Google informuje, że konto testowe GAE używane przez Security Explorations zostało odblokowane.
  • 12-Gru-2014
- Security Explorations przesyła Google 3 kody ilustrujące oraz informacje o słabościach (błędy 1-4).
- Google potwierdza otrzymanie i poprawne odszyfrowanie otrzymanych informacji.
  • 13-Gru-2014
- Security Explorations przesyła Google 4 kody ilustrujące oraz informacje o słabościach (błędy 5-9).
  • 15-Gru-2014
- Security Explorations przesyła Google 9 kodów ilustrujących oraz informacje o słabościach (błędy 10-21).
- Google potwierdza otrzymanie i poprawne odszyfrowanie otrzymanych informacji.
  • 17-Gru-2014
- Zespół inżynierów Oracle przesyła zapytanie dot. tego jak błąd 2 mógłby zostać wykorzystany do obejścia zabezpieczeń w kodzie firmy.
  • 18-Gru-2014
- Security Explorations odpowiada, że nigdy nie twierdziło iż błąd 2 mógłby zostać wykorzystany do obejścia zabezpieczeń w kodzie firmy, tylko że sekwencja kodu firmy Oracle może prowadzić do obejścia zabezpieczeń środowisk, w których zaimplementowane są listy dozwolonych klas (takich jak GAE). Security Explorations pyta Oracle, czy należy przyjąć iż błąd 2 nie jest słabością bezpieczeństwa w kodzie Oracle, lecz w kodzie firmy Google.
  • 19-Gru-2014
- Security Explorations przesyła Google kod ilustrujący oraz informacje o słabości (błąd 22).
- Google potwierdza otrzymanie i poprawne odszyfrowanie otrzymanych informacji. Firma informuje, że część poprawek zostanie wkrótce wypuszczona.
  • 20-Gru-2014
- Security Explorations przesyła Google kod ilustrujący oraz informacje o słabości (błąd 23).
- Security Explorations pyta Google, czy firma może oficjalnie potwierdzić jakiekolwiek ze zgłoszonych słabości.
  • 22-Gru-2014
- Security Explorations przesyła Google kod ilustrujący oraz informacje o słabościach (błędy 24-27).
- Security Explorations zmienia klasyfikację błędu 24. Firma przesyła Google zmodyfikowany kod ilustrujący dla tej słabości pozwalający na całkowite przełamanie bezpieczeństwa środowiska Java.
  • 23-Gru-2014
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji. W odpowiedzi na zapytanie dot. oficjalnego potwierdzenia zgłoszonych słabości, firma informuje, że jest w trakcie dokonywania wielu zmian w oparciu o otrzymany raport, włączając w to błędy które nie zadziałały [te przetestowane jedynie w lokalnym środowisku GAE], oraz że niektóre ze zgłoszonych słabości okazały się być spowodowane przez wspólny błąd / ich klasę, ale z kilkoma różnymi wektorami ataku. Google potwierdza, że raport Security Explorations zademonstrował iż jedna z warstw obronnych firmy zawierała niewystarczającą ochronę przed pewnym typem ataków oraz że analiza bezpieczeństwa uprzywilejowanych klas Java nie była wystarczająca.
- Security Explorations informuje Google, że chciałoby wiedzieć które błędy zostały potwierdzone, odrzucone lub są traktowane jako duplikaty, gdyż umożliwiłoby to wszystkim zainteresowanym stronom śledzenie postępu prac po stronie Google zmierzającego do poprawy zgłoszonych słabości. Firma prosi Google o ograniczenie powyższej informacji do słabości potwierdzonych w środowisku produkcyjnym po tym jak jej konto GAE zostało odblokowane (błędy 1-27 zgłoszone od 12 Gru 2014).
  • 24-Gru-2014
- Oracle przesyła informacje o stanie prac i statusie dot. zgłoszonych błędów. Firma informuje, że błąd 2 jest przedmiotem analizy / opracowywania stosownych poprawek.
- Google przesyła szczegółowy raport o stanie prac nad poprawkami. Firma informuje, że dla błędów zgłoszonych od 12 Gru 2014, 23 zostały zaakceptowane, a 4 działają zgodnie z zamierzeniem (nie są błędami). Google informuje również, że słabości 1-4, 13 zostały poprawione i że firma jest zainteresowana opinią dot. zgłoszeń zakwalifikowanych jako działających zgodnie z zamierzeniem (słabości 17-20).
  • 25-Gru-2014
- Google przesyła dodatkowe informacje do swojego raportu o stanie prac nad poprawkami. Firma informuje, że przyjęła 16 błędów (3 z nich oznaczone jako nie wymagające poprawki), pracuje aktywnie nad 5 słabościami, a do pozostałych zostały opracowane poprawki, jednakże nie wszystkie zostały wdrożone w środowisku produkcyjnym.
  • 27-Gru-2014
- Security Explorations przesyła Google swoje argumenty w odniesieniu do zgłoszeń 17-20 uznanych jako działające zgodnie z zamierzeniem, które wspierają ich klasyfikację jako błędy bezpieczeństwa. Firma informuje Google, że nie zgadza się z jej metodologią ewaluacji błędów ("słabości, które zadziałały okazały się być spowodowane przez wspólny błąd / ich klasę, ale z kilkoma różnymi wektorami ataku") oraz że będzie kontynuować śledzenie statusu zgłoszonych słabości z wykorzystaniem swojej oryginalnej numeracji.
- Security Explorations przesyła Google kod ilustrujący oraz informacje o słabościach (błędy 28-30).
  • 29-Gru-2014
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji. Firma informuje, że odezwie się wkrótce w nawiązaniu do przesłanych argumentów / komentarza.
  • 31-Gru-2014
- Security Explorations przesyła Google zmodyfikowany kod dla błędu 5 oraz dodatkowe informacje dot. zgłoszeń 17 i 18 uznanych jako działające zgodnie z zamierzeniem.
  • 06-Sty-2015
- Google informuje, ze błąd 28 został zaakceptowany. Firma przyznaje, ze w ogólności zgadza sie z tym, iż niektóre zgłoszenia zakwalifikowane jako działające zgodnie z zamierzeniem odbiegają od tradycyjnego modelu bezpieczeństwa Java, jednakże były one konieczne (obsługa aplikacji web, a nie appletów Java). Google informuje, że firma rozważa dodanie kilku dodatkowych mechanizmów wzmacniających bezpieczeństwo, które pomimo braku odwzorowania 1 do 1 do rekomendacji Security Explorations, powinny zapewnić równoważny poziom bezpieczeństwa.
  • 13-Sty-2015
- Google informuje, ze firma przygotowuje się do weryfikacji niektórych poprawek i oszacowania priorytetu dodatkowych mechanizmów bezpieczeństwa.
- Security Explorations przesyła Google kod ilustrujący oraz informacje o słabości (błąd 31).
  • 16-Sty-2015
- Oracle informuje, że jego zespół inżynierów przeanalizował zgłoszenie 2 i doszedł do wniosku, że nie stanowi ono błędu w Java SE. Tym samym firma zamknie zgłoszenie 2.
  • 19-Sty-2015
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji.
  • 02-Mar-2015
- Zapytanie dot. statusu prac nad poprawkami do zgłoszonych błędów wysłane jest do Google.
  • 03-Mar-2015
- Google odpowiada, że większość zaplanowanych zmian zostało zrealizowanych. Firma informuje, że zmiany dotyczyły wielu elementów platformy. Google pozostały jeszcze dwa "ważne" zadania nad którymi nadal aktywnie pracuje oraz wiele innych mniej-priorytetowych zadań, które nie zostały jeszcze rozpoczęte.
  • 04-Mar-2015
- Security Explorations informuje Google, że w oparciu o otrzymaną wiadomość nie jest jasne czy wszystkie zgłoszone błędy zostały poprawione. Firma prosi Google o bardziej precyzyjne informacje dot. statusu poprawek (nr zgłoszenia, poprawiony / w trakcie opracowania poprawki, itp.).
- Google odpowiada, że wszystkie błędy z wyjątkiem słabości 21 zostały poprawione i nie powinny już więcej zadziałać. Kilku inżynierów firmy pracuje nad zgłoszeniem 21, jednakże z uwagi na sposób w jaki GAE działa, jego usunięcie stanowi bardzo wolny proces i wymaga dużo manualnej pracy. Google informuje, że firma posiada inne mechanizmy zabezpieczające przed eksploatacją błędu 21.
  • 17-Mar-2015
- Security Explorations informuje Google, że jego mechanizmy zabezpieczające przed eksploatacją błędu 21 nie działają zgodnie z zamierzeniem. Firma przedstawia Google dowód ilustrujący tę tezę. Security Explorations informuje również Google, że poprawione środowisko GAE zawiera jeszcze więcej wewnętrznych informacji o Google niż w grudniu 2014. W ich skład wchodzą między innymi wrażliwe dane systemu GAIA takie jak konfiguracja logowania dla niektórych sieci klientów Google.
- Google informuje, że jest świadome tego iż błąd 21 może zostać użyty do czytania plików poza piaskownicą JVM, ale firma uznała to za akceptowalne ryzyko do czasu aktualizacji oprogramowania Java. W odniesieniu do pliku konfiguracyjnego systemu GAIA, Google informuje, że zawarte w nim informacje nie są poufne, bądź wrażliwe, jednakże plik ten nie powinien być obecny w GAE.
- Google informuje, że dodatkowa poprawka do błędu 21 została wdrożona w GAE i że kod eksploatujący tę słabość nie powinien juz zadziałać.
  • 18-Mar-2015
- Security Explorations prosi Google o przejrzenie zawartości wskazanego pliku konfiguracyjnego systemu GAIA i potwierdzenie, że "zawarte w nim informacje nie są poufne, bądź wrażliwe". Firma prosi o to samo w odniesieniu do innego pliku systemu GAIA.
  • 20-Mar-2015
- Google przesyła bardziej szczegółowe wyjaśnienie zawartości plików GAIA. Firma informuje, że pomimo tego iż ich zawartość może wyglądać na wrażliwą, nie zawierają one wrażliwych informacji z punktu widzenia bezpieczeństwa. Firma informuje również, że wykorzysta sytuację do ponownego przeanalizowania zawartości pliku(ów) jar w celu oceny zagrożeń dot. wycieku informacji.
- Raport bezpieczeństwa zawierający informacje o błędach wraz z programami testującymi zostają wysłane do Google (błędy 32-34).
  • 22-Mar-2015
- Raport bezpieczeństwa zawierający informacje o błędzie wraz z programem testującym zostają wysłane do Google.
  • 23-Mar-2015
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji.
  • 28-Mar-2015
- Security Explorations prosi Google o informacje w przypadku potwierdzenia zgłoszonych błędów.
  • 01-Kwi-2015
- Security Explorations przesyła Google dodatkowe szczegóły i kod ilustrujący do raportu o błędzie z dnia 22 marca 2015.
  • 03-Kwi-2015
- Security Explorations pyta Google, czy firma potrzebuje pomocy przy uruchomieniu otrzymanych kodów ilustrujących oraz czy potwierdzenie zgłoszonych błędów przez trzecią stronę taką jak US-CERT byłoby dla firmy pomocne. Security Explorations informuje Google, że oczekuje jasnego potwierdzenia, bądź odrzucenia informacji dot. zgłoszonych błędów bez względu na stan prac nad poprawkami.
  • 07-Kwi-2015
- Google odpowiada, że firmie udało się uruchomić wszystkie otrzymane kody ilustrujące. Firma potwierdza wszystkie zgłoszone błędy (32-34 w szczególności) oraz informuje, że niepoprawione słabości 23, 25, 26 i 27 z grudnia 2014 działają zgodnie z zamierzeniem (nie mogą zostać wyeksploatowane bez udziału innych słabości, firma może jednak usunąć niektóre z podatnych klas w przyszłości ze swojego środowiska).
  • 15-Kwi-2015
- Raport bezpieczeństwa zawierający informacje o błędach wraz z programem testującym zostają wysłane do Google (błędy 35 i 36).
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji.
  • 19-Kwi-2015
- Raport bezpieczeństwa zawierający informacje o błędach wraz z programem testującym zostają wysłane do Google (błędy 37-39).
  • 21-Kwi-2015
- Raport bezpieczeństwa zawierający informacje o błędzie wraz z programem testującym zostają wysłane do Google (błąd 40).
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji.
  • 23-Kwi-2015
- Raport bezpieczeństwa zawierający informacje o błędzie wraz z programem testującym zostają wysłane do Google (błąd 41).
  • 28-Kwi-2015
- Security Explorations pyta Google, czy firma potrzebuje pomocy przy uruchomieniu otrzymanych kodów ilustrujących oraz czy potwierdzenie błędów 35-39 zgłoszonych prawie dwa tygodnie temu ze strony opinii publicznej (subskrybentów list dyskusyjnych Bugtraq / Full Disclosure) byłoby dla firmy pomocne. Security Explorations informuje Google, że oczekuje jasnego potwierdzenia, bądź odrzucenia informacji dot. zgłoszonych błędów bez względu na stan prac nad poprawkami. Security Explorations prosi również Google o potwierdzenie otrzymania oraz poprawnego odszyfrowania raportu zawierającego informacje o błędzie z dnia 23 kwietnia 2015 (błąd 41).
  • 29-Kwi-2015
- Google potwierdza poprawne odszyfrowanie otrzymanych informacji dot. błędu 41. Firma informuje, że odezwie się wkrótce w odniesieniu do tematu potwierdzenia zgłoszonych błędów.
  • 06-Maj-2015
- Security Explorations informuje Google, że 3 tygodnie of zgłoszenia błędów 35 i 36, nie otrzymało ich oficjalnego potwierdzenia / odrzucenia. Security Explorations informuje również Google, iż historycznie, niepotwierdzone, bądź odrzucone błędy były przedmiotem natychmiastowej publikacji bez zawiadamiania producenta oraz, że uruchomienie kodów, przeczytanie raportu i/lub konsultacja z kodem źródłowym nie powinno zająć Google (i jego Zespołowi Bezpieczeństwa składającego się z kilkuset inżynierów w szczególności) dłużej niż 1-2 dni robocze. Security Explorations zawiadamia Google, że mając niepotwierdzony status przez producenta, słabości 35 i 36 zostaną wkrótce opublikowane. To samo dotyczy błędów 37-41 jeżeli pozostaną niepotwierdzone dłużej niż 3 tygodnie.
- Google potwierdza błędy 35 i 36. Firma informuje, że prześle aktualizację dot. statusu pozostałych błędów kiedy tylko będzie miała więcej informacji.
  • 11-Maj-2015
- Google potwierdza, że firmie udało się uruchomić kody ilustrujące błędy 37-41.
  • 16-Maj-2015
- Google przesyła informacje o stanie prac dot. zgłoszonych błędów. Firma informuje, że poprawki do błędów 35-36 zostaną wkrótce wdrożone oraz że poprawki do słabości 37, 38, 39 i 41 są poddawane testom. Wg planu, te ostatnie poprawki miały zostać zintegrowane z kolejną wersją oprogramowania GAE, jednakże Google rozważa teraz ich przyspieszenie. Firma informuje również, że błąd 40 nie został poprawiony z uwagi na znacząco mniejszą wagę z punktu widzenia bezpieczeństwa. W nawiązaniu do publikacji błędów 35-41, Google proponuje kilka kroków przywracających sprawną obsługę raportów bezpieczeństwa Security Explorations. Firma przywróci śledzenie błędów przy użyciu arkusza stosowanego przy pierwszej rundzie zgłoszeń i będzie go używać jako podstawowego źródła przekazywania Security Explorations aktualnych informacji dot. zaraportowanych błędów. Google będzie przesyłał wiadomości e-mail kiedy nowy raport zostanie poprawnie odszyfrowany, kiedy firma dokona oceny, czy dane zgłoszenie stanowi błąd (bądź nie) oraz kiedy planuje daną słabość poprawić. Google wyjaśnia również, że ujawnienie błędów 35-41 nie będzie miało wpływu na uprzednio przyznane nagrody programu VRP.
  • 28-Maj-2015
- Google przesyła szczegółowy, zbiorczy raport o stanie prac nad poprawkami. Firma informuje, że dla błędów zgłoszonych od 27 Gru 2014, 12 słabości (błędy 28-39) zostało zaakceptowanych i poprawionych. Błędy 40-41 zostały również zaakceptowane, ale nie są jeszcze poprawione (poprawione wewnętrznie 15 Maj 2015).
  • 25-Cze-2015
- Zapytanie dot. statusu prac nad poprawkami do błędów 40 i 41 wysłane jest do Google.
- Google odpowiada, że firma nie planuje podejmować jakichkolwiek działań w odniesieniu do błędu 40 oraz że poprawka do błędu 41 została wdrożona w środowisku produkcyjnym.
  • 26-Cze-2015
- Google przesyła zaktualizowaną wersję arkusza do śledzenia błędów. Zawiera on informację iż zgłoszenie 40 zostało ocenione jako działające zgodnie z zamierzeniem.
  • 30-Cze-2015
- Raport bezpieczeństwa zawierający informacje o błędzie wraz z programem testującym zostają wysłane do Oracle (błąd 42).
- Oracle potwierdza poprawne odszyfrowanie otrzymanego raportu. Firma informuje, że przeprowadzi dochodzenie zgłoszonego błędu w oparciu o dostarczone materiały i poinformuje wkrótce o otrzymanych rezultatach.
- Oracle przesyła numer śledzący dla zgłoszonej słabości.
  • 07-Lip-2015
- Oracle potwierdza błąd 42. Firma informuje, że zostanie on poprawiony w kolejnej wersji oprogramowania Java.
  • 24-Lip-2015
- Oracle przesyła informacje o stanie prac i statusie dot. zgłoszonego błędu. Firma informuje, że błąd 42 jest przedmiotem analizy / opracowywania stosownych poprawek.
  • 24-Sie-2015
- Oracle przesyła informacje o stanie prac i statusie dot. zgłoszonego błędu. Firma informuje, że do błędu 42 została opracowana stosowna poprawka, która zostanie udostępniona w ramach kolejnego CPU.
  • 24-Wrz-2015
- Oracle przesyła informacje o stanie prac i statusie dot. zgłoszonego błędu. Firma informuje, że do błędu 42 została opracowana stosowna poprawka, która zostanie udostępniona w ramach kolejnego CPU.
  • 17-Paź-2015
- Oracle przesyła raport o stanie prac nad poprawkami w nawiązaniu do planowanej publikacji CPU. Firma informuje, że poprawka do błędu 42 zostanie udostępniona w ramach aktualizacji Critical Patch Update, która zostanie opublikowana 20 października 2015.
  • 23-Paź-2015
- Oracle przesyła informacje o stanie prac i statusie dot. zgłoszonych błędów. Firma informuje, że aktualizacja Critical Patch Update z poprawką do błędu 42 została udostępniona.
  • 29-Paź-2015
- Security Explorations prosi Google o przesłanie informacji o numerach CVE odpowiadających błędom zgłoszonym w ramach projektu SE-2014-02 (błędy 1-41) oraz o lokalizację / referencje do informacji opublikowanych przez firmę komunikujących ich poprawienie.
  • 30-Paź-2015
- Security Explorations prosi Oracle o przesłanie informacji o numerze CVE odpowiadającym błędowi 42.
- Oracle informuje, że firma zbierze wymagane informacje i się wtedy odezwie.
  • 31-Paź-2015
- Google odpowiada, że błędy w GAE nie kwalifikują się do przyznania im identyfikatorów CVE, gdyż GAE jest usługą, która nie jest publicznie dostępna, ani jako część jakiegokolwiek kodu, czy też w formie binarnej. Firma informuje, że w nawiązaniu do informacji otrzymanej od MITRE, numery CVE nie są stosowane jeśli główną metodą usunięcia błędu jest akcja podejmowana przez operatora pojedynczego serwisu WWW lub usługi online. W odniesieniu do lokalizacji / referencji do informacji opublikowanych przez firmę komunikujących poprawienie błędów, Google informuje, że aktualnie nie ma czegoś takiego.
  • 02-Lis-2015
- Oracle przesyła numer CVE dla błędu 42.
  • 09-Gru-2015
- Google pokrótce informuje Security Explorations o nowej "wzmocnionej" wersji bezpiecznego środowiska GAE Java oraz o zastosowanym w nim podejściu (m.in. usunięcie menadżera bezpieczeństwa oraz translatora kodu, dodanie dodatkowych warstw bezpieczeństwa ponad środowiskiem Java).
  • 03-Paź-2016
- Security Explorations pyta Google, czy nowa "wzmocniona" wersja bezpiecznego środowiska Java została wdrożona w środowisku produkcyjnym GAE (przeprowadzone testy wykazały nadal obecność menadżera bezpieczeństwa Java).
- Google odpowiada, że firma porzuciła dotychczasowy mechanizm bezpieczeństwa Java i zastąpiła go technologią zapewniającą izolację, która zlokalizowana jest poza JVM. Google informuje również iż firma nie traktuje mechanizmu bezpieczeństwa środowiska Java jako pierwszej warstwy ochrony i że nie będzie poprawiać błędów umożliwiających jej obejście. Firma informuje, że pracuje nad całkowitym wyłączeniem ochrony Java, co zostanie przeprowadzone w ramach aktualizacji JDK, która jest w toku.
  • 25-Sie-2017
- Security Explorations informuje Google, że przeprowadzone testy wykazały nadal obecność menadżera bezpieczeństwa Java w środowisku GAE. Firma prosi o wyjaśnienie uprzednio podanych informacji / nieścisłości dot. statusu mechanizmów bezpieczeństwa Java w środowisku GAE.
- Google odpowiada, że mechanizmy bezpieczeństwa Java powinny być całkowicie wyłączone w nowym środowisku Java 8. Firma wyjaśnia, że dla środowiska Java 7, menedżer bezpieczeństwa nie został usunięty, aby przypadkowo nie zakłócić pracy aplikacji, nie jest on jednakże traktowany jako bariera bezpieczeństwa i można go całkowicie obejść uruchamiając bezpośrednio środowisko Java 8.

Copyright 2008-2017 Security Explorations. All Rights Reserved.