Krytyczna luka w kluczowych routerach Junipera
- Dodano: 7 January 2010
- Wprowadził: hcsl.pl
- Komentarze: 25
Juniper Networks, jeden z największych na świeci producentów aktywnych urządzeń sieciowych, ostrzegł wczoraj swych klientów przed krytyczną luką w systemie operacyjnym JUNOS.
Szereg urządzeń pracujących pod kontrolą systemu JUNOS podatna jest na awaryjne zakończenie pracy w wyniku odebrania specjalnie spreparowanych segmentów TCP. Błąd ten obecny jest w oprogramowaniu w wersjach od 3 do 10. Co najgorsze, nie ma żadnego sposobu na zabezpieczenie urządzeń zawierających dziurawe wersje systemu. Nie pomoże nawet jakiekolwiek filtrowanie pakietów za pomocą funkcji ACL (ang. access control list). Producent opublikował już jednak odpowiednie poprawki bezpieczeństwa.
Problem jest o tyle poważny, że wiele z najważniejszych routerów internetowych oraz urządzeń wchodzących w skład największych sieci komputerowych to właśnie urządzenia marki Juniper. Do czasu zastosowania odpowiednich poprawek bezpieczeństwa, każde z tych urządzeń pozostanie podatne na zdalny atak.
Materiał pochodzi z serwisu HARD CORE SECURITY LAB.
Więcej informacji: http://www.theregister.co.uk/2010/01/07/...outer_bug/
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
25 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
hmm freebsda też jest zagrożona?
nie musi. Junos to własnościowy system, a jego kluczowe innowacje nie są do FreeBSD włączane.
wiem że nie musi ;p dlatego się pytam.
trasz się chwalił że dużo kodu juniper zwraca z powrotem, a ta dziura trochę już istnieje skoro obejmuje tyle wersji systemu.
Nie wiadomo, czy dotyczy to FreeBSD, na którym rzeczywiście JUNOS bazuje. Co najgorsze, nie wiadomo dokładnie na czym polega ta luka – niestety Juniper prowadzi politykę przekazywania dokładnych informacji o lukach wyłącznie swoim zaufanym klientom
. Wiemy tylko, że chodzi prawdopodobnie o jakąś kombinację bitów w opcjonalnym polu Opcje w segmencie TCP.
Jeśli błąd istnieje też we FreeBSD to ciekawe czy Juniper będzie skłonny się tym podzielić skoro oznacza to de facto "full disclosure" błędu
Ja właśnie rozpracowałem firmware (oparte na Linuksie) jednego z znanych producentów rejestratorów do monitoringu CCTV i poza znalezionymi poważnymi lukami zauważyłem, że ma backdoora zgłaszającego producentowi domenę, adres IP rejestratora i komputera i umożliwia zdalny dostęp na roota + kilku użytkowników (zmiana w użytkownikach w konsoli zarządzania rejestratorem nie rusza tych systemowych ustawionych przez producentach). Oczywiście w dokumentacji nie ma o tym ani słowa, a rejestrator jest dedykowany głównie do wystawiania w Internecie. IMO nie tylko narusza to licencję GPL (firmware w postaci binarnej opartej na jednej z typowych dystrybucji Linuksa bez dostępu do kodu źródłowego i nawet w dokumentacji o tym nie wspominają), ale też naraża klientów na ataki i zdalną kontrolę producenta. Teraz zastanawiam się co zrobić z tym dalej… Fakt (podejrzenia) naruszenia licencji GPL i dziur to mógłbym zgłosić producentowi, ale… backdoor wygląda na celowe działanie wykonane przez producenta (te samo można znaleźć w każdej aktualizacji firmware tego producenta pobieranej z jego strony internetowej lub FTP).
intrygujące. Możesz podać jakieś szczegóły? (oczywiście takie, które nie ułatwią wykorzystania tego backdoora)
Pierwsze podejrzenia padły jak podłączałem się przez przeglądarkę na adres IP rejestratora (http://ip_rejestratora/) – zostałem momentalnie przekierowany (refresh) na link będący odnośnikiem do strony producenta z adresem IP i nazwą rejestratora w zapytaniu HTTP_GET (widoczne na pasku adresu w przeglądarce: http://…/…?ip=...), po czym ponowne przekierowanie na http://ip_rejestratora/web.html, więc postanowiłem zainteresować się czego producent chce ode mnie
…
Potem zabrałem się za analizę pliku firmware dostępnego jako aktualizacja oprogramowania dla rejestratora…
Opisz na bugtraq – to luka w bezpieczeństwie.
Prześlij te dane do FSF i SFLC.
tylko powiedz ze nie planet..
Nie, to akurat firma, która specjalizuje się właśnie głównie w CCTV. Przy okazji szukania oprogramowania do zarządzania tymi rejestratorami znalazłem podobne firmware w rejestratorach również kilku innych firm. W wolnym czasie też je "przebadam" czy przypadkiem nie zawierają czegoś podobnego. Chyba rzeczywiście problem zgłoszę gdzieś dalej…
Koniecznie zgłoś. Wiele firm zarabia na Linuksie, nie dając nic w zamian. Licencja BSD na to pozwala, ale jeżeli GPL nie, to powinni jej przestrzegać. Zgłoszenie może się skończyć tylko dobrze (ale nie dla firmy
). No i po zgłoszeniu nie Ty się zajmujesz sprawą, więc nie ma obaw że będziesz ciągany po sądach. Co najwyżej przejdziesz się na komisariat złożyć zeznania – miałem podobną sytuację w wykorzystywaniem artykułów z linux.pl. Sprawa zakończyła się grzywną, przeprosinami i… satysfakcją pokrzywdzonych 
"Core'owy" potworek razi. Dlatego my, lud pracujący miast i wsi, domagamy się utrzymania wysokiej jakości w całości tekstów hcsl, łącznie z tytułem!
Jak proponujesz to zapisać
?
Krytyczna luka w niektórych routerach Junipera
Krytyczna luka w popularnych routerach Junipera
Krytyczna luka w routerach Junipera
Ale "popularny" ani "niektóry" nie jest tłumaczeniem słowa "core"; można silić się na jakieś rutery "centralne", ale po co?
Chodziło mi o zachowanie znaczenia
. "niektóre", "popularne" itd. nie oddaje tego co znaczy tu słowo core'owe.
Przecież to nie jest tłumaczenie… Chyba, że tłumaczenie się.
Cokolwiek, byle nie korowy
CLR syndrome?
@hcsl.pl: Core'owy tłumaczy się na polski jako rdzeniowy.
w kontekście sieciowym będzie to ruter szkieletowy ew. ruter sieci szkieletowej
No tak, ten szkieletowy chyba byłby najlepszym polskim odpowiednikiem.
W kontekście sieciowym jak najbardziej tłumaczy się jako rdzeniowy, co prawda w odniesieniu do switchy, więc rzeczywiście szkieletowy chyba tu najlepiej pasuje.
Korowy, czyli wykonany z kory drzewnej.
Cieszę się, że nie jestem pierwszym porażonym tytułem czytelnikiem.