Stagefright: Android'i Değiştiren İstismar

Android'in en güçlü noktalarından biri, öncelikle paydaşların işletim sistemini kendi özel ihtiyaçlarına uygun şekilde çatallamasına, değiştirmesine ve yeniden dağıtmasına olanak tanıyan açık kaynak yapısı olmuştur. Ancak açık kaynak olmanın bu avantajı, kötü amaçlı yazılım ve güvenlik sorunları söz konusu olduğunda iki ucu keskin bir kılıç gibi davranır. Kaynak kodu ücretsiz olarak mevcut olan bir projeye çok sayıda yetenekli katkıda bulunanınız olduğunda kusurları bulmak ve yamamak daha kolaydır. Ancak sorunun kaynak düzeyinde düzeltilmesi çoğu zaman sorunun nihai tüketicinin elinde çözülmesi anlamına gelmez. Bu nedenle, veriye duyarlı kurumsal ihtiyaçlar için bir işletim sistemi seçimi söz konusu olduğunda Android ilk tercih değildir.

Google I/O 2014'te Google, daha güvenli ve kurumsal dostu bir ekosisteme yönelik ilk adımını,

Android For Work programı. Android For Work, kurumsal ihtiyaçlar için BT yöneticilerinin bir çift profil yaklaşımı benimsedi. çalışanlar için farklı kullanıcı profilleri - biri işe odaklanmış, diğer profiller çalışanların kişisel kullanımına bırakılmıştır kullanmak. Donanım tabanlı şifreleme ve yönetici tarafından yönetilen politikaların kullanımı sayesinde iş verileri ve kişisel veriler ayrı ve güvende kaldı. Daha sonra, Android For Work sonraki aylarda daha fazla ilgi görmeye başladı ve cihazın kötü amaçlı yazılımlara karşı güvenliğine büyük önem verildi. Google ayrıca şunu da planladı: tüm cihazlar için tam cihaz şifrelemesini etkinleştir kutudan Android Lollipop ile birlikte piyasaya sürülecekti, ancak bu hamlenin OEM'lerin uygulaması için isteğe bağlı hale getirilmesiyle birlikte performans sorunları nedeniyle hurdaya çıkarıldı.

Güvenli bir Android için çaba tamamen Google'ın işi değil; Samsung, bu konuda oldukça önemli bir rol oynadı. KNOX'un AOSP'ye katkıları, sonuçta güçlendirilmiş Android For Work. Ancak Android'deki son zamanlardaki güvenlik açıkları ve güvenlik açıkları, kurumsal benimsemenin popülerliği söz konusu olduğunda zorlu bir göreve işaret ediyor. Bunun en iyi örneği, son zamanlarda ortaya çıkan Stagefright güvenlik açığıdır.

İçindekiler:

• Sahne Korkusu nedir?
• Stagefright ne kadar ciddi?
• Stagefright'ı diğer "büyük güvenlik açıklarından" farklı kılan nedir?
• Güncelleme İkilemi
• Android, Sahne Sonrası Korku
• Kapanış Notları

Sahne Korkusu nedir?

Basit bir ifadeyle Stagefright, Android'de medya oynatmak için kod kitaplığını kullanan bir istismardır. libstagefright. Libstagefright motoru, MMS yoluyla kötü amaçlı bir video biçiminde alınan kodu yürütmek için kullanılır ve böylece başarılı bir saldırı gerçekleştirmek için yalnızca kurbanın cep telefonu numarasına ihtiyaç duyulur.

Şirket içi uzmanımız XDA Kıdemli Tanınmış Geliştirici ve Geliştirici Yöneticimizle iletişime geçtik darbeci_g2 daha ayrıntılı bir açıklama sağlamak için.

"Ben bunu yazarken, [Stagefright] istismarının BlackHat'ta açıklanması gerekiyordu [Bağlantı], ancak henüz slayt veya teknik inceleme ayrıntıları mevcut değil.

