Specjaliści ds. cyberbezpieczeństwa wykryli nową, bardzo poważną lukę w zabezpieczeniach procesorów Intela ze wsparciem dla enklaw SGX (Software Guard eXtensions). Dzięki niej możliwe jest wyciąganie określonych danych z pamięci wykorzystywanej przez oprogramowanie ofiary, za pośrednictwem buforów procesora. Luka otrzymała nazwę CrossTalk, a jej wykorzystanie polega na wykonaniu kodu kontrolowanego przez osobę atakującą na jednym rdzeniu procesora, w celu wycieku wrażliwych danych z oprogramowania ofiary wykonującego się na innym rdzeniu.
Luka jest zatem bardziej niebezpieczna niż wcześniejsze, które umożliwiały wyciąganie danych pomiędzy dwoma wątkami wykonującymi się na jednym rdzeniu.
Niestety, przed luką CrossTalk nie chronią mitygacje wprowadzone do tej pory i niezbędna będzie nowa porcja poprawek, a także wprowadzenie zmian w kompilatorach. Nowa podatność została oznaczona przez Intela jako CVE-2020-0543, a zagrożenie przez nią powodowane jest oceniane na 6,5 punktu w 10 punktowej skali CVSS. Za jej odkrycie odpowiadają Alyssa Milburn, Hany Ragab, Kaveh Razavi, Herbert Bos, Cristiano Giuffrida z Uniwersytetu w Amsterdamie.
K O M E N T A R Z E
Do tej pory się zastanawiam dlaczego Intel (autor: Mario1978 | data: 10/06/20 | godz.: 20:53) dąży do samounicestwienia na rynku CPU z architekturą x86.
To sie juz robi nudne... (autor: gantrithor | data: 10/06/20 | godz.: 21:02) j.w
Napewno ucierpia na tym firmy udostepniajace maszyny wirtualne i ich klienci :S
Wyłącz SGX w bios setup i po problemie (autor: zbiggy | data: 10/06/20 | godz.: 21:58) Czasem w bios setup jest podana pełna nazwa: Software Guard Extensions - wystarczy zrobić Disable i już jej nie ma.
na strone Intela, SGX opisany jest sloganem: (autor: Qjanusz | data: 10/06/20 | godz.: 23:26) "Przejmij kontrolę nad ochroną danych"
Bardzo niefortunny dobór słów w kontekście tego newsa.
@zbiggy - oczywiście... wyłącz SGX, HT, zaimplementuj wszystkie łatki bezpieczeństwa odejmując 10% mocy CPU, a i tak okaże się że z bezpieczeństwem niewiele on ma wspólnego.
@2. (autor: pwil2 | data: 11/06/20 | godz.: 00:49) I tak i nie. Wydajność maszyn spadnie, więc klienci będą kupować więcej zasobów ;-)
c.d. (autor: pwil2 | data: 11/06/20 | godz.: 00:52) ""In other words, from what I can tell, this takes the crazy 'Intel ships buggy CPU's and it causes problems for virtualization' code (which I didn't much care about), and turns it into 'anybody can opt in to this disease, and now it affects even people and CPU's that don't need it and configurations where it's completely pointless'."
c.d. (autor: pwil2 | data: 11/06/20 | godz.: 00:53) ""I don't want some application to go 'Oh, I'm _soo_ special and pretty and such a delicate flower, that I want to flush the L1D on every task switch, regardless of what CPU I am on, and regardless of whether there are errata or not. Because that app isn't just slowing down itself, it's slowing down others too."
Torvalds' reference to virtualization was directed at AWS which, like other cloud providers, sells virtual CPUs often with simultaneous multithreading (SMT) enabled.
He goes on to point out that with SMT enabled, it "should disable this kind of crazy pseudo-security entirely, since it is completely pointless in that situation".
"At a _minimum_, SMT being enabled should disable this kind of crazy pseudo-security entirely, since it is completely pointless in that situation. Scheduling simply isn't a synchronization point with SMT on, so saying "sure, I'll flush the L1 at context switch" is beyond stupid," he said.
In a discussion with Singh, Torvalds notes that to "'flush L1D$ on SMT' is crazy, since an attacker would just sit on a sibling core and attack the L1 contents *before* the task switch happens"."
c.d. (autor: pwil2 | data: 11/06/20 | godz.: 00:55) Taki patch byłby na rękę Intelowi, bo spowalniałby również procesory konkurencji, czemu przeciwstawia się Linus Torvalds.
pwil2 (autor: kombajn4 | data: 11/06/20 | godz.: 10:48) Czemu? Jak to ma być łata na poziomie kompilatora to wystarczy sprawdzić flagę rodzaju procesora.
A odnośnie samej luki (autor: kombajn4 | data: 11/06/20 | godz.: 11:26) cóż można powiedzieć.. Kolejna dziura w Intelu? Szok i niedowierzanie...
po prostu czas na nowa architektore bo to sa bledy bedace w prockach od (autor: pawel1207 | data: 11/06/20 | godz.: 17:52) ponad 8 lat :D :D
@10 (autor: Kenjiro | data: 11/06/20 | godz.: 19:02) Intel już rok czy dwa temu wysłał komiczną łatę na kernel, która blokowała pewnie zachowania dla wszystkich procesorów, niezależnie czy są podatne, czy nie. Oczywiście łata została wyśmiana i odrzucona.
Ciekawostka (autor: PCCPU | data: 11/06/20 | godz.: 22:53) Jim Keller podobno z powodów osobistych w trybie natychmiastowym odchodzi z Intela. Jeszcze przez 6 miesięcy będzie pełnił rolę konsultanta.
D O D A J K O M E N T A R Z
Aby dodawać komentarze, należy się wpierw zarejestrować, ewentualnie jeśli posiadasz już swoje konto, należy się zalogować.
