Podczas gdy Pan Mateusz ładnie gawędził o temacie filmu, mój mózg nie mógł przestać się wpatrywać w białe coś w tle co przy zmrużeniu oka wygląda jak jakaś twarz ducha :D
Czyli co jako że pęk kluczy Apple jest systemowy to może być w tym przypadku bardziej podatny na tą lukę czy ratuje go to że najczęściej żeby wypełnić hasło trzeba użyć Pinu / FaceID / TouchID?
Serio??? Kompletnie niepotrzebne politykowanie, w kontekście, który w żadne sposób tego nie uzasadnia. Do tego aluzja mało wyrafinowana i potencjalnie nakręcająca przemysł pogardy trawiący naszą przestrzeń publiczną. Bardzo lubiłem filmy z tego kanału, ale teraz mocno stracił w moich oczach…
Pragne tylko małą poprawke od siebie dodać; Architektury procesorów od samego początku były ulepszane nie tylko pod kątem "wincyj GHZ" i "wincyj rdzenióf". Sam pipelining jest przeskokiem gdzie komputery z MOS 6502 zeszły do Motorola 68000. Kwestia tego, że pipelining jest ograniczony prędkością dostępu do ramu po to też i jest L1C, by saturować pipeline i nie stallować go. Przy pentium 1 dochodzi port FPU i superscallar, możliwość odpalenia dwóch instrukcji w jednym cyklu pod warunkiem że jedna z instrukcji jest instrukcją FPU. Jak już dochodzi pentium pro/2 i out of order execution, to chodzi o saturowanie portów, ilość portów, preventing stallingu. Dochodzą 2 porty MMX, jeden do ładowania/zapisu danych, moduł retirera. Im dłuższy pipeline, tym większy koszt branch misspredictu przy cache missu, ale łatwiej było wbić GHZ. Koszt ten był czasem w ilości cykli zegara procesora w którym procek dopiero zaczynał rzeczywiście wykonywać instrukcje. "Wincyj GHZ" okres w którym Intel wydał Pentium 4 a później P4 Extreme 3.8Ghz, był też okresem w którym AMD wydawało procesory oznaczone prędkością w mhz odpowiadającą procesorowi Pentium 4 będące gdzieś o ghz nawet wolniejsze. Procesory powerPC G4. Możliwie nie czytałem zbyt dużo na temat tego co się działo między pentium 4 do teraz, ale ciężko jest sobie wyobrazić, że jedyną innowacją było wincyj GHZuf i rdzeniuf znając historie tego jak się to potoczyło wcześniej. Ja tak to widzę, że wszystko od samego początku rozgrywało się o maksmalizacje saturacji, redukcje czasu spędzonego na niczym(stall), redukcje szansy na wystąpienie stallu itp. Ale warto pewnie też dodać. Że ilość "ghz" jest limitowane przez architekture poszczególnych części procesora, dekodera, cachea, alu, register renamingu, retire-ra itp. pod pewnymi względami liczyć się może czysty teoteryczny maksymalny throughput gdy nic nie idzie się jebać podczas egzekucji w dupe. Wiec ostatecznie to czy "wincyj GHZ"/"wincyj PORTÓW" czy "mniej STALLu"/"wincyj SATURACJI" jest lepsze, jest czysto statystyczną zależnenością. "Wincyj rdzeniów" to poprostu wincyj kontekstów egzekucyjnych plusem takiego rozwiązania jest to że stall w jednym z rdzeniów lub wątku nie jest stallem w drugim wątku/rdzeniu. Przy wątkach stall może występować zewzględu np. na to że wątek nie ma dostępu do portu odczytu danych, więc wykonuje się OOE, branch predictor w końcu miśnie i idzie się jebać pipeline w wątku blog.cloudflare.com/branch-predictor/. Nawet taki buldozer, z założenia miało to umożliwić sharowanie portów(czyli unitów na które można schedulować wykonanie instrukcji procesora), między dwoma rdzeniami tylko w kontekście 2 rdzeniów. Różnica między wątkiem a rdzeniem jest taka, że wątek może schedulnąć cały rzeń, a moduły mogły sharować między sobą tylko FPU. Założenia zakładam że mogły być 2 przy takiej architekturze: mniejszy rdzeń, więcej rdzeniów, większy yield; lub zmniejszenie czasu w którym istnieje nie saturowany port w kontekście dwóch rdzeniów/modułu, czyli możliwość on-demand zwiększenie IPC dla jednego rdzenia kosztem drugiego(w czasie gdy nie potrzebuje on tego unita koszt jest zerowy). Przy "wincyj rdzeniów" w pewnym momentie nawet z memory cachingiem brakuje już memory bandwidtha by to wszystko obsłużyć. Znowóż wraca też do nas informacja, że limitacją prędkości cache jest fizyczny rozmiar ścieżki doprowadzającej dane z cache do procesora. Może tutaj też jest mój brak wiedzy bo ja czytałem z podręcznika pentium 2, ale czy przypadkiem spekulacyjna egzekucja wykonuje kod który NIE jest zależny od wyniku operacji, jedyne co jest tak predictowane to branche(czyli flow egzekucji) poprzez accounting na temat poprzedniego wyniku operacji brancha . Tak istnieje też defaultowe założenia, gdy branch nie znajduje się w tablicy accountowanych branchów i jeśli dobrze pamiętam to założeniem tym jest że procesor nie skacze do instrukcji w branchu. Bo przecież nie są dodawane do siebie przecież żadne dane z komórek pamięci do których procesor nie ma dosłownie jeszcze dostępu, bo to kompletnie bez sensu by było i wynik takiej operacji w 90% wymuszał by pipeline reset i wypierdolenie shadow stacka do śmietnika. Chodzi głównie o to że gdy nie ma czegoś w komórce L1 cache, to procesor zaczyna odpalać kod do przodu ten który może on wyliczyć wylicza, ale branche są predictowane tak by preventnąć stall. Generalnie prawdopodobieństwo wystąpienia brancha po kalkulacji jakieś jest, nie każdy workload jest czystym crunchem na danych bez żadnego ifa/brancha(w przypadku MMX to akurat te IFy będą bez branchowe w postaci maski 0x00/0xFF) i przy crunchach na danych nie można powiedzieć, że każdy loop jest unrollnięty do końca(nie tylko by nam zabrakło L1C xD). Jako że prawdopodobieństwo że branch skończy się tak samo jest większe niż mniejsze(przyśpiesza to długie jak i niekończące loopy, sytuacje gdy system operacyjny sprawdza czy mamy dostęp do pliku i najczęściej program o taki plik się zapyta do którego ma dostęp niżeli o taki do którego nie ma dostępu).
*_Jednak warto zaznaczyć, że ewolucja procesorów komputerowych w ostatnich latach skupia się również na efektywności energetycznej, co prowadzi do tworzenia coraz bardziej zaawansowanych rozwiązań, takich jak architektura wielordzeniowa, co może przynosić korzyści w kontekście zarówno wydajności, jak i oszczędności energii. Ponadto innowacje w dziedzinie architektury procesorów często wynikają z potrzeb związanych z nowymi technologiami, takimi jak sztuczna inteligencja czy obliczenia w chmurze._*
Mateusz, a co z managerem Apple, skoro wymaga on każdorazowo autoryzacji przez TouchID, nie ma tu autouzupełniania. Więc jak to wygląda pod kątem tej podatności?
Dobry materiał. Dobrze to pokazuje jak zamknięty system apple mocno utrudnia profilaktykę i workaroundy takich podatności. Bardzo tez niepokoi ignorancja apple na tą lukę ciekawe czy m3 też jest podatne bo mogli tego uniknąć
pytanie, czy to ignorowanie, czy przeliczenie, że ryzyko skutecznego ataku jest mniejsze niż wkurzenie się użytkowników i ich negatywna ocena, za zwolnienie systemu. Gdy taka luka wyszła kilka lat temu w intelu, to łatanie kosztowało jakieś 30% mocy obliczeniowej ówczesnych procków. Przez co mój lapek kupiony jakiś rok przez wyjściem łatek, jest właściwie nie używalny w trybie pawersafe. Więc to może być po prostu finansowa kalkulacja...
@@toudisajfaj takie przeliczenie to chyba nawet gorsze bo znacząco przeciw polityce marketingowej apple. Ale efekt jak na razie taki sam: brak działania i brak łatki
@@BxOxSxS, tu trzeba zwrócić, że większość użytkowników Apple, to fanatycy, póki Apple do czegoś się nie przyzna, lub tego nie wprowadzi, to to nie istnieje. Oni będą dalej kupować ten sprzęt i go chwalić. Znam to z autopsji, kierowani ich do takich materiałów jak ten ich nie przekonuje, bo to nie jest źródło godne zaufania. Dopiero gdyby Apple wydało w tej sprawie komunikat, to problem by dla nich zaistniał.Apple wychowuje swoja sektę od dawna. Więc takie wyparcie ma dla nich sens.
@@toudisajfajnie fanatycy, tylko ludzie, którzy nie chca/ nie maja siły/ nie umieja/ nie maja czasu na np konfigurowanie linuxa i utrzymywanie go, liczac ze jakas aktualizacja nie rozwali ich pracy. W kwestii urzadzeń mobilnych - urzadzenia z androidem maja wsparcie max 2 lata, szybko się psuja i zamulaja, a np 5letni ipad działa jak nowy. Chyba ludzie o których mówisz to 12letnie dzieci, którym mama kupiła ajfona.
Ciekawe, ale jak ten mechanizm działa na MacOS, skoro Apple za każdym autouzupełnianiem, wymaga autoryzacji do systemu, np wpisanie hasła do systemu albo dotknięcia touchid? Szukałem opcji do wyłączenia tego zabezpieczenia, ale nie znalazłem.
A jak to jest z kluczami sprzętowymi? Rozumiem, że moment definiowania PIN-u w takim kluczu też jest zagrożony chociaż teoretycznie chroni nas fizyczna saparacja klucza od atakującego.
@@Banerled To nie ma znaczenia. Tak samo jak przytaczany 50 letni procesor nie ma nic wspólnego ze współczesnymi. Rozkazy tych dziadków to nawet nie 5% puli rozkazów współczesnych.
Właśnie miałem wyciek swojego hasła z i cloud znajomy mówił że oryginalna przegladarka aple i faktycznie wywaliło mnie z konta przez dostanie sms od znajomego i wtedy wylogowało nie wiem jeszcze jak to zrobił druga sprawa to włamał mi się też do routera i chyba wgrał wirusa bo w pewne pory o stałych godzinach prędkość internetu spada ze 100na 5-10 mb a wysył w kilobajtach już wymieniłem 2 razy router za każdym razem parę dni było wszystko ok przyszedł znowu posiedział w aucie i wywaliło mi internet całkiem miałem zrobić reset routera i z powrotem zaczęła spadać prędkość o stałych godzinach możecie mi jakoś pomóc?
Czy korzystanie z pęku kluczy nie rozwiązuje tej sytuacji? Przecież aby udostępnić w nowym oknie dane logowania, muszę autoryzować pęk kluczy do przekazania tych danych do nowego okna przeglądarki/aplikacji.
Wgl Prawo Moora to ciekawa rzecz, bo nie jest prawem w rozumieniu jak w np. fizyce gdzie prawo oznacza coś co jest i będzie. Te "prawo" to ładna zbieżność/obserwacja zjawiska.
No dobra, ale mam pytania: do poczty zwykle się używa apki, do banku też. Nawet hasła z Applowego managera też się odblokowuje face id. Czy to nie ogranicza podatności, jeśli np. nie jestem zalogowany w przeglądarce do mojego konta google albo banku używam tylko biometrią w apce i nie mam zapisanych sekretów?
Prad jest przemienny, a nie zmienny. Przemienny to taki ladny sinus, a zmienny to lata jak chce. Ofc jest tutaj ta sama zasada co z prostokatem i kwadratem, jednak o tym w gnizdku mowimy przemienny. Na wiki jest to bardzo ladnie rozrysowane.
No tak ale luka została znaleziona przez badaczy i najpierw zgloszona do Apple, wiec zanim nakowcy ujawnią wszystkie szczegóły to Apple jakoś to „załata”. Albo zrobi Update systemu np osobna aplikacja z hasłami i po sprawie.
Największymi niebezpieczeństwem naszej prywatności i tak są sami użytkownicy ktorzy na lewo i prawo podają hasła bez zastanowienia, największe wycieki danych to pikuś do naiwności i głụpoty ludzi.
@@BxOxSxS Właśnie też to tak rozumiem. Jednak przy tej prędkości + możliwość przerwania procesu zamknięciem karty w przeglądarce daje bardzo małe możliwości realnego użycia ataku a tym bardziej kradzieży haseł.
@@donio4 Nie zgadzam się. Są pewne ograniczenia ale gdy ofiara nie jest świadoma ataku i dodać do tego sociotechnikę to ma to duże możliwości. Gdy znamy np email ofiary (bo np strona emituje rejestrację na nowy serwis) można np wysłać prośbę resetowania hasła na inny portal i następnie ją odczytać podczas gdy ofiara myśli że czeka na link aktywacyjny do nowego konta. Scenariusz wymyślony w kilka sekund a pewnie są lepsze
_Nie, to poprzez wiele innych czynników wbudowanych w environment a właściwie elementy rdzenia, kolejek zadań o znacznikach danych procesów, a Safari to tylko ich nakładka jak i wiele innych procesów aktualnie korzystających z CPU._
ojoj, niemożliwe - nikt by się nie spodziewał. Serio :D Apple to jest marketingowy żart. Brak podstawowych technologicznie nowych ficzerów - ma tylko część tego co inni już mają.
12:35 skoro strona odpala nowe okno i ma dostęp do wsztkich danych, to po co ten wstęp o pamięci podręcznej? Nie rozumiem powiązania wykradania danych z cache, a przeglądarki do których ma dostęp
To podpowiada jedno : w dobie coraz to nowszych sprytnych łamań zabezpieczeń a będą na bieżąco itd itd. Może warto w czasach taniej elektroniki posiadać jedno urządzenie strikte do obsługi poczty, płatności, serwisów a drugie wyłącznie do serfowania w sieci, wiem wiem poczta link = atak. Jednak z tylu głowy należy mieć te lampkę ostrzegawczą zawsze być na czujce. No ciekawy to był wykład o tych atakach , dzieki.
Ma to jak najbardziej sens kwestia wygody, chęci i konsekwencji. Podobne rzeczy da się osiągnąć softwarowo. Np dualboot, maszyny wirtualne. QubesOS jest tutaj świetnym przykładem
@@draxianhyserski1654 strasznie upraszczasz temat. Też tak można (a nawet się powinno moim zdaniem) ale można dużo więcej. Bezpieczeństwo czy prywatność nie jest wartością tak lub nie tylko bardzo złożoną skalą. To jak bardzo chcemy być pewni zależy od nas
@@Dariusz_K44 Wystarczy że nie będzie danej osoby w domu/mieszkaniu w ostateczności nie musi otwierać :D co nie zmienia faktu, że tak byłoby to irytujące :P
odpowiem pokretnie: nasz Sejm urzadzeniami z iOS stoi (chyba wszyscy poslowie maja iPady) btw. ciekawe, czy po tych informacjach beda ich nadal uzywac (i iPhonow jesli takowe posiadaja). Tu zaczynamy dotykac spraw bezpieczenstwa narodowego (zwlaszcza w tych niepewnych czasach).
To tak nie działa i to w sumie świetny przykład złego użycia szyfrowanie. Po pierwsze to spadek wydajności, dla takiej pamięci podejrzewam że sporym. Po drugie i ważniejsze zawsze szyfurjesz jakimś kluczem a rdzeń musi mieć go przysobie aby móc odczytać i szyfrować nowe dane. Gdzie go umieścić? Obok w tej samej pamięci? No to szyfrowanie wtedy nie daje żadnego bezpieczeństwa bo każdy inny rdzeń może sobie odczytać klucz. To może w pamięci dostępnej tylko dla tego rdzenia? Właśnie zrobiłeś wolniejszy L1. Szyfrowanie na to nic nie da
😂 Pierwszy problem od nie wiadomo kiedy i już nagle IOS jest równie niebezpieczny co Anroid czy Windows 🤣🤣 W końcu się musiało zdarzyć. Hakerzy z dupach nie siedzą. ;)
to nie pierwszy raz, kiedy ten ekosystem pokazuje swoje slabosci. Marketingowo sprawdza sie swietnie (zamkniety system, nikt nie ma dostepu z zewnatrz, ale nawet na zamknietym osiedlu zlodziej moze wynajac mieszkanie i w czasie swiat pladrowac mieszkania sasiadow). Na obrone powiem, ze nie ma systemu bez wad i kwestia czasu jest poznanie luk dowolnego OeSa
? Przecież Apple potrafi z dnia na dzień fixy robić, tak było chociażby z tym hackowaniem przez SMS, gdzie artykuły o tym pojawiały się po tym jak już wleciał update. Apple to akurat jedne z najszybszych korpo jeśli o to chodzi
Tak to jest jak przeglądarka daje za duże uprawnienia skryptom js. To jest jakiś absurd , jeśli przeglądarka daje takie możliwości skryptom Java, to oczywiście wszystko jest możliwe. Ogólna zasada nie wchodzimy na podejrzane strony, a szczególnie na linki w mailach czy sms-ach. Jest jakiś sposób na ograniczenie w przeglądarce uprawnień dostępu skryptom Java ? Może tylko systemy Apple pozwalają na tak dalece posunięte ich działania.
Da się mniej lub bardziej robią to przeglądarki nastawione na prywatność. Są też dodatki które mogą to ograniczyć, nawet po konkretnym API z tego co znalazłem na szybko. Problem polega na tym że masa rzeczy może być źle użyta i jednocześnie bardzo przydatna. Nawet ograniczając te oczywiste niebezpieczeństwa dużo stron może przestać działać w zależności od use casu
Dopiero po 6 minutach wyjaśnia się, ze tytuł wprowadza w błąd! Problem nie dotyczy urządzeń apple tylko procesorów apple. To duża różnica, gdy ktoś ma starszy sprzęt choćby z procesorem intela. W Polsce raczej mało kogo stać na to, żeby kupić cokolwiek nowego marki apple.
I co z tego? Grunt, że materiał stoi na wysokim poziomie i jest merytoryczny. Jak ci aż tak przeszkadza wymowa, to wycisz materiał i oglądaj z napisami XD