Bu nedenle, bu açıklamayı, tam doğruluk vb. ile son derece derinlemesine bir açıklama olmaktan ziyade, neler olup bittiğine dair kaba bir fikir olarak veriyorum.

Stagefright'ı oluşturan çok sayıda farklı hata vardır ve bunların kendi CVE'leri vardır [Yaygın Güvenlik Açıkları ve Etkilenmeler] izleme için sayılar:

• CVE-2015-1538
• CVE-2015-1539
• CVE-2015-3824
• CVE-2015-3826
• CVE-2015-3827
• CVE-2015-3828
• CVE-2015-3829

Maalesef mevcut yamalar her bir CVE'ye doğrudan bağlı değildir (olması gerektiği gibi), dolayısıyla bunu açıklamak biraz karmaşık olacaktır.

1. [CVE-2015-1538]

MPEG4 işleme kodunda, 3GPP meta verileri (bir video 3GPP formatında olduğunda formatı ve diğer ekstra bilgileri açıklayan bilgiler) işleme kodu sorunludur. Verilerin aşırı büyük olduğu meta verileri reddetmek yerine yalnızca çok küçük olup olmadığını kontrol etti. Bu, bir saldırganın, olması gerekenden daha uzun bir meta veri kısmına sahip olacak "değiştirilmiş" veya "bozuk" bir dosya oluşturmasının mümkün olduğu anlamına geliyordu.

"Güvenilmeyen" verileri (yani bir kullanıcıdan veya kodunuzun dışındaki herhangi bir yerden gelen) işlemek için kod yazmanın en büyük zorluklarından biri, değişken uzunluktaki verileri yönetmektir. Videolar bunun mükemmel bir örneğidir. Yazılımın, olup bitene bağlı olarak belleği dinamik olarak ayırması gerekir.

Bu durumda, bir belleğe işaretçi olarak bir arabellek oluşturulur, ancak işaret ettiği dizinin uzunluğu bir öğe çok kısadır. Daha sonra meta veriler bu diziye okundu ve bu dizideki son girdinin "boş" (veya sıfır) olmaması mümkün oldu. Dizideki son öğenin sıfır olması önemlidir, çünkü yazılım dizinin bittiğini bu şekilde söyler. Son değeri sıfırdan farklı hale getirebilmek (dizi potansiyel olarak bir öğenin çok küçük olması nedeniyle), kötü amaçlı kodun kodun başka bir kısmı tarafından okunabilmesine ve çok fazla verinin okunabilmesine olanak sağladı. Bu değerin sonunda durmak yerine okumaması gereken diğer verileri okumaya devam edebilir.

(Ref: OmniROM Gerrit)

2. [CVE-2015-1539]

UTF-16 dizesi olması nedeniyle meta verinin mümkün olan en kısa "boyutu" 6 bayt olmalıdır. Kod tam sayı değerinin boyutunu alır ve bundan 6 çıkarır. Bu değer 6'dan küçük olsaydı, çıkarma işlemi "yetersiz" olur ve etrafı sarardı ve sonuçta çok büyük bir sayı elde ederdik. Örneğin yalnızca 0'dan 65535'e kadar sayabildiğinizi düşünün. 4 sayısını alıp 6'yı çıkarırsanız sıfırın altına inemezsiniz. Yani 65535'e geri dönün ve oradan sayın. Burada olan da bu!

6'nın altında bir uzunluk alınırsa bu, karelerin kodunun hatalı şekilde çözülmesine yol açabilir, çünkü byteswap işlemi, değeri ile başlayan bir hesaplamadan elde edilen len16 değişkenini kullanır. (boyut-6). Bu, amaçlanandan çok daha büyük bir takas işleminin gerçekleşmesine neden olabilir ve bu da çerçeve verilerindeki değerlerin beklenmedik bir şekilde değişmesine neden olabilir.

(Ref: OmniROM Gerrit)

3. [CVE-2015-3824]

Büyük bir şey! Bu çok kötü. Bu son sorunun tam tersi var: bir tam sayının "çok büyük" olabileceği bir tam sayı taşması. Eğer 65535'e ulaştıysanız (örneğin) ve daha fazlasını sayamıyorsanız, yuvarlanırsınız ve ardından 0'a gidersiniz!

