Şimdi Ara

Son 9 yılın AMD işlemcileri sızıntıya sebep olabilecek açığa sahip

Bu Konudaki Kullanıcılar:
2 Misafir - 2 Masaüstü
5 sn
60
Cevap
0
Favori
2.198
Tıklama
Daha Fazla
İstatistik
  • Konu İstatistikleri Yükleniyor
0 oy
Öne Çıkar
Sayfa: 123
Sayfaya Git
Git
sonraki
Giriş
Mesaj
  •  



    Graz University of Technology içerisinde yürütülen bir çalışmanın sonucuna göre AMD’nin büyük bir spektrumdaki işlemcileri, spesifik bir yöntemle veri sızdırıyor. Bu açıktan etkilenen işlemciler arasında 2011 yılından Athlon 64 X2 işlemcilerinden Ryzen 7 ve Threadripper'a kadar birimler yer alıyor. 



    Diğer saldırı yöntemlerine kıyasla gerçek hayata uyarlaması araştırmacılar için kolay olan bu saldırı, Chrome ya da Firefox gibi tarayıcılarda çalışan bir JavaScript koduyla gerçeklenebiliyor. Saldırı yöntemi ve açığın doğası gereği çok az bilgi kaçırılabilen yöntem, daha önce ortaya çıkan Meltdown ve Spectre gibi açıklara kıyasla çok daha küçük. Bu açıklar, araştırmacıların AES şifreleme anahtarlarını almalarına yetecek seviyedeydi.



    Araştırmacılara göre bu açığın kapatılması için bir dizi yazılım ve donanım düzeltmesine ihtiyaç var. Bu düzeltmeler, Spectre ve Meltdown açıklarında olduğu gibi performansta yapılan işe göre kayıp yaşatabilir. 



    Ayrıca Bkz.İstanbul Havalimanı'nın 18 Haziran’da açılacak pisti, yürüme süresini ne kadar düşürecek?



    Araştırmacılar, açıklamalarına göre 2019 Ağustos'unda AMD'ye açıklar hakkında bilgi vermelerine rağmen hâlâ yanıt alabilmiş değil. 

     




  • AMD cevapladı, hem AMD'de hem de Intelde olan eski bir açık. Aynı açığı kullanan herkes yeni makale yayınlayacaksa işimiz yaş. Siz gidin sadece Intelde olan açıklara bakın daha geçen gün düzeltilmez açıklarımız var diyordu. Intel hemen medyaya para yağdırmış ki yalan haberler ortaya çıkıyor.
    bu mevzuyu melikulupınar hocam uzun uzun anlattı ama kimse okuyup anlamadığı için ki ben de %100 anlamadım her açık haberinde kreşe dönüyor burası.
    x86 mimarisinin tek açığı spectre ve varyasyonlarıdır çünkü amd'de de var.özellikle konan bir açık varsa budur diğer hiçbiri değil.


    peki neden böyle çünkü intel performans kazanma uğruna riskli bir yoldan gidiyormuş fakat amd olması gerektiği gibi gidiyormuş.spectre haricinde duyduğunuz açıkların hepsi ki bunları amd'de duymuyorsunuz işte bu intelin politikası yüzündenmiş.ne yolu demeyin artık o kadar teknik bilgi istiyorsanız melik hocamın mesajlarını okuyun.intel'de açık bitmez bu riskli yoldan vazgeçemedikleri için ama amd'de bundan sonra 100 tane açık haberi duyarsanız bilin ki spectre'nin varyasyonudur ve zaten yamanmıştır.amaç zaten algı yaratmak olduğu için bakın amd'de de varmış diye isteyen istediğine inansın.üniversite bağış biri demiş yukarıda.


    peki intel neden bu işten vazgeçemiyor?amd'nin kullandığı hata polisi gibi bir şey varmış 9kb miymiş neymiş o sığmıyormuş.yeni mimari de yapamıyormuş çünkü amd'den 64 biti aldı beleşe aralarındaki anlaşma ile ve şimdi o anlaşma yok.yeni mimari yapması için önce amd'nin kapısına bir tır parayla gitmesi gerekiyormuş lisans ver diye ve amd vermek zorunda değilmiş ki vereceğe de benzemiyormuş.içinde polis olmayan ama x64 olan pakedi bozamıyorlar yani.5700 serisinden beri mimari değiştirmedi adamlar yani şu söylediğimin yarısında en az haklılık payı vardır parası mı yok hala skylake gidiyor?sıfırdan yeni mimari yapma güncelle bari.x files gibi oldu ama kesin bi dolap dönüyor.



    intelciler bi 1909'da oyun oynasın bir de 1709'da.BF5 varsa özellikle.
    Mete Can Karahasan üstad konuya kısaca değinmiş.

    Herkes AMD'de ilk açık diye düşünüyor ama doğru değil. AMD'de daha önce de açık çıkmıştı. (bununla ilgili yazmıştım)

    Bu açık PSP vulnerability (Platform Security Processor zayıflığı) diye bilinen açıktır. PSP birimi ARM yapısında olup işlemci içinde ayrı bir işlemcidir ve sistem-bileşen-veri-işlem tutarlılığını denetler-sağlar. Linux benzeri özel bir kod yürütür. PSP birimi ARM mimarisi olduğundan teorik olarak tüm Meltdown-Spectre açıklarına sahiptir. Ancak kendi cachesi olmadığından Spectre grubu açıklar işlemez. Meltdown grubu teorik olarak işlese de pratikte işlemez. Zira PSP spekülatif çalıştrma yapamaz, sadece tek bir uygulamayı lineer olarak çalıştırabilir. Bu durumda tek program hedef mi saldırgan mı olacak durumu ortaya çıkar. Programın kendi kendine saldırıp kendi verisini çalması gibi absürd bir durum ortaya çıkacağından Meltdown açıkları da işe yaramaz.

    Benzer bir açık Intel işlemcilerde de vardır ve yazılımla kapatılması çok zordur. Özellikle bulut sunucularda komşu serverleri hüpletmede çok işe yarar. AMD'de ise kullanımı kısıtlıdır, buna dayanan 1 veya 2 saldırı grubu (Ryzenfall-chimera vb 13 alt teknik) bilinmektedir. ABD borsa manipülasyon ve DDOS saldırısında kullanıldığı düşünülmektedir. Pek riskli değildir zira açıkların etkin hale geçmesi için de yönetici onayı (sistemi administrator olarak açtıysanız siz) gerekmekte, Intel'dekiler gibi doğrudan çalışmamaktadır.

    Açık aslında bir hatadan kaynaklanmamaktadır. Sistem bileşenleri arasında yoğun kullanımda performansı artıran kısayollar-bağlantılar kurmayı sağlayan bir yöntemi istismar eder. Mesela ağ kartına veya harici USB cihaza erişirken her veri paketinde, yol denetimi, yönlendirmesi, paket düzenlemesi, header düzenlemesi, protokol ayarı vb vb işlerin tekrar tekrar yapılması gerekir. Bu durumda ise adanmış bir yol oluşturulup, ayarlar bir kere yapılarak, veri paketlerinin daha hızlı iletilmesi söz konusudur. İstismar buna dayanır, kurala uygun ayarlar yapılıp, kısa yol açılır ama kurala uymayan-modifiyeli-zararlı paketler gönderilir.

    Bu açık tamamen kapatılmıştır. Windows artık buna yönetici onayını istemeyi ve almayı engellemektedir. Yeni modellerde yoktur, eski sistemlerde BIOS üzerinden kapatılmıştır, BIOS güncellediyseniz açık yoktur. Aslında bir AÇIK değil yan kanal saldırısı söz konusudur, yoksa sistem istismar edilmediğinde doğru çalışmaktadır. Mesela ekmek bıçağı ile ekmek kesersek normal kullanmış oluruz, ama adam kesersek amacının dışında (yan kanal saldırısı) kullanmış oluruz.

    AMD işlemlerde hiçbir Meltdown grubu (işlemcideki koruma mekanizmalarını atlatan açıklar) açığın olmamasını Intel'in aksine perf pahasına sıkı spekülatif çalıştırma denetimi (uOPS işaretlemesi dahil) oluğunu daha önceleri yazmıştım. Spectre grubunun da (yetkimiz olmayan veriye erişmeyi sağlayan açıklar) yapılan mutlak hedef-kaynak yetki-uygunluk kontrolü nedeniyle işlemediğini yazmıştım. Intel burada da nadir kontrol yapar.

    Aslında cache nedeniyle (Intel de AMD'nin yana bakan cache mimarisini kullanır) teorik olarak Spectre grubu açıkların AMD işlemcilerde de çalışması beklenir. Hatta ilk başlarda açık var diye bile gösteriliyordu. Ancak yukarıda bahsettiğimiz mutlak hedef-kaynak kontrolü nedeni ile Spectre grubu açıklar işe yaramaz. AMD verileri Intel gibi denetlemeden küt diye cacheye atmaz. (Bu denetimi de PSP yapar) Bu yüzden cacheden veri sızdırmak çok zordur, genelde çalmak istediğiniz değil zaten size ait olan veri gelir elinize ve bir işe yaramaz. Size ait olmayan veri ise rastlantısaldır (denetimi geçemediğinden eşleme yapılmamıştır) ve neye ait veya ne olduğu tamamen belirsizdir. Doğru veriyi bulmak anlamsız derecede zor ve uzun süreli olur.

    Bu yeni teorik açık da buna dayanıyor. Anlamak için zaman duyarlı yan kanal saldırısı ve cachenin işleme mantığını biraz bilmek gerekiyor.

    Öncelikle L1 cacheler segment+offset duyarlıdır. L1 Code/Inst cachede çekirdekte çalışan kodun (CS segmenti) verileri cachelenir, L1 Data cachede ise kullanılan bilgiler (DS segmenti) cachelenir. L1 cacheler çekirdek içinde (L2 bitişiğinde, L3 dışında) bulunduğundan başka bir çekirdekte çalışan kod tarafından erişilmesi mümkün değildir. Yani Spectre ile L1'den veri çalınamaz. (Intelde de çalınamaz, gelende L3 üzerinden çalınır her çekirdek erişebildiğinden)

    Bunu aşmak için aynı çekirdekte (L1 cachenin ait olduğu) çalışan iki kodun da aynı segment adresine sahip olması gerekir. 32 bitte win buna izin vermez. 64 bitte ise zaten tüm segmentler 0 adresinden başlar. Ancak segment register tanımlama kayıtları farklıdır, burada bunu da eşlemek gerekecektir. Yani iki kod da aynı segment tanım koduna sahip olmalıdır.

    Bu da yetmez, doğru alanı eşlemek için segmentlerin lineer adresleri de yanı olmalıdır. Win önce segmentleri sanal adresler ile oluşturur, sonra sayfaları ayarlayarak lineer adres oluşturur. TLB birimleri ise bunu fiziksel adrese çevirerek belleğe erişimi sağlar. Sanal adres demek segmentin boyuna göre 4 KB boyunda sayfa dizisi oluşturmak demektir. (Segment tanım kaydında kaydında başlangıç sayfası, ve Index-page tablo dizisi) Daha sonra bu sanal sayfa dizisini gerçek fiziksel bellek sayfaları ile eşler.

    Örneğin 8 KB boya sahip A-B programları sanal olarak 0 ve 1 sayfalarına (her biri 4 KB) sahiptir. Lineer adreste ise gerçek fiziksel sayfa nuaraları A=100,200 ve B=300,400 numaralı sayfalar olabilir. A programı kendi sanal 0 sayfasına eriştiğinde çekirdekteki adres üretici (AGU) bunu 100 nolu sayfa olarak TLB birimine iletir ve TLB de kendi denetimini (sayfa sanal bellekte olabilir vb) yaparak fiziksel belleğe erişir. Burada sorun B programının sanal 0 sayfasından veri çalacak olan A programının sanal 0 sayfasının farklı gerçek fiziksel adrese sahip olmasıdır.

    En kolay çözümü iki 0 sanal sayfanın da aynı fiziksel sayfayı göstermesini sağlamaktır. Ancak win buna engel olur. AMD işlemcilerde ise PAT diye bilinen (Page Atrributes Table) özellik buna zaten izin vermez. Intel olanlarda Meltdows grubu bir saldırı yaparak TLB girdisini veya segment tanımlama bilgisini (başlangıç sayfası-entry page) değiştirerek bunu aşabiliriz. Ancak bir segementin entry page veya TLB bilgisini değiştirebildi isem zaten segemntteki tüm veriye erişirim. Daha ne uğraşayım, direkt dalarım. Dolayısı ile bu yöntemi denemek de anlamsız olur.

    Geriye tek teorik zayıflık kalıyor. Bunun için öncelikle fiziksel sayfalar eşleşmese de sanal sayfaların eşleşmesi ve offset adreesinin bilinmesi lazımdır. Yani ulaşmak istediğimiz veri segmentin hangi sayfasında ve satırında. Ardından task switch işlemi sırasında yapılan Cache Flush/Refresh işlemine müdahale edebilmeli ve uygun ayarları tutturmuş olmamız lazım.

    L1C/L1D cachedeki her verinin bir kopyası L2 cachede, L2 cachedeki her verinin bir kopyası da L3 cachede bulunur. L1 cacheler hem segment bağımlı hem offset bağımlı, hem de satır yapısındadır. L1C/L1D cachedeki veriler kod (CD) ve data (DS) segmentlerinin offset adreslerine göre tutulur. 64 bit sistemde 64 KB L1 cache demek her biri 8 byte (64 bit) tutan 8192 veri demektir. L1 cahede veriler hizalıdır (aligned) ve ardışıktır. Veri 1 Byte veri bile olsa L1 cachede yine 8 byte kaplar. Bu yüzden L1 cacheler adete register gibi hızlı işler.

    L2 cache de segment duyarlıdır ama birden çok segmenti (kod-data vb) içeren veri tutabilir. Bu nedenle L1 gibi hizalı değildir, veriler 4 satırlık paketler halinde tutulur. Offset adresinden etkilenmediğinden verilerin sıralı bulunma olasılığı da çok düşüktür. 4 satırlık paketler en az kullanılan kümelere göre dinamik olarak dağıldığından yerinin tespiti de zordur. Üstelik uygulama birden çok kod-data segmenti de kullanabilir ve işi daha da zorlaştırır.

    L3 cache ise uygulama-çekirdek-segment vb işlerinden bağımsızdır. L3 cachenin adreslenmesi fiziksel belleğe göredir ve Burst Mode bellek erişim metoduna (her seferde 4 satır erişim) göre ayarlanmıştır. Veriler hizalı değildir ve 4 satırlık paketler halinde en az kullanılan kümelere dinamik olarak yerleşirler. Bir veri paketinin hangi kümeye yerleşeceğini etkileyen çok sayıda faktör vardır.

    Görüldüğü gibi her seviye cachenin çalışması farklıdır ve yüksek oranda (L1 hariç) rastlantısallık içerir. L1-L2 olanlara çekirdek dışından erişilemediğinden veri sızdırmada genelde L3 bellek hedeflenir. Burada problem ise segment-sayfa-offset eşlemenin çok zor olmasıdır, zira L3 fiziksel belleği aynalar.

    Mesela benim FX-8320 işlemci 8 MB L3 içerir, 64 yollu küme birleşimlidir (64 way set associative) ve her küme uzunluğu 64 bytedir (64 bit işlemci için her satır 8 byte, 4*8=32 byte burst paketi, iki kanal bellek için 64 byte). 8320 içinde 8 çekirdekte 32 adet 64 bit tamsayı birimi, modüllerde 8 FMAC içinde gruplanmış 64 adet 64 bit kayar nokta ve 16 MMX birimi, 4 decode, 4 fetch, 8 load, 8 store birimi vardır (toplam 132). Bunların hepsi cachelere-belleğe erişmeye ihtiyaç duyarlar ve aynı anda kaçının eriştiği önceden bilinemez.

    L3 cache yarı dinamiktir, boş yer olduğu sürece bilgiler tutulmaya devam eder ve belleğe geri yazılmaz. Ancak Writeback metodu ayarlandıysa belleğe de geri yazılır. Boş yer kalmadığında en az kullanılan kümeler (her biri 64 byte) belleğe geri yazılır ve yeni veriler yüklenir. Invalidate/clflush vb gibi komutlarla değişmiş tüm veriler geri yazdırılabilir veya buna ilaveten cache boşaltılabilir.

    L2 cache ise çekirdekte çalışan uygulama değiştiğinde dinamik olarak yenilenir. İçindeki değişmiş öbekler L3 cacheye yazılır ve boşaltılır. Yeni uygulamanın verileri komple yüklenmez, uygulama çalıştıkça yüklenirler. Yer kalmazsa en az kullanılan öbekler L3 cacheye yazılır ve yeni veriler buraya yüklenir. L1 cache de dinamiktir. Çekirdekte çalışan uygulama değişince L2 gibi yenilenir. Ancak L1 için çalışan uygulama değişmese de kod/data segmentleri değişti ise L1C/L1D cacheler yenilenir. Yenileme işleminde değişen veriler hep bir geriye (L1->L2, L2->L3, L3->Mem) olacak şekilde yazılır.

    Bu açık çekirdekte çalışan uygulama değiştiğinde (task switch) boşaltılan (invalidate) L1-L2 cachelerin L3 cacheden tekrar doldurulması (refresh) işlemini istismar etmeye çalışmaktadır. Cachenin boşaltılmasına müdahale edilemez, zira tek komutla ve tamamen işlemci tarafından yerine getirilir. Araya kod girmek mümkün olmadığından istismar da mümkün değildir. Ancak task switch sonrası cacheler komple değil, kullanıldıkça tazelendiğinden cacheler arası hız-gecikme farkını istismar etmek mümkün olabilir. Ancak bu sanıldığından çok daha karmaşıktır.

    Buna geçmeden önce zaman duyarlı yan kanal saldırısına biraz değinelim. Kolay anlaşılsın diye ilkinde C/C++ vb dillerin yamanmamış halinde bulunan bir özelliği istismar edeceğiz ve bir parola kırmaya çalışacağız. (şu anda bunu yamanmamış halini bulmak zordur, uğraşmaya değmez) Parolamız 'BDFH' olsun. Biz kaba kuvvet benzeri (tam kaba kuvvet değil, tüm olasılıkları denemiyoruz) bir yöntem uyguluyoruz. Parola olarak 'AA' gönderiyoruz. İlk harfler uymadığından hemen red dönüyor. Sonra parola 'BA' gönderiyoruz. İlk harfler uyuyor ama ikincide red dönüyor. Ancak bu 1 yerine 2 harf kontrol edildiğinden red cevabı daha uzun sürüyor.

    Birkaç deneme ile sonuca ulaşamayız ama yeteri kadar deneme yaptığımızda B ile diğer harfler arasında red cevabında ölçülebilir bir zaman farkı olacak ve B ile başlayan grubun süresi az ölçülecektir. Böylece parolanın ilk harfinin B olduğunu tahmin edebilir ve sonraki harfleri de benzer yöntemle tahmin bulabiliriz. Bu açık keşfedilip yamanıncaya kadar çok etkili şekilde kullanılmıştır. (internette fink atan site hesapları filan) Belli sürede belli deneme sınırı veya captcha vb tekniklerin çoğu bunu engellemeye yöneliktir temelinde. Kısa sürede sayısız ihtimali denemeyi önlerler.

    Spectre grubu açıkların çoğu ve bahsedilen bu açık da mantıksal açıdan buna benzer bir yaklaşım kullanıyor. Tabii ki daha karmaşık ve işlemcilerin bellek-cache kullanım mekanizmasını istismar ediyor. Zaman duyarlı yan kanal saldırısı yönemiyle cacheden veri sızdıralım (spectre grubu). Bunun için sızıntı yapacağımız bellek alanı ile kendi bellek alanımızın sanal-lineer adreslerini eşlememiz lazım. (Lüzumsuz kişiler kurcalamasın diye bunu pas geçiyorum. Zaten açığı kullanacak kadar programlama bilen bunu da bilir) Bellek ayarlarını yaptığımızı kabul edelim.

    Öncelikler sızdıracağımız bellek adreslerine rastgele erişemeyiz. İki veri arasında en az 4096 byte (4 KB sayfa boyu) mesafe olmalıdır, yani aynı sayfadaki verilere erişirsek olmaz. Mesela önce 0,4096,8192 vb sonra 1,4097,8193 vb adreslere erişmemiz lazım. Aksi takdirde burst mode bellek erişimi, page interleave ve ileri okuma tahmin mekanizması istediğimizden daha fazla veriyi cacheye atar ve ayrım yapamayız. Açığı ise her seferinde tek satır okuyarak istismar edebiliriz. Bu yüzden erişimi uygun adımla yapmak lazım.

    Sonra da cacheleri boşaltmalıyız ki eskiden kalan verilerle çakışma olmasın, sadece sızdırmaya çalıştığımız veri cachede bulunsun. L1-L2 cachelere çekirdek dışından erişilemediğinden L3 cacheyi kullanmamız lazım. Eşlediğimiz bellek erişimini yaparken cachelemeyi engelleyecek şekilde erişmemiz lazım. Bu durumda veri L1-L2 içine atılmaz. Ancak L3 çekirdek değil bellek eşgüdümlü çalıştığından tamamen kapatmadıkça veri L3 belleğe alınır. Böylece yine diğerleri ile karışmasını önleriz.

    Ardından sızdırmak istediğimiz bize ait olmayan bellek alanına bir erişim deneriz. İşlemci koruma hatası (exception) üretir ve veriyi bizim verdiğimiz hedefe (bellek-register) atmaz. Windows da exceptionu yakalar ve hata işleme işini devreye sokar, bizi uyarır. Bizim bu hatayı bastırmamız (error handling de bilmemiz) lazım. Ama Intel işlemcilerde veri L3 cacheye atılmış olur ve geri alınamaz. Pardon deyip hatayı bastırırız ve aynı adrese bu sefer kendi bellek alanımızdan (segmentimizden) erişiriz. Doğal olarak burada sorun olmaz.

    Eğer eriştiğimiz veri cachede ise (sızdırmaya çalıştığımız) hızlı okunacak, değilse (kendi bellek alanımız) daha yavaş okunacaktır. Sızdırılan verinin hangi cache kümesine atıldığını bilemeyiz. Bu yüzden tek erişim ile tespit etme imkanı yoktur, çünkü zaman farkı ölçülmayecek kadar küçüktür. Çok sayıda deneme yaparak zaman farkını ölçülebilir kadar artırırız ve kısa sürede gelen satır (veri) sızdırdığımız veri olur. AMD ise Intel gibi veriyi küt diye cacheye atmadığından genelde istene veriye ulaşamayız ve rastlantısallık nedeni ile zaman farkını tespit etmek imkansıza yakındır.

    Bu açık da cacheler arasındaki zaman (gecikme) farkını istismar ediyor. Task witch ile cacheler boşalıyor, yeni task yüklendiğinde L1-L2 cacheler tekrar L3 cacheden doldurulmaya başlıyor. L3 cachenin gecikme süresi L2-L1 ve işlemciye göre oldukça uzun. Bu açık bu araya başka bir okuma sıkıştırarak çakışma yaratmaya ve verinin bir kopyasını oluşturmaya çalışıyor. Ancak bu çok zor ve doğru zamanı yakalamak lazım, buna engel olacak da bir sürü husus var.

    AMD işlemcilerde Spectre grubu açıkların çalışmamasının veriyi intel gibi küt diye cacheye atmaması, önce denetimden geçirmesi olduğunu söylemiştik. Aynı Mhz hızda olsa da AMD CPU cache gecikmesi bu yüzden Intel CPU cache gecikmesinden daha fazladır, yani AMD cache az biraz daha yavaş çalışır daha sıkı denetim ve bunun gecikmesi yüzünden. Şimdi bazıları Ryzen cache gecikmesi niye azaltılmıyor, intel seviyesine neden gelmiyor diye tırı vırı yapıyor. Gecikmenin intel seviyesine inmesi için denetimin zayıflatılması lazım ki bu da Spectre açıklarının AMD işleemcide de işe yaraması anlamına gelir. (bırakın böyle kalsın)

    Bu açık da aslında bu extra denetimin oluşturduğu gecikmeden faydalanıyor. Araya ilave komut sıkıştırmaya çalışıyor. Extra denetimi kaldırsak bu açık kapanır ama Spectre açılır dediğim gibi. Ancak bu açığın kullanımı zor.

    Öncelikle denetimin yapılması, verinin geçerliliğinin onaylanması lazım. Bu tamamlanmadan erişirseniz elinize boş veri geçer. Bunu süresi de sabit değil. Cache doluluğu, tag yükü, işlemci yükü, bus kullanan EU sayısının yoğunluğu, cache crossbar çakışması gibi bir sürü faktör bunu süresini değiştiriyor. Yani sadece verinin geçerli olduğu anı yakalamak için sayısız deneme yapmak lazım.

    Bu da yetmiyor. Benim 8320 işlemcide 64 yollu L3 cache ve bus kullanabilecek 132 ünite olduğunu söylemiştim. Bu üniteler işlem yüküne göre cacheye-belleğe sık sık ve değişken/rastlantısal oran ve yoğunlukta erişmeye çalışır. Bizim sızdırma erişimimizi bunlar arasında mümkün olduğunca erken, mümkünse ilk olarak yapmamız lazım. Yoksa boşalttığımız cache bunların eriştiği veriler de dolacak ve hangisinin bizim olduğunu anlamamız çok zor olacaktır. Cacheye atılan veri arttıkça doğru veriyi bulma ihtimalimiz üstel olarak azalacak, yani zorluk üstel (permütasyon) şekilde inanılmaz artacaktır.

    Üstelik burada önceliği ele geçirmek için bir yol da yoktur. Yine sayısız deneme yanılma yapmak ve şansızmıza güvenmek lazım. İşlemcide çalışan uygulama-thread (işleç) sayısıs ne kadar azsa bunu başarma ihtimalimiz de o kadar yüksektir. Kendi makinamızda bunu yapabiliriz ama dışardan eriştiğimiz başka bilgisayardaki uygulama-thread sayısına yapacak pek bir şey yok. Bunu yapmak için Meltdown-virüs vb ile önce sızmak gerekir ki, bunu yaptıysam daha ne uğraşacam, zaten hedefi ele geçirmişim demektir.

    Ardından da bir ton veri arasında tamamen rastlantısal görüne zaman farklarını kullanarak (spectre gibi ölçemiyoruz) zibilyon ihtimal arasında tek doğru ihtimali bulmamız lazım. Hesaplamadım ama büyük ikramiye çıkma olasılığı eminim kat kat daha fazladır.

    Sonuç olarak:
    Güvenlik tedbirleri insanlar tarafından geliştirilir. Başka biri de bunu aşacak bir saldırı geliştirebilir. Hatta tüm olasılıkları deneyen bir kaba kuvvet (brute force) saldırısı, hatta bunu ihtimal sayısını azaltan analizler kullanılarak aşılamayacak güvenlik yoktur. Aslında cacheye yönelik (bu açık-specreler vb) temelde çok sayıda denemeye dayanan bir nevi kaba kuvvet saldırısıdır zaten.

    Burada önemli husus güvenliği aşmak için harcadığınız zaman ve maliyetin makul seviyede kalmasıdır. Yoksa anlamsız derecede çok deneme yaparak AMD cachelerinden bile bilgi sızdırabilirsiz. Ama kazanç-kayıp oranı arasında kabul edilemez derecede korkunç fark olacaktır.

    Mesela akşam kod uygulaması (yol araması, huzur operasyonu vb) yapacak Jandarma için emir öğlen yayınlandıysa akşama kadar kırılmaması yeterlidir. 15 gün sonra düşmanın sol kanadına hucüm edecek ordu emri için saldırı başlayıncaya kadar kırılmaması yeterlidir. 10 yıl saklanacak gizli meclis tutanakları da en az bu sürede kırılmamalıdır. Bunu sağlayan her güvenlik yeterlidir, fazlası gereksizdir. 1 günlük uygulama emrini 1000 yıl korumaya çalışmak abestir.

    Bahsettiğimiz açıkta da buna benzer bir durum var. Açığı istismar edebilmek için harcadığınız kaynak elde edeceğiniz kazanca değmiyor. Hoca nasreddin 10 lira alıp 9 liraya satıyordu, bu durum 1000 liraya alıp 1 liraya satmak gibi anlamsız ve abes. Bu maliyete katlanabilmek için elde edilecek şeyin çok ama çok değerli olması lazım. Bu da istirmar ihtimalinin neredeyse yok derecesine düşürür. Belki içerden adam satın almak, veya komple bilgisayarı çalacak soygun düzenlemek filan çok daha ucuz ve kolay olabilir.
  • Ya kaç gün önce Intel’de çıkan bir açık üzerine fena şekilde İntel’e laf edildi. Demek ki her iki tarafta da olabiliyormuş ve körü körüne de fanatik olmamak gerekiyormuş.



    < Bu mesaj bu kişi tarafından değiştirildi Morichannnn -- 9 Mart 2020; 0:13:35 >
    < Bu ileti DH mobil uygulamasından atıldı >
  • https://www.donanimhaber.com/arastirmacilar-intel-cpu-ve-yonga-setlerinde-duzeltilemez-bir-guvenlik-acigi-oldugunu-kesfetti--119446

    O zaman intel kepenk kapatsın bir açık aranmak istenirse mutlaka bulunur. Her yazılım veya donanımın açığı mutlaka vardır.
  • AMD de patladı...

  • İntel açığının başlığında dalga geçen arkadaşlar çok emin bi şekilde dalga geçiyordu amd de olamazmış gibi böyle şeyler. Kimbilir iki işlemcide de daha ortaya çıkmamış ne açıklar vardır. %100 açıksız hiç biri garanti edemez.

    < Bu ileti DH mobil uygulamasından atıldı >
  • Sızdırmayan işlemci yapamadılar bir laa cinnah.

    < Bu ileti DH mobil uygulamasından atıldı >
  • intel en azından hemen refleks gösteriyor. Amd bırak güvenlik yamasını adamlara cevap vermeye bile tenezzül etmemiş.

    < Bu ileti mobil sürüm kullanılarak atıldı >
  • S.T.A.L.K.E.R. kullanıcısına yanıt
    bu konuda cok tartışma dönüyor amd aslında belli başli aciklamar yapip bu aslında bizi etkilemiyor gibisinden bir şeyler demiş
    https://www.reddit.com/r/Amd/comments/ff2g8h/amd_responds_to_white_paper_that_claims_potential/

    "We are aware of a new white paper that claims potential security exploits in AMD CPUs, whereby a malicious actor could manipulate a cache-related feature to potentially transmit user data in an unintended way. The researchers then pair this data path with known and mitigated software or speculative execution side channel vulnerabilities. AMD believes these are not new speculation-based attacks.

    AMD continues to recommend the following best practices to help mitigate against side-channel issues:

    Keeping your operating system up-to-date by operating at the latest version revisions of platform software and firmware, which include existing mitigations for speculation-based vulnerabilities
    Following secure coding methodologies
    Implementing the latest patched versions of critical libraries, including those susceptible to side channel attacks
    Utilizing safe computer practices and running antivirus software
    "

    tabii konuya daha yetkin daha yakından birilerinin de görüşü lazım. AMD'ye göre ciddiye alınması ve patchlenmesi gereken bi sorun değilmiş çünkü bi önceki açıkların bir uzantısıymış. o açık patchliyse bu açık iş yapmaz demişler

    ama öbür yandan bilmem ne izolasyonu yaparak bu açıgın yine de kullanılabildiğini söyleyenler de var

    ben de neye inanacağıma emin olmadım biraz daha yetkin ve daha tarafsız bazı kişilerin ve sitelerin masaya yumrugu koyması lazım eğer bu gerçekten bi sorunsa ve amd bu şekilde üstünü örtbas etmeye çaliştiysa SIKINTI
  • Saldırı yöntemi ve açığın doğası gereği çok az bilgi kaçırılabilen yöntem, daha önce ortaya çıkan Meltdown ve Spectre gibi açıklara kıyasla çok daha küçük. Bu açıklar, araştırmacıların AES şifreleme anahtarlarını almalarına yetecek seviyedeydi.

    Heralde Intel üniversiteye bir miktar bağış yapmış Amd dede bir şeyler bulun diye ama Amd pek kaale almamış adamları
  • Kimse yogurdum eksi demez ;)

  • Intel fazla ileri gidince birer birer açıklar çıkmaya başlamıştı.

    Şimdi AMD fazla ileri gittiği için yeni hedef tahtası oldu.

  • quote:

    Heralde Intel üniversiteye bir miktar bağış yapmış Amd dede bir şeyler bulun diye ama Amd pek kaale almamış adamları.


    bütün sırrı bozdun ya..
  • Intel temsili

    Son 9 yılın AMD işlemcileri sızıntıya sebep olabilecek açığa sahip
  • ayni açık intelde de var nedense bi donanim haberde amd denmiş amaç ne editör sağlam kaynak bul yancı sitelere gitme



    < Bu mesaj bu kişi tarafından değiştirildi wolferto -- 8 Mart 2020; 23:27:35 >
  • bu mevzuyu melikulupınar hocam uzun uzun anlattı ama kimse okuyup anlamadığı için ki ben de %100 anlamadım her açık haberinde kreşe dönüyor burası.
    x86 mimarisinin tek açığı spectre ve varyasyonlarıdır çünkü amd'de de var.özellikle konan bir açık varsa budur diğer hiçbiri değil.


    peki neden böyle çünkü intel performans kazanma uğruna riskli bir yoldan gidiyormuş fakat amd olması gerektiği gibi gidiyormuş.spectre haricinde duyduğunuz açıkların hepsi ki bunları amd'de duymuyorsunuz işte bu intelin politikası yüzündenmiş.ne yolu demeyin artık o kadar teknik bilgi istiyorsanız melik hocamın mesajlarını okuyun.intel'de açık bitmez bu riskli yoldan vazgeçemedikleri için ama amd'de bundan sonra 100 tane açık haberi duyarsanız bilin ki spectre'nin varyasyonudur ve zaten yamanmıştır.amaç zaten algı yaratmak olduğu için bakın amd'de de varmış diye isteyen istediğine inansın.üniversite bağış biri demiş yukarıda.


    peki intel neden bu işten vazgeçemiyor?amd'nin kullandığı hata polisi gibi bir şey varmış 9kb miymiş neymiş o sığmıyormuş.yeni mimari de yapamıyormuş çünkü amd'den 64 biti aldı beleşe aralarındaki anlaşma ile ve şimdi o anlaşma yok.yeni mimari yapması için önce amd'nin kapısına bir tır parayla gitmesi gerekiyormuş lisans ver diye ve amd vermek zorunda değilmiş ki vereceğe de benzemiyormuş.içinde polis olmayan ama x64 olan pakedi bozamıyorlar yani.5700 serisinden beri mimari değiştirmedi adamlar yani şu söylediğimin yarısında en az haklılık payı vardır parası mı yok hala skylake gidiyor?sıfırdan yeni mimari yapma güncelle bari.x files gibi oldu ama kesin bi dolap dönüyor.



    intelciler bi 1909'da oyun oynasın bir de 1709'da.BF5 varsa özellikle.
  • Ülkemize uğramayan corona virüsü işine döndüydü bu açık meselesi. İlk başta amd de eçık yok diye sevinirken sonradan ulan benim işlemcimin neyi eksik niye açık bulunamıyor diye hayıflanmaya başlamıştım iyi oldu bu haber
  • Açıklama yaptığı yerin linkini atar mısın?

    < Bu ileti DH mobil uygulamasından atıldı >
  • AMD cevapladı, hem AMD'de hem de Intelde olan eski bir açık. Aynı açığı kullanan herkes yeni makale yayınlayacaksa işimiz yaş. Siz gidin sadece Intelde olan açıklara bakın daha geçen gün düzeltilmez açıklarımız var diyordu. Intel hemen medyaya para yağdırmış ki yalan haberler ortaya çıkıyor.

  • 
Sayfa: 123
Sayfaya Git
Git
sonraki
- x
Bildirim
mesajınız kopyalandı (ctrl+v) yapıştırmak istediğiniz yere yapıştırabilirsiniz.