Ed z LowLevelLearning po angielsku bardzo sensownie wyrłumaczył mechanizm, aktualizacja kodu wykonywanego na poziomie jądra zawierała same zera, co najprawdopodobniej prowadziło do dereferencji nullpointera i crashu jądra w trakcie ładowania.
nie ma czego objaśniać, chmura + drivery działające w ring0 == fakap, a przynajmniej wysoki potencjalny impakt. Co ciekawe, w infrze którą ja zarządzam linuksowe agenty CS też dostawały "wyzerowane" binarki no ale tam nie ma modułów jądra tylko zwyczajny userspace code, więc po prostu wysypała się usługa flakon-sęsor i tyle ;d
Szanuję Cię Mati że w sposób nierzadko boleśnie łopatologiczny wykładasz race conditions grażynkom i panom areczkom o ile ci chcą słuchać. Naprawdę, poziom dostępności Twoich opracowań jest na tyle przystępny że mogę bez obawy o pytania doprecyzowujące wysłać linka wszystkim znajomym, od rodziców po kolegów frontendziarzy (okej, to nie koledzy ale liczą się jako odbiorcy linka xD) i mieć pewność że każdy zrozumie w wystarczającym stopniu. Chapeau bas.
ale na drugie brawa zasługuje balans pomiędzy ujawnianiem pewnych treści, pewnych podpowiedzi dla "złej" grupy odbiorców a maksymalnym rozrysowaniu przykładu wraz z analogicznymi wzorcami👌💣 Mati guru, mati muk by mnie uczyć dużo ❤😂😂
Myślę, że w materiale zabrało informacji, że podatność udało się przetestować tylko na systemach 32 bitowych, nie oznacza to, że 64 bitowe systemy nie są zagrożone, z publikacji wynika natomiast fakt, że zdobycie shella na systemach 64 bitowych może zająć znacznie znacznie dłużej.
Przypomina nam to też o zasadzie tak zwanego płotu Chestertone'a (mam nadzieje, ze tak się to pisze), czyli właśnie takiej sytuacji, kiedy widzimy coś, co się wydaje niepotrzebne, nie rozumiemy po co jest, a gdy to usuniemy - skutki potrafią być opłakane. W przypadku oryginalnego płotu Chestertone'a - miał to być rzeczywiście płot, dosłownie na środku pustyni w Australii, na pierwszy rzut oka będący tam zupełnie bez sensu. Jak się okazało po usunięciu - miał on bronić terenów zamieszkałych przez ludzi przed pustynnymi skorpionami, które po jego usunięciu zaczęły nękać mieszkańców, a wcześniej, w obliczu płotu zawracały na pustynię. A dziś ogólnie ideę najczęściej odnosi się do jakichś dawnych zwyczajów, które dziś wydaja się bez sensu.
*_Większość obecnych ruterów jeśli już ma SSH to w formie dropbear, więc można spać spokojnie. Jedynie trzeba się przyjrzeć NAS'om bo one mają "pełne" dystrybucje Linuxów. Trzeba też pamiętać, że w repozytoriach nie znajdziesz aktualnej wersji OpenSSH, musisz sam sobie ją pobrać, skompilować i zainstalować._* _Dzięki Mati, chyba korzystamy z tego samego źródła wiedzy o exploitach :D_
Produkujesz świetne materiały, ale jak usłyszałem, że rozwiązania asynchroniczne mogą tworzyć pewne problemy... Się poplułem, bardzo ładny eufemizm! I świetny materiał
Zapomniałeś dodać, że ten bug jest tylko w systemach 32 bitowych, więc od razu odpada 99% serwerów na świecie oraz że potrzeba ponad 10.000 połączeń - i trwa to około tygodnia. To zdecydowanie nie jest koniec świata i dlatego wynik CVSS jest "tylko" 8.1. Nie ma co siać paniki.
10:11 Jak miło słyszeć, że znowu komuś kawałek kodu wydawał się zbędny 😄 Inna sprawa, czy osoba, która dokonała tej zmiany była tylko niedoświadczona, czy doskonale wiedziała po co to robi. Moim zdaniem, w nowoczesnych IDE a nawet tych terminalowych edytorach jak VIM czy Nano powinne być chociażby jakieś ostrzeżenie po usunięciu czegoś z pozoru nieużywanego. Marzeniem byłoby aby zrobić taką funkcjonalność konfigurowalną i żeby pokazywała drzewiastą strukturę możliwych konsekwencji.
authentication failure/timeout czesany przez fail2ban (najlepiej z regułami recydywy), może knockd do tego i można spać spokojniej. Oczywiście do czasu, aż wylezie kolejny bug w iptables ;)
Jak się daje jakąś linijkę kodu, która jest ważna, a nie wygląda warto dać komentarz :) A jak się usuwa kod wyglądający na zbędny - warto sprawdzić opis commita w tej linijce ;) no chyba, że ktoś poprzenisil kod ;)
Zmiana portu ssh jest praktyczna, bo 99% _pukania_ jest na domyślny port bez sprawdzania. Zawsze też fail2ban z czasem na 24h przynajmniej (+ analiza logów w celu stałej blokady najbardziej natrętnych zakresów ip), zawsze przy pierwszym logowaniu po instalacji systemu ustawienie wymogu klucza o _odpowiedniej_ długości zamiast hasła, zawsze dla usług typu www umieszczanie wszystkiego w jailu i tam sftp a nie ftp itd itp. Od 20 lat na żadnym z wielu stawianych serwerow nie odnotowałem włamania, choć dziennie są setki prób. Poza jakimiś przypadkami w ramach zamknietej w jailu domeny, gdzie klienci mieli zabytkowe wersje swoich jedynie słusznych Wordpress'ów. Ale to byl wtedy wewnętrzny problem w konkretnej _klatce_ dla domeny, nigdy nie dla całego serwera. W przypadu serwerow plików połączenie tylko przez LAN i zdalnie przez openVPN, gdzie ten też tylko z logowaniem na indywidualnych kluczach.
szczerze, nie słyszałem gorszego wytłumaczenia race conditions, także jest różnica pomiędzy asynchronicznością i uruchamianiem rzeczy jednocześnie i sama asynchroniczność nie na tym polega i może być jednowątkowa
Mój szef działu IT duża firma, kłócił się ze mną że nie potrzebnie chce wyciąć 22 na iptables do kilu naszych adresów, 2 lata temu mówiłem że co jak będzie luka w sshd? i jest.
99% skanów idzie na porty 1-1024, bo tutaj chodzi o złapanie kogoś kto na pewno ma słabe zabezpieczenia lub ich brak. Ktoś kto zmienił port na inny z zakresu 1025-65536 nie jest już takim łakomym kąskiem, gdyż trzeba się domyślić czy np. ten port 38651 to SSH, a może RDP a może w ogóle coś innego. Po 2. tak jak wspomniał Mateusz, jeżeli już musimy mieć dostęp SSH przez publiczne łącze to zamknijmy je pod konkretne adresy IP a w ogóle to najlepiej za jakimś VPN-em
@@matix16 Ustawianie niestandardowego portu to jest "Security Through Obscurity", coś czego raczej nie chcemy, może dawać to fałszywe poczucie bezpieczeństwa a w niczym nie pomaga. Skanery nie mają problemu z identyfikacją usługi ssh, to nie ma żadnego znaczenia czy to jest port 22 czy 12345. Jeżeli ktoś chce ukryć swój serwer SSH to już lepiej skorzystać z knockd. Ustawienie niestandardowego portu przykuwa uwagę skanujących, być może ktoś kto zmienił port na niestandardowy myśli że to mu wystarczy i to może sprowokować dalsze próby ataku.
9:00 - jaki progres... - jak kolesie z OłpenSSH nie dali administratorom czerwonym tekstem przy starcie że machine owner w miarę możliwości i potrzebn powinie WYŁĄCZYĆ "Interactive Logon/password auth." o czym było już wiadomo od 20 lat że jest metodą podatną na wykorzystanie luk w szyfrowaniu, dopełnianiu haseł i wszelkie inne potencjalne tylko techniki a od 30 lat było to wiadomo o głupim udostępnianiu srików i utrawnień w MS to nie mam dla nich szacunku. Za darmo to sobie mogą punkty w sklepiku zbierać a nie udawać że rozwijają poważne oprogramowanie.
Z tego co zrozumiałem to na ubuntu pomimo 9.6 openssh jest ta luka już załatana przez team ubuntu? Tutaj padło też ciekawe stwierdzenie, że od 20lat to jest pierwsza odkryta luka w openssh... no właśnie... odkryta. A ciekawe ile takich luk istnieje od lat i które nie są nadal odkryte, podejrzewam że jest to wartość większa niż 0.
Zaskakuje mnie, że podczas pierwotnego latania podatności deweloperowi zabrakło wyobraźni aby dodać komentarz taki aby nikt później tej linijki kodu nie usunął.
pierwsza zasada refactoringu - kod, który widzisz został napisany w jakimś celu, zanim go zaczniesz zmieniać, zrozum dokładnie, po co tam jest. druga zasada refactoringu - opisy commitów w gicie są istotne. Miliony godzin kodowania zakończono revertem, bo ludzie tych dwóch zasad nie stosują.
Jak to ma się do systemów BSD? Czy na prawdę to wszystko Linuksy? Co z systemami BSD? Przecież BSD jest chyba lepsze na serwery, więc czemu to wszystko linuksy?
Przejęcie całkowite internetu to to rzeczywiście wyczyn. Jednak nawiększy wyczyn o jakim słyszałem to fakt przeczytania całego internetu przez Chucka Norrisa.
pamiętam jeszcze czasy, kiedy przed oddaniem programu należało udowodnić jego poprawność. Uczył o tym Wirth, Denny van Tassel, czy Iglewski z Madejem. Ale któż by się tym przejmował, jak produkt trzeba szybko sprzedać … No ale wolnego softwearu jednak się nie sprzedaje …
Zadne oprogramowanie nie może być "szczelne" bez furtek bo Amerykanie nie mogli by śledzić całego świata i zbierać informacje o tych co ich nie lubią ........ albo chcą im zrobić jakie kuku .........