Buna dayanarak bellek ayırıyorsanız (Stagefright'ın yaptığı da budur!), dizide çok az bellek ayrılmış olur. Buna veri eklendiğinde, kötü amaçlı dosyayı oluşturan kişinin kontrol ettiği verilerle ilgisiz verilerin üzerine yazılması olasıdır.

(Ref: OmniROM Gerrit)

4. [CVE-2015-3826]

Bir iğrençlik daha! Sonuncuya çok benzer - bir dizinin (arabellek olarak kullanılan) çok küçük yapılacağı başka bir tamsayı taşması. Bu, ilgisiz belleğin üzerine yazılmasına olanak tanır ve bu da yine kötü bir durumdur. Belleğe veri yazabilen biri, ilgisiz diğer verileri bozabilir ve potansiyel olarak bunu kontrol ettiği bazı kodun telefonunuzda çalıştırılmasını sağlamak için kullanabilir.

(Ref: OmniROM Gerrit)

5. [CVE-2015-3827]

Bu sonunculara oldukça benzer. Bir hafızanın bir kısmı atlanırken bir değişken kullanılır ve bu, çıkarma işlemi sırasında negatif yapılabilir (yukarıdaki gibi). Bu, çok büyük bir "atlama" uzunluğuna, arabelleğin taşmasına ve erişilmemesi gereken belleğe erişim sağlanmasına neden olur.

(Ref: OmniROM Gerrit)

Ayrıca [Android] 5.1'de de kullanılmış gibi görünen bazı (potansiyel olarak) ilgili düzeltmeler var.

(Ref: OmniROM Gerrit)

Bu, kendisi de taşabilecek sınır kontrolleri eklemek için geçmiş bir güvenlik düzeltmesiyle ilgili sorunları durdurmaya yönelik kontroller ekler. C'de imzalı int olarak temsil edilebilen sayılar imzalı int olarak saklanır. Aksi takdirde işlemler sırasında değişmeden kalırlar. Bu kontrollerde, bazı tamsayılar imzalı hale getirilmiş olabilir (imzasız yerine), bu da daha sonra maksimum değerlerini düşürebilir ve taşma oluşmasına neden olabilir.

(Ref: OmniROM Gerrit)

Biraz daha fazla tamsayı taşması (sayıların çok düşük olduğu ve daha sonra bu sayılar üzerinde çıkarma işlemi gerçekleştirilerek negatif olmalarına izin verilir). Bu da yine küçük sayı yerine büyük sayıya yol açar ve bu da yukarıdakiyle aynı sorunlara neden olur.

(Ref: OmniROM Gerrit)

Ve son olarak bir tamsayı taşması daha. Daha önce olduğu gibi, başka bir yerde kullanılmak üzere, taşabilir.

(Ref: OmniROM Gerrit)"

Stagefright ne kadar ciddi?

Göre Blog yazısı Ana araştırma şirketi Zimperium Research Labs tarafından yayınlanan Stagefright saldırısı potansiyel olarak açığa çıkıyor Android cihazların %95'i (yaklaşık 950 Milyon) bu güvenlik açığından etkileniyor çünkü Android 2.2 ve 2.2 çalıştıran cihazları etkiliyor. yukarı. Daha da kötüsü, Jelly Bean 4.3'ten önceki cihazlar bu istismara karşı yeterli önlemleri içermediğinden "en kötü risk" altındadır.

Stagefright'ın verebileceği hasarla ilgili olarak Pulser_g2 şunu belirtti:

[blockquote yazar = "pulser_g2"]"Stagefright kendi başına telefondaki sistem kullanıcısına erişim sağlar. Aslında kötüye kullanmak için ASLR'yi (adres alanı düzeni rastgeleleştirmesi) atlamanız gerekir. Bunun gerçekleşip gerçekleşmediği şu anda bilinmiyor. Bu istismar, sistem veya medya kullanıcısı olarak cihazınızda "rastgele kod" çalıştırılmasına olanak tanır. Bunlar cihazdaki sese ve kameraya erişime sahiptir ve sistem kullanıcısı, kökten yararlanma işlemini başlatmak için harika bir yerdir. Telefonunuzu rootlamak için kullandığınız tüm muhteşem root istismarlarını hatırlıyor musunuz?

Bunlar potansiyel olarak cihazınızda root kazanmak için sessizce kullanılabilir! Root sahibi olan, telefonun sahibidir. SELinux'u atlamak zorunda kalacaklardı ama TowelRoot bunu başardı ve PingPong da başardı. Root aldıklarında telefonunuzdaki her şey onlara açıktır. Mesajlar, anahtarlar vb."[/blockquote]En kötü senaryolardan bahsetmişken, kodu iletmek ve bu istismarı tetiklemek için yalnızca bir MMS'e ihtiyaç vardır. Kullanıcı mesajı açmaya bile gerek yok Pek çok mesajlaşma uygulaması, kullanıcı onunla etkileşime girmeden önce MMS'i önceden işler. Bu, hedef odaklı kimlik avı saldırılarından farklıdır; çünkü kullanıcı başarılı bir saldırıdan tamamen habersiz olabilir ve telefondaki mevcut ve gelecekteki tüm verileri tehlikeye atabilir.

Stagefright'ı diğer "büyük güvenlik açıklarından" farklı kılan nedir?

"Tüm güvenlik açıkları kullanıcılar için bazı riskler oluşturur. Bu özellikle risklidir, çünkü birisi ona uzaktan saldırmanın bir yolunu bulursa (ki bu ASLR'yi aşmanın bir yolu bulunursa), siz farkında bile olmadan tetiklenebilir. saldırı"

Android Installer Hijacking, FakeID gibi daha eski istismarların yanı sıra TowelRoot ve PingPong gibi kök istismarlarının yürütülebilmesi için bir noktada kullanıcı etkileşimi gerekir. Kötü niyetli olarak kullanıldığında pek çok zararın ortaya çıkabileceği gerçeğinden dolayı hala "istismarcı" olsalar da, Stagefright'ın gerçek olduğu gerçeği ortadadır. teorik olarak kurbanın telefonunu bir truva atına dönüştürmek için yalnızca cep telefonu numarasına ihtiyaç vardır ve bu nedenle son zamanlarda bu kadar çok ilgi görmektedir. günler.

Ancak Android tamamen bu istismarın insafına kalmış değil. Android Güvenliği Baş Mühendisi Adrian Ludwig, bir konuşmasında bazı endişeleri dile getirdi. Google+ yayını:

[blockquote yazar = "Adrian Ludwig"]"Herhangi bir yazılım hatasının güvenlik açığına dönüştürülebileceğine dair yaygın ve yanlış bir varsayım vardır. Aslında çoğu hatadan yararlanılamaz ve Android'in bu olasılıkları iyileştirmek için yaptığı pek çok şey vardır...

Ice Cream Sandwich'ten (Android 4.0) bu yana tanıtılan teknolojilerden bazılarının listesi listelenmiştir Burada. Bunlardan en bilineni, tamamı tamamlanmış olan Adres Alanı Düzeni Rastgeleleştirmesi (ASLR)'dir. PIE (Konumdan Bağımsız Çalıştırılabilirler) desteğiyle Android 4.1'de ve şu anda Android'in %85'inden fazlasında cihazlar. Bu teknoloji, bir saldırganın başarılı bir istismar oluşturması için gerekli olan kodun konumunu tahmin etmesini zorlaştırır...

ASLR ile yetinmedik; ayrıca NX, FortifySource, Salt Okunur Yer Değiştirmeler, Yığın Kanaryaları ve daha fazlasını da ekledik."[/blockquote]

Ancak Stagefright'ın Android'in geleceği açısından ciddi bir mesele olduğu ve bu nedenle ilgili paydaşlar tarafından ciddiye alındığı inkar edilemez. Stagefright ayrıca odadaki beyaz fillerin altını çizdi; parçalanma ve güncellemelerin nihayet tüketiciye ulaşması sorunu.

Güncelleme İkilemi

Güncellemelerden bahsetmişken, birçok kişinin söz verdiği gibi OEM'lerin kullanıcı güvenliği sorumluluğunu üstlendiğini görmek güzel Özellikle Stagefright gibi istismarlara yönelik güvenlik düzeltmeleri ve yamaları dahil etmek için güncelleme sürecini geliştirin.

Resmi bir açıklama yayınlayan ilk şirketlerden biri olan Google, söz verdi aylık güvenlik güncellemeleri (planlanan işletim sistemi ve platform güncellemelerine ek olarak) neredeyse 3 yaşındaki Nexus 4 de dahil olmak üzere çoğu Nexus cihazı için. Samsung da aynı yolu izleyerek operatörler ve iş ortaklarıyla birlikte çalışacağını duyurdu. aylık güvenlik güncelleme programı ancak bu uygulamanın cihazlarını ve zaman çizelgesi ayrıntılarını belirtmede başarısız oldu. Bu ilginç çünkü operatörlerle işbirliği içinde güvenlik güncellemelerine yönelik "hızlı takip" yaklaşımından bahsediyor. Taşıyıcıda daha sık güncellemeler bekliyoruz (güvenlik tabanlı da olsa, ancak cihaz yazılımı yükseltmelerini de hızlandıracağını umuyoruz) cihazlar.

Pakete katılan diğer OEM'ler arasında, katılacak olan LG de yer alıyor aylık güvenlik güncellemeleri. Motorola da duyurdu güncellenecek cihazların listesi Stagefright düzeltmeleriyle birlikte listede şirketin 2013'ten bu yana ürettiği hemen hemen tüm cihazlar yer alıyor. Sony de şunu söyledi cihazları yakında yamaları alacak fazla.

Bir kez olsun, operatörler de güncellemelerle geliyor. Sprint var Bir bildiri yayınladı bazı cihazların zaten Stagefright yamasını aldığını ve daha fazla cihazın güncelleme için planlandığını söyledi. AT&T de aynı şeyi yaptı bazı cihazlara yamayı yayınlayarak. Verizon ayrıca yamalar da yayınladı, ancak bu, Galaxy S6 Edge ve Note 4 gibi üst düzey akıllı telefonlara öncelik veren yavaş bir dağıtım olsa da. T-Mobile Note 4 de Stagefright yama güncellemesi aldı.

Son kullanıcı olarak saldırıya uğrama olasılığınızı azaltmak için atabileceğiniz birkaç önlem vardır. Yeni başlayanlar için, telefonunuzda bulunan mesajlaşma uygulamalarında MMS mesajlarının otomatik olarak alınmasını devre dışı bırakın. Bu, istismarın çalışması için hiçbir kullanıcı etkileşiminin gerekli olmadığı durumları kontrol altında tutmalıdır. Bundan sonra, bilinmeyen ve güvenilmeyen kaynaklardan gelen MMS mesajlarından medya indirmekten kaçının.

Bir XDA uzmanı kullanıcısı olarak şunları da yapabilirsiniz: Stagefright'ı devre dışı bırakmak için yapı desteğinizde düzenlemeler yapın. Bu, kendinizi Stagefright'tan kurtarmanın tam ve kesin bir yolu değildir, ancak daha eski bir Android sürümünde takılıp kalırsanız başarılı bir saldırı olasılığını azaltmak için şansınızı değerlendirebilirsiniz. Ayrıca, çoğu kaynakları düzenli olarak AOSP ile senkronize eden ve dolayısıyla Stagefright düzeltmelerinin dahil edildiği özel ROM çözümleri de vardır. AOSP tabanlı bir rom çalıştırıyorsanız, Stagefright yamalarını içeren ROM'un daha yeni bir sürümüne güncelleme yapmanız önemle tavsiye edilir. Kullanabilirsiniz bu uygulama Mevcut günlük sürücünüzün Stagefright'tan etkilenip etkilenmediğini kontrol etmek için.

Android, Sahne Sonrası Korku

Stagefright, Android'e ve onun parçalanma ve güncelleme sorununa karşı bir uyandırma çağrısından başka bir şey değildi. Bu tür kritik düzeltmelerin çok sayıda cihaza zamanında uygulanabilmesini sağlayacak net bir mekanizmanın bulunmadığını vurguluyor. OEM'ler cihazlar için yamalar çıkarmaya çalışırken, acı gerçek şu ki bu düzeltmelerin çoğu yalnızca yeni amiral gemileriyle sınırlı olacak. Amiral gemisi olmayan diğer cihazlar ve daha eski cihazlar, daha küçük OEM'ler ise Stagefright'ın benzerlerine maruz kalmaya devam edecek.

Bu istismarın bir gümüş astarı var: Android'in güncelleme sürecine yeniden dikkat çekti ve bunu, gelecekteki pek çok kurumsal şirketin Android'i kurumsal kullanım için benimsemeye çekmeyeceği bir ışık altında sundu. Google, kurumsal benimsemeyi daha fazla artırmaya çalışırken, güncelleme stratejisini ve OEM'lere izin verdiği kontrol miktarını yeniden düşünmek zorunda kalacak.

Android M'in piyasaya sürülmesi gün geçtikçe yaklaşırken, Google'ın Play hizmetleri paketini tercih ederek AOSP'nin giderek daha fazla bileşenini ortadan kaldırmayı seçmesi sürpriz olmayacaktır. Sonuçta bu, bir cihazın Google Play Store ile birlikte gönderilip gönderilmeyeceği konusunda Google'ın hâlâ tam kontrol sahibi olduğu bir alandır. Bu kendi dezavantajları var açık kaynaklı alanların yakın kaynaklı duvarlarla değiştirilmesi şeklinde.

Android'in geleceği hakkında spekülasyon yaparken, Google'ın OEM'lerin AOSP'de yapabileceği değişiklikleri de sınırlandırabilmesi (çok küçük) bir olasılıktır. İle RRO çerçevesi Android M'de işlevsel bir durumda bulunan Google, OEM'lerin yalnızca RRO kaplamaları biçiminde kozmetik değişiklikler yapmasını kısıtlayabilir. Bu, daha hızlı güncelleme dağıtımına olanak sağlamalıdır ancak OEM'lerin Android'i tamamen özelleştirme fırsatının reddedilmesi pahasına olacaktır.

Olası olabilecek başka bir yol da, bu paketle birlikte gönderilen tüm cihazlar için zorunlu hale getirilmesi olabilir. Google Play Store, sabit bir süre (muhtemelen iki) için garantili güvenlik güncellemeleri alacak yıllar. Play Hizmetleri çerçevesi, önemli güvenlik güncellemelerinin ve yamaların varlığını kontrol etmek için kullanılabilir; uyumsuzluk durumunda Play Store erişimi iptal edilir.

Kapanış Notları

Bu sorunu çözmenin zarif bir yolu olmadığından, bu hala en iyi ihtimalle spekülasyondur. Çok totaliter bir yaklaşımın dışında, düzeltmelerin gerçekleştirilmesinde her zaman bazı eksiklikler olacaktır. Piyasada çok sayıda Android cihaz olduğundan, her cihazın güvenlik durumunu takip etmek çok devasa bir görev olacaktır. Şu anki ihtiyaç, Android'in güncelleme şeklinin yeniden düşünülmesidir çünkü mevcut yol kesinlikle en iyisi değildir. XDA Developers olarak biz, Android'in Google'ın kapalı kaynak planlarıyla birlikte çalışırken Açık Kaynak köklerine sadık kalmaya devam etmesini umuyoruz.

Telefonunuz Stagefright'a karşı savunmasız mı? Telefonunuzun bir Stagefright yaması alacağını düşünüyor musunuz? Aşağıdaki yorumlarda bize bildirin!