Android güvenlik ekibi, Android platformunda ve Android cihazlarla birlikte gelen birçok temel Android uygulamasında keşfedilen güvenlik açıklarının yönetiminden sorumludur.
Android güvenlik ekibi, dahili araştırma yoluyla güvenlik açıklarını bulur ve ayrıca üçüncü taraflarca bildirilen hatalara yanıt verir. Harici hata kaynakları, güvenlik açığı formu aracılığıyla bildirilen sorunları, yayınlanmış ve önceden yayınlanmış akademik araştırmaları, yukarı akış açık kaynak proje yürütücülerini, cihaz üreticisi iş ortaklarımızdan gelen bildirimleri ve bloglarda veya sosyal medyada yayınlanan kamuya açıklanan sorunları içerir.
Güvenlik sorunlarını bildirme
Herhangi bir geliştirici, Android kullanıcısı veya güvenlik araştırmacısı, güvenlik açığı formu aracılığıyla olası güvenlik sorunlarını Android güvenlik ekibine bildirebilir.
Güvenlik sorunu olarak işaretlenen hatalar dışarıdan görünmez, ancak sorun değerlendirildikten veya çözüldükten sonra sonunda görünür hale getirilebilir. Bir güvenlik sorununu çözmek için bir yama veya Uyumluluk Test Paketi (CTS) testi göndermeyi planlıyorsanız, lütfen bunu hata raporuna ekleyin ve kodu AOSP'ye yüklemeden önce yanıt bekleyin.
Tetikleme hataları
Bir güvenlik açığının ele alınmasındaki ilk görev, hatanın önem derecesini ve Android'in hangi bileşeninin etkilendiğini belirlemektir. Önem derecesi, sorunun nasıl önceliklendirileceğini ve bileşen, hatayı kimin düzelteceğini, kime bildirileceğini ve düzeltmenin kullanıcılara nasıl dağıtılacağını belirler.
Bağlam türleri
Bu tablo, donanım ve yazılım güvenlik bağlamlarının tanımlarını kapsar. Bağlam, tipik olarak işlediği verilerin hassasiyetine veya içinde çalıştığı alana göre tanımlanabilir. Tüm güvenlik bağlamları tüm sistemler için geçerli değildir. Bu tablo en az ayrıcalıklıdan en çok ayrıcalıklıya doğru sıralanmıştır.
| bağlam türü | Tip tanımı |
|---|---|
| kısıtlı bağlam | Yalnızca en az izinlerin sağlandığı kısıtlı bir yürütme ortamı. Örneğin, korumalı bir ortamda güvenilmeyen verileri işleyen güvenilir uygulamalar. |
| Ayrıcalıksız bağlam | Ayrıcalıksız kod tarafından beklenen tipik bir yürütme ortamı. Örneğin, untrusted_app_all özniteliğine sahip bir SELinux etki alanında çalışan bir Android uygulaması. |
| ayrıcalıklı bağlam | Yükseltilmiş izinlere erişimi olabilen, birden çok kullanıcı PII'sini işleyen ve/veya sistem bütünlüğünü koruyan ayrıcalıklı bir yürütme ortamı. Örneğin, SELinux untrusted_app etki alanı tarafından yasaklanacak yeteneklere sahip veya privileged|signature izinlerine erişimi olan bir Android uygulaması. |
| İşletim Sistemi Çekirdeği | İşlevsellik:
|
| Güvenilir Donanım Tabanı (THB) | Cihazın temel kullanım durumlarında (hücresel temel bantlar, DSP'ler, GPU'lar ve ML işlemciler gibi) kritik işlevsellik sağlayan, genellikle SoC'de bulunan ayrı donanım bileşenleri. |
| Bootloader Zinciri | Cihazı önyükleme sırasında yapılandıran ve ardından kontrolü Android işletim sistemine geçiren bir bileşen. |
| Güvenilir Yürütme Ortamı (TEE) | Düşman bir İşletim Sistemi Çekirdeğinden bile korunmak üzere tasarlanmış bir bileşen (örneğin, TrustZone ve Sanal Makineleri İşletim Sistemi Çekirdeğinden koruyan pKVM gibi hipervizörler). |
| Güvenli Bölge / Güvenli Öğe (SE) | Secure Elements'a Giriş bölümünde tanımlandığı gibi, cihazdaki diğer tüm bileşenlerden ve fiziksel saldırılardan korunmak üzere tasarlanmış isteğe bağlı bir donanım bileşeni. Bu, bazı Android cihazlarda bulunan Titan-M çipini içerir. |
önem derecesi
Bir hatanın ciddiyeti, genellikle bir hatadan başarıyla yararlanıldığında meydana gelebilecek potansiyel zararı yansıtır. Önem derecesini belirlemek için aşağıdaki kriterleri kullanın.
| Değerlendirme | Başarılı sömürünün sonucu |
|---|---|
| kritik |
|
| Yüksek |
|
| Ilıman |
|
| Düşük |
|
| İhmal Edilebilir Güvenlik Etkisi (NSI) |
|
Derecelendirme değiştiricileri
Güvenlik açıklarının ciddiyetini belirlemek genellikle kolay olsa da, derecelendirmeler koşullara göre değişebilir.
| Sebep | Etki |
|---|---|
| Saldırıyı gerçekleştirmek için ayrıcalıklı bir bağlam olarak çalıştırmayı gerektirir (TEE, SE ve pKVM gibi hipervizörler için geçerli değildir) | -1 Önem Derecesi |
| Güvenlik açığına özgü ayrıntılar, sorunun etkisini sınırlar | -1 Önem Derecesi |
| Doğrudan cihaz sahibinden biyometrik bilgi gerektiren biyometrik kimlik doğrulama atlaması | -1 Önem Derecesi |
| Derleyici veya platform yapılandırmaları, kaynak koddaki bir güvenlik açığını azaltır | Altta yatan güvenlik açığı Orta veya daha yüksekse Orta Önem Derecesi |
| Cihazın dahili bileşenlerine fiziksel erişim gerektirir ve cihaz kapalıysa veya açıldıktan sonra kilidi açılmamışsa yine de mümkündür. | -1 Önem Derecesi |
| Cihaz açıkken ve daha önce kilidi açılmışken, cihazın içindekilere fiziksel erişim gerektirir | -2 Şiddet |
| Önyükleyici zincirinin kilidinin açılmasını gerektiren yerel bir saldırı | Düşükten daha yüksek değil |
| Geliştirici Modunun veya herhangi bir kalıcı geliştirici modu ayarının cihazda şu anda etkinleştirilmiş olmasını gerektiren (ve Geliştirici Modunun kendisinde bir hata olmayan) yerel bir saldırı. | Düşükten daha yüksek değil |
| Google tarafından sağlanan SEPolicy kapsamında hiçbir SELinux alanı işlemi gerçekleştiremezse | İhmal Edilebilir Güvenlik Etkisi |
Yerele karşı Yakına karşı Uzak
Uzaktan saldırı vektörü, hatanın bir uygulama yüklenmeden veya bir cihaza fiziksel erişim olmadan kullanılabileceğini gösterir. Bu, bir web sayfasına göz atarak, bir e-postayı okuyarak, bir SMS mesajı alarak veya düşman bir ağa bağlanarak tetiklenebilen hataları içerir. Önem derecesi derecelendirmelerimiz açısından, "yakın" saldırı vektörlerini de uzak olarak değerlendiriyoruz. Bunlar, yalnızca fiziksel olarak hedef cihazın yakınında bulunan bir saldırgan tarafından yararlanılabilen hataları içerir; örneğin, hatalı biçimlendirilmiş Wi-Fi veya Bluetooth paketlerinin gönderilmesini gerektiren bir hata. Ultra geniş bant (UWB) ve NFC tabanlı saldırıları yakın ve dolayısıyla uzak olarak değerlendiriyoruz.
Yerel saldırılar, kurbanın bir uygulamayı yükleyip çalıştırarak veya bir Hazır Uygulama çalıştırmayı kabul ederek bir uygulamayı çalıştırmasını gerektirir. Eşleştirilmiş tamamlayıcı cihazlar yerel olarak kabul edilecektir. Android güvenlik ekibi, önem derecesi derecelendirmeleri amacıyla fiziksel saldırı vektörlerini de yerel olarak kabul eder. Bunlar, yalnızca cihaza fiziksel erişimi olan bir saldırgan tarafından yararlanılabilen, örneğin kilit ekranındaki bir hata veya bir USB kablosunun takılmasını gerektiren hatalar içerir.
Ağ güvenliği
Android, tüm ağların düşman olduğunu ve saldırılar düzenleyebileceğini veya trafiği gözetleyebileceğini varsayar. Bağlantı katmanı güvenliği (örneğin, Wi-Fi şifrelemesi), bir cihaz ile bağlı olduğu Erişim Noktası arasındaki iletişimi güvence altına alırken, cihaz ile iletişim kurduğu sunucular arasındaki zincirde kalan halkaları güvence altına almak için hiçbir şey yapmaz.
Buna karşılık, HTTPS tipik olarak tüm iletişimi uçtan uca korur, verileri kaynağında şifreler ve ardından yalnızca nihai hedefine ulaştığında şifresini çözer ve doğrular. Bu nedenle, bağlantı katmanı ağ güvenliğini tehlikeye atan güvenlik açıkları, HTTPS/TLS'deki güvenlik açıklarından daha az ciddi olarak derecelendirilir: Tek başına Wi-Fi şifrelemesi, internetteki çoğu iletişim için yetersizdir.
Biyometrik kimlik doğrulama
Biyometrik kimlik doğrulama zorlu bir alandır ve en iyi sistemler bile yakın bir eşleşme tarafından kandırılabilir (bkz. Android Geliştiricileri Blogu: Android 11'de kilit ekranı ve kimlik doğrulama geliştirmeleri ). Bu önem dereceleri, iki saldırı sınıfı arasında ayrım yapar ve son kullanıcıya yönelik gerçek riski yansıtmayı amaçlar.
Birinci sınıf saldırılar, sahibinden yüksek kaliteli biyometrik veriler olmadan, genelleştirilebilir bir şekilde biyometrik kimlik doğrulamanın atlanmasına izin verir. Örneğin, bir saldırgan parmak izi sensörüne bir parça sakız yerleştirebilir ve sensörde kalan kalıntıya dayalı olarak cihaza erişim izni verirse, bu, herhangi bir hassas cihazda gerçekleştirilebilecek basit bir saldırıdır. Cihazın sahibi hakkında herhangi bir bilgi gerektirmez. Genelleştirilebilir olduğu ve potansiyel olarak daha fazla sayıda kullanıcıyı etkileyebildiği göz önüne alındığında, bu saldırı tam önem derecesini alır (örneğin, Kilit Ekranını atlamak için Yüksek).
Diğer saldırı sınıfı, genellikle cihaz sahibine dayalı bir sunum saldırı aracını (sahte) içerir. Bazen bu biyometrik bilgileri elde etmek nispeten kolaydır (örneğin, birinin sosyal medyadaki profil resmi biyometrik kimlik doğrulamasını yanıltmak için yeterliyse, o zaman biyometrik baypas tam önem derecesini alır). Ancak bir saldırganın biyometrik verileri doğrudan cihaz sahibinden alması gerekiyorsa (örneğin, yüzlerinin kızılötesi taraması), bu, saldırıdan etkilenen insan sayısını sınırlayacak kadar önemli bir engeldir, bu nedenle -1 değiştirici vardır. .
SYSTEM_ALERT_WINDOW ve Tapjacking
SYSTEM_ALERT_WINDOW ve tapjacking ile ilgili politikalarımız hakkında bilgi için, BugHunter University'nin Güvenlik etkisi olmayan hatalar sayfasının " Güvenlik açısından kritik olmayan bir ekranda SYSTEM_ALERT_WINDOW güvenlik açığını ele geçirme/bindirme " bölümüne bakın.
Android Automotive OS'de çok kullanıcılı güvenlik
Android Automotive OS, diğer form faktörlerinden farklı çok kullanıcılı bir güvenlik modelini benimser. Her Android kullanıcısının farklı bir fiziksel kişi tarafından kullanılması amaçlanmıştır. Örneğin araç sahibinden aracı ödünç alan bir arkadaşa geçici misafir kullanıcı atanabilir. Bunun gibi kullanım durumlarını karşılamak için, kullanıcılar varsayılan olarak aracı kullanmak için gereken Wi-Fi ve hücresel ağ ayarları gibi gerekli bileşenlere erişebilir.
Etkilenen bileşen
Hatayı düzeltmekten sorumlu geliştirme ekibi, hatanın hangi bileşende olduğuna bağlıdır. Bu, Android platformunun temel bir bileşeni, orijinal ekipman üreticisi (OEM) tarafından sağlanan bir çekirdek sürücüsü veya Pixel cihazlarında önceden yüklenmiş uygulamalardan biri olabilir. .
AOSP kodundaki hatalar, Android mühendislik ekibi tarafından giderilir. Önem düzeyi düşük hatalar, belirli bileşenlerdeki hatalar veya zaten genel olarak bilinen hatalar, doğrudan genel kullanıma açık AOSP ana dalında düzeltilebilir; aksi halde önce dahili depolarımızda sabitlenirler.
Bileşen, kullanıcıların güncellemeleri nasıl aldığı konusunda da bir faktördür. Çerçeve veya çekirdekteki bir hata, her OEM'in göndermesi gereken kablosuz (OTA) bir üretici yazılımı güncellemesi gerektirir. Google Play'de yayınlanan bir uygulama veya kitaplıkta (örneğin, Gmail, Google Play Hizmetleri veya WebView) bulunan bir hata, Android kullanıcılarına Google Play'den bir güncelleme olarak gönderilebilir.
Ortakları bilgilendirmek
AOSP'deki bir güvenlik açığı bir Android Güvenlik Bülteni'nde giderildiğinde, Android iş ortaklarına sorun ayrıntılarını bildirir ve yamalar sağlarız. Backport destekli sürümlerin listesi, her yeni Android sürümünde değişir. Desteklenen cihazların listesi için cihaz üreticinize başvurun.
AOSP'ye kod bırakma
Güvenlik hatası bir AOSP bileşenindeyse, OTA kullanıcılara yayınlandıktan sonra düzeltme AOSP'ye gönderilir. Önem düzeyi düşük sorunlar için düzeltmeler, bir OTA aracılığıyla cihazlara bir düzeltme sunulmadan önce doğrudan AOSP ana şubesine gönderilebilir.
Android güncellemelerini alma
Android sistemine yapılan güncellemeler, cihazlara genellikle OTA güncelleme paketleri aracılığıyla ulaştırılır. Bu güncellemeler, cihazı üreten OEM'den veya cihaza servis sağlayan taşıyıcıdan gelebilir. Google Pixel cihaz güncellemeleri, bir operatör teknik kabulü (TA) test prosedüründen geçtikten sonra Google Pixel ekibinden gelir. Google ayrıca cihazlara yandan yüklenebilen Pixel fabrika görüntüleri de yayınlar.
Google hizmetleri güncelleniyor
Android güvenlik ekibi, güvenlik açıkları için yamalar sağlamanın yanı sıra, kullanıcıları korumanın başka yolları olup olmadığını belirlemek için güvenlik açıklarını inceler. Örneğin, Google Play tüm uygulamaları tarar ve bir güvenlik açığından yararlanmaya çalışan tüm uygulamaları kaldırır. Google Play'in dışından yüklenen uygulamalar için Google Play Hizmetlerine sahip cihazlar, kullanıcıları potansiyel olarak zararlı olabilecek uygulamalar hakkında uyarmak için Uygulamaları Doğrula özelliğini kullanabilir.
Diğer kaynaklar
Android uygulama geliştiricileri için bilgiler: https://developer.android.com
Güvenlik bilgileri, Android Açık Kaynak ve Geliştirici sitelerinde mevcuttur. Başlamak için iyi yerler:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Raporlar
Bazen Android Güvenlik ekibi raporlar veya teknik incelemeler yayınlar. Daha fazla ayrıntı için Güvenlik Raporlarına bakın.
,Android güvenlik ekibi, Android platformunda ve Android cihazlarla birlikte gelen birçok temel Android uygulamasında keşfedilen güvenlik açıklarının yönetiminden sorumludur.
Android güvenlik ekibi, dahili araştırma yoluyla güvenlik açıklarını bulur ve ayrıca üçüncü taraflarca bildirilen hatalara yanıt verir. Harici hata kaynakları, güvenlik açığı formu aracılığıyla bildirilen sorunları, yayınlanmış ve önceden yayınlanmış akademik araştırmaları, yukarı akış açık kaynak proje yürütücülerini, cihaz üreticisi iş ortaklarımızdan gelen bildirimleri ve bloglarda veya sosyal medyada yayınlanan kamuya açıklanan sorunları içerir.
Güvenlik sorunlarını bildirme
Herhangi bir geliştirici, Android kullanıcısı veya güvenlik araştırmacısı, güvenlik açığı formu aracılığıyla olası güvenlik sorunlarını Android güvenlik ekibine bildirebilir.
Güvenlik sorunu olarak işaretlenen hatalar dışarıdan görünmez, ancak sorun değerlendirildikten veya çözüldükten sonra sonunda görünür hale getirilebilir. Bir güvenlik sorununu çözmek için bir yama veya Uyumluluk Test Paketi (CTS) testi göndermeyi planlıyorsanız, lütfen bunu hata raporuna ekleyin ve kodu AOSP'ye yüklemeden önce yanıt bekleyin.
Tetikleme hataları
Bir güvenlik açığının ele alınmasındaki ilk görev, hatanın önem derecesini ve Android'in hangi bileşeninin etkilendiğini belirlemektir. Önem derecesi, sorunun nasıl önceliklendirileceğini ve bileşen, hatayı kimin düzelteceğini, kime bildirileceğini ve düzeltmenin kullanıcılara nasıl dağıtılacağını belirler.
Bağlam türleri
Bu tablo, donanım ve yazılım güvenlik bağlamlarının tanımlarını kapsar. Bağlam, tipik olarak işlediği verilerin hassasiyetine veya içinde çalıştığı alana göre tanımlanabilir. Tüm güvenlik bağlamları tüm sistemler için geçerli değildir. Bu tablo en az ayrıcalıklıdan en çok ayrıcalıklıya doğru sıralanmıştır.
| bağlam türü | Tip tanımı |
|---|---|
| kısıtlı bağlam | Yalnızca en az izinlerin sağlandığı kısıtlı bir yürütme ortamı. Örneğin, korumalı bir ortamda güvenilmeyen verileri işleyen güvenilir uygulamalar. |
| Ayrıcalıksız bağlam | Ayrıcalıksız kod tarafından beklenen tipik bir yürütme ortamı. Örneğin, untrusted_app_all özniteliğine sahip bir SELinux etki alanında çalışan bir Android uygulaması. |
| ayrıcalıklı bağlam | Yükseltilmiş izinlere erişimi olabilen, birden çok kullanıcı PII'sini işleyen ve/veya sistem bütünlüğünü koruyan ayrıcalıklı bir yürütme ortamı. Örneğin, SELinux untrusted_app etki alanı tarafından yasaklanacak yeteneklere sahip veya privileged|signature izinlerine erişimi olan bir Android uygulaması. |
| İşletim Sistemi Çekirdeği | İşlevsellik:
|
| Güvenilir Donanım Tabanı (THB) | Cihazın temel kullanım durumlarında (hücresel temel bantlar, DSP'ler, GPU'lar ve ML işlemciler gibi) kritik işlevsellik sağlayan, genellikle SoC'de bulunan ayrı donanım bileşenleri. |
| Bootloader Zinciri | Cihazı önyükleme sırasında yapılandıran ve ardından kontrolü Android işletim sistemine geçiren bir bileşen. |
| Güvenilir Yürütme Ortamı (TEE) | Düşman bir İşletim Sistemi Çekirdeğinden bile korunmak üzere tasarlanmış bir bileşen (örneğin, TrustZone ve Sanal Makineleri İşletim Sistemi Çekirdeğinden koruyan pKVM gibi hipervizörler). |
| Güvenli Bölge / Güvenli Öğe (SE) | Secure Elements'a Giriş bölümünde tanımlandığı gibi, cihazdaki diğer tüm bileşenlerden ve fiziksel saldırılardan korunmak üzere tasarlanmış isteğe bağlı bir donanım bileşeni. Bu, bazı Android cihazlarda bulunan Titan-M çipini içerir. |
önem derecesi
Bir hatanın ciddiyeti, genellikle bir hatadan başarıyla yararlanıldığında meydana gelebilecek potansiyel zararı yansıtır. Önem derecesini belirlemek için aşağıdaki kriterleri kullanın.
| Değerlendirme | Başarılı sömürünün sonucu |
|---|---|
| kritik |
|
| Yüksek |
|
| Ilıman |
|
| Düşük |
|
| İhmal Edilebilir Güvenlik Etkisi (NSI) |
|
Derecelendirme değiştiricileri
Güvenlik açıklarının ciddiyetini belirlemek genellikle kolay olsa da, derecelendirmeler koşullara göre değişebilir.
| Sebep | Etki |
|---|---|
| Saldırıyı gerçekleştirmek için ayrıcalıklı bir bağlam olarak çalıştırmayı gerektirir (TEE, SE ve pKVM gibi hipervizörler için geçerli değildir) | -1 Önem Derecesi |
| Güvenlik açığına özgü ayrıntılar, sorunun etkisini sınırlar | -1 Önem Derecesi |
| Doğrudan cihaz sahibinden biyometrik bilgi gerektiren biyometrik kimlik doğrulama atlaması | -1 Önem Derecesi |
| Derleyici veya platform yapılandırmaları, kaynak koddaki bir güvenlik açığını azaltır | Altta yatan güvenlik açığı Orta veya daha yüksekse Orta Önem Derecesi |
| Cihazın dahili bileşenlerine fiziksel erişim gerektirir ve cihaz kapalıysa veya açıldıktan sonra kilidi açılmamışsa yine de mümkündür. | -1 Önem Derecesi |
| Cihaz açıkken ve daha önce kilidi açılmışken, cihazın içindekilere fiziksel erişim gerektirir | -2 Şiddet |
| Önyükleyici zincirinin kilidinin açılmasını gerektiren yerel bir saldırı | Düşükten daha yüksek değil |
| Geliştirici Modunun veya herhangi bir kalıcı geliştirici modu ayarının cihazda şu anda etkinleştirilmiş olmasını gerektiren (ve Geliştirici Modunun kendisinde bir hata olmayan) yerel bir saldırı. | Düşükten daha yüksek değil |
| Google tarafından sağlanan SEPolicy kapsamında hiçbir SELinux alanı işlemi gerçekleştiremezse | İhmal Edilebilir Güvenlik Etkisi |
Yerele karşı Yakına karşı Uzak
Uzaktan saldırı vektörü, hatanın bir uygulama yüklenmeden veya bir cihaza fiziksel erişim olmadan kullanılabileceğini gösterir. Bu, bir web sayfasına göz atarak, bir e-postayı okuyarak, bir SMS mesajı alarak veya düşman bir ağa bağlanarak tetiklenebilen hataları içerir. Önem derecesi derecelendirmelerimiz açısından, "yakın" saldırı vektörlerini de uzak olarak değerlendiriyoruz. Bunlar, yalnızca fiziksel olarak hedef cihazın yakınında bulunan bir saldırgan tarafından yararlanılabilen hataları içerir; örneğin, hatalı biçimlendirilmiş Wi-Fi veya Bluetooth paketlerinin gönderilmesini gerektiren bir hata. Ultra geniş bant (UWB) ve NFC tabanlı saldırıları yakın ve dolayısıyla uzak olarak değerlendiriyoruz.
Yerel saldırılar, kurbanın bir uygulamayı yükleyip çalıştırarak veya bir Hazır Uygulama çalıştırmayı kabul ederek bir uygulamayı çalıştırmasını gerektirir. Eşleştirilmiş tamamlayıcı cihazlar yerel olarak kabul edilecektir. Android güvenlik ekibi, önem derecesi derecelendirmeleri amacıyla fiziksel saldırı vektörlerini de yerel olarak kabul eder. Bunlar, yalnızca cihaza fiziksel erişimi olan bir saldırgan tarafından yararlanılabilen, örneğin kilit ekranındaki bir hata veya bir USB kablosunun takılmasını gerektiren hatalar içerir.
Ağ güvenliği
Android, tüm ağların düşman olduğunu ve saldırılar düzenleyebileceğini veya trafiği gözetleyebileceğini varsayar. Bağlantı katmanı güvenliği (örneğin, Wi-Fi şifrelemesi), bir cihaz ile bağlı olduğu Erişim Noktası arasındaki iletişimi güvence altına alırken, cihaz ile iletişim kurduğu sunucular arasındaki zincirde kalan halkaları güvence altına almak için hiçbir şey yapmaz.
Buna karşılık, HTTPS tipik olarak tüm iletişimi uçtan uca korur, verileri kaynağında şifreler ve ardından yalnızca nihai hedefine ulaştığında şifresini çözer ve doğrular. Bu nedenle, bağlantı katmanı ağ güvenliğini tehlikeye atan güvenlik açıkları, HTTPS/TLS'deki güvenlik açıklarından daha az ciddi olarak derecelendirilir: Tek başına Wi-Fi şifrelemesi, internetteki çoğu iletişim için yetersizdir.
Biyometrik kimlik doğrulama
Biyometrik kimlik doğrulama zorlu bir alandır ve en iyi sistemler bile yakın bir eşleşme tarafından kandırılabilir (bkz. Android Geliştiricileri Blogu: Android 11'de kilit ekranı ve kimlik doğrulama geliştirmeleri ). Bu önem dereceleri, iki saldırı sınıfı arasında ayrım yapar ve son kullanıcıya yönelik gerçek riski yansıtmayı amaçlar.
Birinci sınıf saldırılar, sahibinden yüksek kaliteli biyometrik veriler olmadan, genelleştirilebilir bir şekilde biyometrik kimlik doğrulamanın atlanmasına izin verir. Örneğin, bir saldırgan parmak izi sensörüne bir parça sakız yerleştirebilir ve sensörde kalan kalıntıya dayalı olarak cihaza erişim izni verirse, bu, herhangi bir hassas cihazda gerçekleştirilebilecek basit bir saldırıdır. Cihazın sahibi hakkında herhangi bir bilgi gerektirmez. Genelleştirilebilir olduğu ve potansiyel olarak daha fazla sayıda kullanıcıyı etkileyebildiği göz önüne alındığında, bu saldırı tam önem derecesini alır (örneğin, Kilit Ekranını atlamak için Yüksek).
Diğer saldırı sınıfı, genellikle cihaz sahibine dayalı bir sunum saldırı aracını (sahte) içerir. Bazen bu biyometrik bilgileri elde etmek nispeten kolaydır (örneğin, birinin sosyal medyadaki profil resmi biyometrik kimlik doğrulamasını yanıltmak için yeterliyse, o zaman biyometrik baypas tam önem derecesini alır). But if an attacker would need to acquire biometric data directly from the device owner (for example, an infrared scan of their face), that's a significant enough barrier that it limits the number of people affected by the attack, so there's a -1 modifier.
SYSTEM_ALERT_WINDOW and Tapjacking
For information about our policies regarding SYSTEM_ALERT_WINDOW and tapjacking, see the " Tapjacking/overlay SYSTEM_ALERT_WINDOW vulnerability on a non-security-critical screen " section of BugHunter University's Bugs with no security impact page.
Multi-user security in Android Automotive OS
Android Automotive OS adopts a multi user security model different from the other form factors. Each Android user is intended to be used by a different physical person. For example, a temporary guest user can be assigned to a friend who borrows the vehicle from the car's owner. To accommodate use cases like this, users by default have access to necessary components needed to use the vehicle, such as Wi-Fi and cellular network settings.
Affected component
The development team responsible for fixing the bug depends on which component the bug is in. It could be a core component of the Android platform, a kernel driver supplied by an original equipment manufacturer (OEM), or one of the preloaded apps on Pixel devices.
Bugs in AOSP code are fixed by the Android engineering team. Low-severity bugs, bugs in certain components, or bugs that are already publicly known may be fixed directly in the publicly available AOSP main branch; otherwise they're fixed in our internal repositories first.
The component is also a factor in how users get updates. A bug in the framework or kernel requires an over-the-air (OTA) firmware update that each OEM needs to push. A bug in an app or library published in Google Play (for example, Gmail, Google Play Services, or WebView) can be sent to Android users as an update from Google Play.
Notifying partners
When a security vulnerability in AOSP is fixed in an Android Security Bulletin, we'll notify Android partners of issue details and provide patches. The list of backport-supported versions changes with each new Android release. Contact your device manufacturer for the list of supported devices.
Releasing code to AOSP
If the security bug is in an AOSP component, the fix is pushed out to AOSP after the OTA is released to users. Fixes for low-severity issues may be submitted directly to the AOSP main branch before a fix is available to devices through an OTA.
Receiving Android updates
Updates to the Android system are generally delivered to devices through OTA update packages. These updates may come from the OEM who produced the device or the carrier who provides service to the device. Google Pixel device updates come from the Google Pixel team after going through a carrier technical acceptance (TA) testing procedure. Google also publishes Pixel factory images that can be side-loaded to devices.
Updating Google services
In addition to providing patches for security bugs, the Android security team reviews security bugs to determine if there are other ways to protect users. For example, Google Play scans all apps and removes any app that attempts to exploit a security bug. For apps installed from outside of Google Play, devices with Google Play Services may also use the Verify Apps feature to warn users about apps that may be potentially harmful.
Other resources
Information for Android app developers: https://developer.android.com
Security information exists throughout the Android Open Source and Developer sites. Good places to start:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
Reports
Sometimes the Android Security team publishes reports or whitepapers. See Security Reports for more details.