सुरक्षा से जुड़े अपडेट और संसाधन

Android की सुरक्षा टीम, Android प्लैटफ़ॉर्म और Android डिवाइसों के साथ बंडल किए गए कई मुख्य Android ऐप्लिकेशन में, सुरक्षा से जुड़ी जोखिम वाली स्थितियों को मैनेज करने की ज़िम्मेदारी होती है.

Android की सुरक्षा टीम, अंदरूनी रिसर्च की मदद से सुरक्षा से जुड़ी जोखिम की संभावनाओं का पता लगाती है. साथ ही, तीसरे पक्षों से मिली गड़बड़ियों की शिकायतों पर भी कार्रवाई करती है. बाहरी गड़बड़ियों के सोर्स में, सुरक्षा से जुड़ी समस्याओं की शिकायत करने के लिए बने फ़ॉर्म के ज़रिए बताई गई समस्याएं, पब्लिश की गई और पहले से पब्लिश की गई अकादमिक रिसर्च, अपस्ट्रीम ओपन सोर्स प्रोजेक्ट के रखरखाव करने वाले लोग, डिवाइस बनाने वाले हमारे पार्टनर की सूचनाएं, और ब्लॉग या सोशल मीडिया पर सार्वजनिक तौर पर बताई गई समस्याएं शामिल हैं.

सुरक्षा से जुड़ी समस्याओं की शिकायत करना

कोई भी डेवलपर, Android उपयोगकर्ता या सुरक्षा विशेषज्ञ, सुरक्षा से जुड़ी समस्याओं के बारे में बताने के लिए फ़ॉर्म भरकर, Android की सुरक्षा टीम को सुरक्षा से जुड़ी संभावित समस्याओं के बारे में बता सकता है.

सुरक्षा से जुड़ी समस्याओं के तौर पर मार्क किए गए गड़बड़ियां, संगठन से बाहर नहीं दिखती हैं. हालांकि, समस्या का आकलन करने या उसे हल करने के बाद, उन्हें दिखने दिया जा सकता है. अगर आपको सुरक्षा से जुड़ी किसी समस्या को ठीक करने के लिए, पैच या Compatibility Test Suite (CTS) टेस्ट सबमिट करना है, तो कृपया उसे गड़बड़ी की रिपोर्ट में अटैच करें. साथ ही, AOSP में कोड अपलोड करने से पहले, जवाब मिलने का इंतज़ार करें.

गड़बड़ियों की प्राथमिकता तय करना

सुरक्षा से जुड़े जोखिम को ठीक करने के लिए, सबसे पहले यह पता लगाना ज़रूरी है कि बग कितना गंभीर है और Android के किस कॉम्पोनेंट पर असर पड़ा है. गंभीरता से यह तय होता है कि समस्या को प्राथमिकता कैसे दी जाए. साथ ही, कॉम्पोनेंट से यह तय होता है कि गड़बड़ी को कौन ठीक करता है, किसे सूचना दी जाती है, और उपयोगकर्ताओं के लिए गड़बड़ी को कैसे डिप्लॉय किया जाता है.

कॉन्टेक्स्ट के टाइप

इस टेबल में, हार्डवेयर और सॉफ़्टवेयर की सुरक्षा से जुड़े कॉन्टेक्स्ट की परिभाषाएं दी गई हैं. कॉन्टेक्स्ट को, आम तौर पर प्रोसेस किए जाने वाले डेटा की संवेदनशीलता या उस क्षेत्र के हिसाब से तय किया जा सकता है जहां यह चलता है. सभी सुरक्षा कॉन्टेक्स्ट, सभी सिस्टम पर लागू नहीं होते. इस टेबल में, कम से ज़्यादा अनुमति वाले ऐक्सेस को क्रम में लगाया गया है.

कॉन्टेक्स्ट टाइप टाइप की परिभाषा
सीमित संदर्भ ऐसा सीमित वर्शन जिसमें सिर्फ़ कम से कम अनुमतियां दी जाती हैं.

उदाहरण के लिए, भरोसेमंद ऐप्लिकेशन, सैंडबॉक्स किए गए एनवायरमेंट में गैर-भरोसेमंद डेटा को प्रोसेस करते हैं.
बिना अनुमति वाला कॉन्टेक्स्ट बिना खास सुविधाओं वाले कोड के लिए, एक सामान्य तौर पर इस्तेमाल होने वाला एनवायरमेंट.

उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जो untrusted_app_all एट्रिब्यूट वाले SELinux डोमेन में काम करता है.
खास जानकारी खास सुविधाओं वाला एक प्रोसेसिंग एनवायरमेंट, जिसमें ऐलिमेंट की अनुमतियों का ऐक्सेस हो सकता है. साथ ही, यह एक से ज़्यादा उपयोगकर्ताओं की PII को हैंडल करता है और/या सिस्टम की सुरक्षा बनाए रखता है.

उदाहरण के लिए, ऐसा Android ऐप्लिकेशन जिसमें ऐसी सुविधाएं हों जिन्हें SELinux untrusted_app डोमेन से पाबंदी लगी हो या privileged|signature अनुमतियों का ऐक्सेस हो.
ओएस कर्नेल ऐसी सुविधाएं जो:
  • कर्नेल का हिस्सा है
  • कर्नेल के साथ एक ही सीपीयू कॉन्टेक्स्ट में काम करता है. उदाहरण के लिए, डिवाइस ड्राइवर
  • उसके पास कर्नेल मेमोरी का सीधा ऐक्सेस हो (उदाहरण के लिए, डिवाइस के हार्डवेयर कॉम्पोनेंट)
  • इसमें कर्नेल कॉम्पोनेंट (उदाहरण के लिए, eBPF) में स्क्रिप्ट लोड करने की सुविधा होती है
  • उपयोगकर्ताओं के लिए उपलब्ध कुछ सेवाओं में से एक है. इसे कर्नेल के बराबर माना जाता है. जैसे, apexd, bpfloader, init, ueventd, और vold.
भरोसेमंद हार्डवेयर बेस (THB) आम तौर पर, SoC पर मौजूद अलग-अलग हार्डवेयर कॉम्पोनेंट, जो डिवाइस के मुख्य इस्तेमाल के उदाहरणों (जैसे, सेल्युलर बेसबैंड, डीएसपी, जीपीयू, और एमएल प्रोसेसर) के लिए ज़रूरी फ़ंक्शन उपलब्ध कराते हैं.
बूटलोडर चेन यह एक ऐसा कॉम्पोनेंट है जो डिवाइस को बूट करने पर कॉन्फ़िगर करता है और फिर Android OS को कंट्रोल देता है.
ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) ऐसा कॉम्पोनेंट जिसे खतरनाक ओएस कर्नेल से भी सुरक्षित रखने के लिए डिज़ाइन किया गया है. उदाहरण के लिए, TrustZone और pKVM जैसे हाइपरवाइजर, जो वर्चुअल मशीनों को ओएस कर्नेल से सुरक्षित रखते हैं.
सिक्योर एन्क्लेव / सिक्योर एलिमेंट (एसई) यह एक वैकल्पिक हार्डवेयर कॉम्पोनेंट है. इसे डिवाइस के सभी अन्य कॉम्पोनेंट और फ़िज़िकल अटैक से सुरक्षित रखने के लिए डिज़ाइन किया गया है. इस बारे में ज़्यादा जानकारी के लिए, सुरक्षित एलिमेंट के बारे में जानकारी लेख पढ़ें.

इसमें कुछ Android डिवाइसों में मौजूद Titan-M चिप भी शामिल है.

गंभीरता

आम तौर पर, किसी बग की गंभीरता से यह पता चलता है कि बग का इस्तेमाल करने पर, क्या नुकसान हो सकता है. समस्या की गंभीरता का पता लगाने के लिए, इन शर्तों का इस्तेमाल करें.

रेटिंग एक्सप्लोरेशन के सफल होने का नतीजा
सबसे अहम सिद्धांत
  • टीईई या एसई में मनमुताबिक कोड चलाना
  • सुरक्षा से जुड़े सॉफ़्टवेयर या हार्डवेयर कॉम्पोनेंट के काम न करने से रोकने के लिए डिज़ाइन किए गए सॉफ़्टवेयर मेकेनिज्म को बायपास करना. उदाहरण के लिए, थर्मल प्रोटेक्शन
  • रिमोट सेवा की पुष्टि करने के लिए इस्तेमाल किए जाने वाले संवेदनशील क्रेडेंशियल का रिमोट ऐक्सेस (उदाहरण के लिए, खाते के पासवर्ड या बियरर टोकन)
  • उपयोगकर्ता के इंटरैक्शन के बिना, मोबाइल बेसबैंड कॉन्टेक्स्ट में मनमुताबिक कोड को रिमोट से चलाना. उदाहरण के लिए, मोबाइल रेडियो सेवा में मौजूद किसी गड़बड़ी का फ़ायदा उठाना
  • किसी खास कॉन्टेक्स्ट, बूटलोडर चेन, THB या ओएस कर्नेल में, मनमुताबिक कोड को रिमोट से चलाना
  • पैकेज इंस्टॉल करने या मिलते-जुलते व्यवहार के लिए, उपयोगकर्ता के इंटरैक्शन से जुड़ी ज़रूरी शर्तों को रिमोट से बायपास करना
  • मुख्य डेवलपर, सुरक्षा या निजता सेटिंग के लिए, उपयोगकर्ता इंटरैक्शन की ज़रूरी शर्तों को रिमोट तौर पर बायपास करना
  • डिवाइस को रिमोट से लगातार सेवा देने से रोकना (स्थायी रूप से, पूरे ऑपरेटिंग सिस्टम को फिर से फ़्लैश करने या फ़ैक्ट्री रीसेट करने की ज़रूरत होती है)
  • रिमोट से सेक्योर बूट को बायपास करना
  • एसई से सुरक्षित किए गए डेटा का बिना अनुमति वाला ऐक्सेस. इसमें एसई में कमज़ोर कुंजियों से चालू किया गया ऐक्सेस भी शामिल है.
ज़्यादा
  • सुरक्षा से जुड़ी मुख्य सुविधा को पूरी तरह से बायपास करना. जैसे, SELinux, FBE या seccomp
  • बूटलोडर चेन, टीईई या एसई में, बेहतर सुरक्षा या एक्सप्लॉइट कम करने वाली टेक्नोलॉजी के लिए सामान्य बाईपास
  • ऑपरेटिंग सिस्टम की सुरक्षा से जुड़ी सामान्य सुविधाओं को बायपास करने का तरीका, जो ऐप्लिकेशन, उपयोगकर्ता या प्रोफ़ाइल की सीमाओं के हिसाब से मेमोरी या फ़ाइल का कॉन्टेंट दिखाती है
  • किसी एसई पर हमले, जिसकी वजह से कम सुरक्षित तरीके से लागू किया जाता है
  • रिमोट से ऐक्सेस किए जा सकने वाले, हैक किए गए बेर-मेटल फ़र्मवेयर (उदाहरण के लिए, बेसबैंड, कम्यूनिकेशन प्रोसेसर (सीपी)) से ऐप्लिकेशन प्रोसेसर (एपी) कर्नेल पर स्विच करना या ऐसे तरीकों को बायपास करना जिन्हें बेर-मेटल फ़र्मवेयर को एपी कर्नेल से अलग करने के लिए डिज़ाइन किया गया है
  • डिवाइस की सुरक्षा, फ़ैक्ट्री रीसेट करने से जुड़ी सुरक्षा या मोबाइल और इंटरनेट सेवा देने वाली कंपनी की पाबंदियों को बायपास करना
  • टीईई की मदद से सुरक्षित किए गए, उपयोगकर्ता इंटरैक्शन की ज़रूरी शर्तों को बायपास करना
  • क्रिप्टोग्राफ़ी से जुड़ी ऐसी समस्या जिसकी वजह से एंड-टू-एंड प्रोटोकॉल पर हमले किए जा सकते हैं. इसमें ट्रांसपोर्ट लेयर सिक्योरिटी (TLS) और ब्लूटूथ (BT) पर होने वाले हमले भी शामिल हैं.
  • रिमोट सेवा की पुष्टि करने के लिए इस्तेमाल किए जाने वाले संवेदनशील क्रेडेंशियल का स्थानीय ऐक्सेस (उदाहरण के लिए, खाते के पासवर्ड या पासकोड वाले टोकन)
  • किसी खास कॉन्टेक्स्ट, बूटलोडर चेन, THB या ऑपरेटिंग सिस्टम के कर्नेल में, मनमुताबिक कोड को स्थानीय तौर पर चलाना
  • लोकल सेक्योर बूट को बायपास करना
  • लॉकस्क्रीन को बायपास करना
  • मुख्य डेवलपर, सुरक्षा या निजता सेटिंग के लिए, उपयोगकर्ता इंटरैक्शन की ज़रूरी शर्तों को स्थानीय तौर पर बायपास करना
  • पैकेज इंस्टॉल करने या उससे मिलते-जुलते व्यवहार के लिए, उपयोगकर्ता के इंटरैक्शन से जुड़ी ज़रूरी शर्तों को स्थानीय तौर पर बायपास करना
  • डिवाइस पर लगातार सेवा में रुकावट आना (स्थायी, पूरे ऑपरेटिंग सिस्टम को फिर से फ़्लैश करने या फ़ैक्ट्री रीसेट करने की ज़रूरत होती है)
  • सुरक्षित डेटा का रिमोट ऐक्सेस (यानी, ऐसा डेटा जो खास अनुमति वाले कॉन्टेक्स्ट तक सीमित है)
  • बिना अनुमति वाले कॉन्टेक्स्ट में, रिमोट से कोई भी कोड चलाना
  • उपयोगकर्ता के इंटरैक्शन के बिना, मोबाइल नेटवर्क या वाई-फ़ाई सेवा को ऐक्सेस करने से रोकना. उदाहरण के लिए, गलत पैकेट की मदद से मोबाइल रेडियो सेवा को क्रैश करना
  • उपयोगकर्ता इंटरैक्शन की ज़रूरी शर्तों को रिमोट से बायपास करना (ऐसे फ़ंक्शन या डेटा का ऐक्सेस जिसे ऐक्सेस करने के लिए, उपयोगकर्ता की अनुमति या कार्रवाई ज़रूरी हो)
  • आपातकालीन सेवाओं को ऐक्सेस करने से रोकना
  • अनुरोध करने वाले व्यक्ति को सुरक्षित तरीके से जानकारी भेजने के बजाय, संवेदनशील जानकारी को असुरक्षित नेटवर्क प्रोटोकॉल (उदाहरण के लिए, एचटीटीपी और एन्क्रिप्ट (सुरक्षित) नहीं किया गया ब्लूटूथ) पर भेजना. ध्यान दें कि यह वाई-फ़ाई एन्क्रिप्शन (जैसे, WEP) पर लागू नहीं होता
  • टीईई से सुरक्षित किए गए डेटा का बिना अनुमति वाला ऐक्सेस. इसमें, टीईई में कमज़ोर कुंजियों से चालू किया गया ऐक्सेस भी शामिल है
ठीक-ठाक
  • बेहतर सुरक्षा या एक्सप्लॉइट को कम करने वाली टेक्नोलॉजी के लिए, आम तौर पर इस्तेमाल होने वाला बाईपास
  • ऑपरेटिंग सिस्टम की सुरक्षा से जुड़ी उन सुविधाओं के लिए सामान्य बाईपास जो ऐप्लिकेशन, उपयोगकर्ता या प्रोफ़ाइल की सीमाओं के बीच प्रोसेस की स्थिति या मेटाडेटा को दिखाती हैं
  • वाई-फ़ाई एन्क्रिप्शन या पुष्टि करने की प्रोसेस को बायपास करना
  • स्टैंडर्ड क्रिप्टो प्राइमिटिव में क्रिप्टोग्राफ़िक से जुड़ी ऐसी कमजोरी जिसकी वजह से, टेक्स्ट को एन्क्रिप्ट किए बिना ही पढ़ा जा सकता है. यह कमजोरी, टीएलएस में इस्तेमाल किए जाने वाले प्राइमिटिव में नहीं होती
  • सुरक्षित डेटा का लोकल ऐक्सेस (यानी, ऐसा डेटा जो खास संदर्भ तक सीमित है)
  • बिना अनुमति वाले कॉन्टेक्स्ट में, स्थानीय कोड को मनमुताबिक चलाना
  • उपयोगकर्ता के इंटरैक्शन की ज़रूरी शर्तों को स्थानीय तौर पर बायपास करना (ऐसी सुविधा या डेटा का ऐक्सेस जिसे ऐक्सेस करने के लिए, आम तौर पर उपयोगकर्ता की अनुमति या कार्रवाई ज़रूरी होती है)
  • बिना सुरक्षा वाले डेटा को रिमोट से ऐक्सेस करना. इसका मतलब है कि वह डेटा जिसे आम तौर पर, स्थानीय तौर पर इंस्टॉल किए गए किसी भी ऐप्लिकेशन से ऐक्सेस किया जा सकता है
  • पाबंदी वाले कॉन्टेक्स्ट में, रिमोट से कोई भी कोड चलाना
  • डिवाइस को कुछ समय के लिए रिमोट से ऐक्सेस न कर पाना (रिमोट से डिवाइस हैंग होना या रीबूट होना)
कम
  • उपयोगकर्ता लेवल पर सुरक्षा के लिए, पूरी तरह से सुरक्षा देने वाली या कम अनुमतियों वाले कॉन्टेक्स्ट में, एक्सप्लॉइट को कम करने वाली टेक्नोलॉजी के लिए सामान्य बाईपास
  • सामान्य सुरक्षा लेवल की अनुमति को बायपास करना
  • स्टैंडर्ड के मुताबिक इस्तेमाल न करने पर, क्रिप्टोग्राफ़िक से जुड़ी जोखिम की आशंका
  • डिवाइस पर आपके हिसाब से काम करने वाली सुविधाओं को सामान्य तौर पर बायपास करना. जैसे, वॉइस मैच या फ़ेस मैच
  • गलत दस्तावेज़, जिसकी वजह से सुरक्षा से जुड़ी समस्या हो सकती है
  • पाबंदी वाले कॉन्टेक्स्ट में, स्थानीय तौर पर कोई भी कोड चलाने की अनुमति
  • सिस्टम से तय किया गया टेक्स्ट, जिसमें गुमराह करने वाला ब्यौरा शामिल हो और जिससे सुरक्षा के बारे में गलत जानकारी मिलती हो
सुरक्षा पर काफ़ी कम असर (एनएसआई​)
  • ऐसी सुरक्षा से जुड़ी समस्या जिसका असर, रेटिंग में बदलाव करने वाले एक या उससे ज़्यादा फ़ैक्टर या वर्शन के हिसाब से किए गए आर्किटेक्चर में बदलावों की वजह से कम हो गया है. इस वजह से, समस्या की गंभीरता कम हो गई है, हालांकि कोड से जुड़ी समस्या बनी रह सकती है
  • कोई भी ऐसी सुरक्षा से जुड़ी समस्या जिसके लिए गलत फ़ाइल सिस्टम की ज़रूरत होती है. हालांकि, अगर इस्तेमाल से पहले उस फ़ाइल सिस्टम को हमेशा अपनाया/एन्क्रिप्ट किया जाता है, तो यह समस्या नहीं होती.
  • डिवाइस पर कुछ समय के लिए सेवा उपलब्ध न कराना. जैसे, डिवाइस को रीबूट करने या ट्रिगर करने वाले ऐप्लिकेशन को अनइंस्टॉल करने पर, समस्या हल हो सकती है.

किराये में बदलाव करने वाले मॉडिफ़ायर

सुरक्षा से जुड़ी कमज़ोरियों की गंभीरता का पता लगाना आम तौर पर आसान होता है. हालांकि, परिस्थितियों के आधार पर रेटिंग बदल सकती हैं.

वजह प्रभाव
हमला करने के लिए, इसे खास सुविधाओं वाले कॉन्टेक्स्ट में चलाना ज़रूरी है. यह TEE, SE, और pKVM जैसे हाइपरवाइजर पर लागू नहीं होता -1 गंभीरता
जोखिम से जुड़ी जानकारी से, समस्या के असर को कम किया जा सकता है -1 गंभीरता
बायोमेट्रिक ऑथेंटिकेशन को बायपास करने की सुविधा, जिसके लिए डिवाइस के मालिक की बायोमेट्रिक जानकारी की ज़रूरत होती है -1 गंभीरता
कंपाइलर या प्लैटफ़ॉर्म कॉन्फ़िगरेशन, सोर्स कोड में मौजूद किसी जोखिम को कम करते हैं अगर मौजूदा जोखिम की गंभीरता मध्यम या उससे ज़्यादा है, तो गंभीरता मध्यम
इसके लिए, डिवाइस के अंदरूनी हिस्सों को फ़िज़िकल ऐक्सेस करना ज़रूरी है. डिवाइस के बंद होने या चालू होने के बाद से अनलॉक न होने पर भी, ऐसा किया जा सकता है -1 गंभीरता
डिवाइस के चालू होने और पहले से अनलॉक होने के दौरान, डिवाइस के अंदरूनी हिस्सों को ऐक्सेस करना ज़रूरी है -2 गंभीरता
स्थानीय हमला, जिसके लिए बूटलोडर चेन को अनलॉक करना ज़रूरी है कम से ज़्यादा 'कम'
स्थानीय हमला, जिसके लिए डिवाइस पर डेवलपर मोड या डेवलपर मोड की किसी भी सेटिंग को चालू करना ज़रूरी हो. साथ ही, यह हमला डेवलपर मोड में मौजूद किसी गड़बड़ी की वजह से न हो. कम से ज़्यादा 'कम'
अगर Google की दी गई SEPolicy के तहत, कोई भी SELinux डोमेन कार्रवाई नहीं कर सकता सुरक्षा पर काफ़ी कम असर

लोकल बनाम प्रोक्सिमल बनाम रिमोट

रिमोट अटैक वेक्टर से पता चलता है कि किसी ऐप्लिकेशन को इंस्टॉल किए बिना या डिवाइस का ऐक्सेस किए बिना, बग का इस्तेमाल किया जा सकता है. इसमें ऐसे बग शामिल हैं जो किसी वेब पेज को ब्राउज़ करने, ईमेल पढ़ने, एसएमएस मैसेज पाने या किसी खतरनाक नेटवर्क से कनेक्ट होने पर ट्रिगर हो सकते हैं.

प्रॉक्सिमल अटैक वेक्टर को रिमोट माना जाता है. इनमें ऐसे बग शामिल होते हैं जिनका फ़ायदा सिर्फ़ तब लिया जा सकता है, जब हमलावर टारगेट डिवाइस के आस-पास हो. उदाहरण के लिए, ऐसा बग जिसमें गलत वाई-फ़ाई या ब्लूटूथ पैकेट भेजने की ज़रूरत होती है. हम अल्ट्रा-वाइडबैंड (यूडब्ल्यूबी) और एनएफ़सी पर आधारित हमलों को प्रोक्सिमल मानते हैं. इसलिए, हम उन्हें रिमोट मानते हैं.

लोकल अटैक के लिए, हमलावर के पास पीड़ित के डिवाइस का ऐक्सेस होना ज़रूरी है. सिर्फ़ सॉफ़्टवेयर के उदाहरण के तौर पर, ऐसा तब हो सकता है, जब पीड़ित ने नुकसान पहुंचाने वाले किसी ऐप्लिकेशन को इंस्टॉल किया हो या इंस्टैंट ऐप्लिकेशन को चलाने की अनुमति दी हो.

जोड़े गए डिवाइसों (जैसे, ब्लूटूथ साथी डिवाइस) को लोकल डिवाइस माना जाता है. हम जोड़े गए डिवाइस और जोड़े जाने की प्रोसेस में शामिल डिवाइस के बीच अंतर करते हैं.

  • ऐसे गड़बड़ियां जिनकी वजह से उपयोगकर्ता, जोड़े जा रहे दूसरे डिवाइस की पहचान करने की सुविधा का इस्तेमाल नहीं कर पाता (जैसे, पुष्टि करना), उन्हें प्रोक्सिमल और इसलिए रिमोट माना जाता है.
  • जो गड़बड़ियां, जोड़ने के फ़्लो के दौरान होती हैं, लेकिन उपयोगकर्ता की सहमति (अर्थात अनुमति) से पहले होती हैं उन्हें प्रोक्सिमल और इसलिए रिमोट माना जाता है.
  • उपयोगकर्ता की सहमति मिलने के बाद होने वाली गड़बड़ियों को लोकल माना जाता है. भले ही, आखिर में डिवाइसों को जोड़ने की प्रोसेस पूरी न हो पाए.

हमले के फ़िज़िकल वेक्टर को स्थानीय माना जाता है. इनमें ऐसे बग शामिल होते हैं जिनका फ़ायदा सिर्फ़ वह व्यक्ति उठा सकता है जिसके पास डिवाइस का ऐक्सेस है. उदाहरण के लिए, स्क्रीन लॉक में मौजूद बग या ऐसा बग जिसे ठीक करने के लिए यूएसबी केबल को प्लग इन करना पड़ता है. आम तौर पर, डिवाइसों को यूएसबी से कनेक्ट करने के दौरान, डिवाइस अनलॉक रहता है. इसलिए, यूएसबी कनेक्शन की ज़रूरत वाले हमले उतने ही खतरनाक होते हैं, चाहे डिवाइस अनलॉक हो या नहीं.

नेटवर्क की सुरक्षा

Android यह मानता है कि सभी नेटवर्क खतरनाक हैं और वे ट्रैफ़िक पर हमला कर सकते हैं या उस पर नज़र रख सकते हैं. लिंक-लेयर की सुरक्षा (उदाहरण के लिए, वाई-फ़ाई एन्क्रिप्शन), किसी डिवाइस और उससे कनेक्ट किए गए ऐक्सेस पॉइंट के बीच के कम्यूनिकेशन को सुरक्षित रखती है. हालांकि, यह डिवाइस और उन सर्वर के बीच के चैनल में बचे हुए लिंक को सुरक्षित नहीं रखती जिनसे डिवाइस कम्यूनिकेट कर रहा है.

इसके उलट, एचटीटीपीएस आम तौर पर पूरे कम्यूनिकेशन को एंड-टू-एंड सुरक्षित करता है. इसके लिए, डेटा को सोर्स पर एन्क्रिप्ट (सुरक्षित) किया जाता है. इसके बाद, डेस्टिनेशन पर पहुंचने के बाद ही उसे डिक्रिप्ट (सुरक्षित से सामान्य में बदलना) किया जाता है और उसकी पुष्टि की जाती है. इस वजह से, लिंक-लेयर नेटवर्क की सुरक्षा को कमज़ोर करने वाली कमियों को, एचटीटीपीएस/TLS की कमियों के मुकाबले कम गंभीर माना जाता है: इंटरनेट पर ज़्यादातर कम्यूनिकेशन के लिए, सिर्फ़ वाई-फ़ाई एन्क्रिप्शन काफ़ी नहीं है.

बायोमेट्रिक ऑथेंटिकेशन

बायोमेट्रिक पुष्टि करना एक चुनौती भरा काम है. यहां तक कि सबसे अच्छे सिस्टम भी, मिलते-जुलते डेटा से गुमराह हो सकते हैं. ज़्यादा जानकारी के लिए, Android डेवलपर ब्लॉग: Android 11 में लॉकस्क्रीन और पुष्टि करने की सुविधा में हुए सुधार लेख पढ़ें. गंभीरता की इन रेटिंग से, हमले की दो क्लास के बीच अंतर किया जाता है. इनका मकसद, आखिरी उपयोगकर्ता के लिए असल जोखिम को दिखाना है.

पहले ग्रेड के हमलों से, बायोमेट्रिक ऑथेंटिकेशन की सुविधा को सामान्य तरीके से बायपास किया जा सकता है. इसके लिए, डिवाइस के मालिक का अच्छी क्वालिटी का बायोमेट्रिक डेटा होना ज़रूरी नहीं है. उदाहरण के लिए, अगर कोई हमलावर फ़िंगरप्रिंट सेंसर पर गोंद का एक टुकड़ा रखता है और सेंसर पर बचे अवशेषों के आधार पर डिवाइस का ऐक्सेस देता है, तो यह एक आसान हमला है. इसे किसी भी डिवाइस पर किया जा सकता है. इसके लिए, डिवाइस के मालिक की जानकारी की ज़रूरत नहीं होती. इस हमले को गंभीरता की पूरी रेटिंग दी जाती है, क्योंकि यह सभी डिवाइसों पर काम करता है और इससे बड़ी संख्या में उपयोगकर्ताओं पर असर पड़ सकता है. उदाहरण के लिए, लॉकस्क्रीन को बायपास करने के लिए, 'गंभीर' रेटिंग दी जाती है.

हमले की दूसरी कैटगरी में, आम तौर पर डिवाइस के मालिक के आधार पर, प्रज़ेंटेशन अटैक इंस्ट्रूमेंट (स्पूफ़) शामिल होता है. कभी-कभी यह बायोमेट्रिक जानकारी आसानी से मिल जाती है. उदाहरण के लिए, अगर किसी व्यक्ति की सोशल मीडिया प्रोफ़ाइल फ़ोटो, बायोमेट्रिक पुष्टि की सुविधा को धोखा देने के लिए काफ़ी है, तो बायोमेट्रिक बायपास को गंभीरता की सबसे ज़्यादा रेटिंग दी जाएगी. हालांकि, अगर किसी हमलावर को डिवाइस के मालिक से सीधे तौर पर बायोमेट्रिक डेटा हासिल करना पड़ता है, तो यह एक बड़ी समस्या है. इससे हमले का असर उन लोगों पर पड़ता है जो बायोमेट्रिक डेटा का इस्तेमाल करते हैं. इसलिए, इस मामले में -1 का मॉडिफ़ायर लागू होता है. उदाहरण के लिए, हमलावर को डिवाइस के मालिक के चेहरे का इन्फ़्रेरेड स्कैन हासिल करना पड़ता है.

SYSTEM_ALERT_WINDOW और टैपजैकिंग

SYSTEM_ALERT_WINDOW और टैपजैकिंग से जुड़ी हमारी नीतियों के बारे में जानकारी पाने के लिए, BugHunter University के सुरक्षा पर कोई असर न डालने वाले बग पेज पर, "सुरक्षा के लिहाज़ से अहम नहीं होने वाली स्क्रीन पर, टैपजैकिंग/ओवरले SYSTEM_ALERT_WINDOW की समस्या" सेक्शन देखें.

Android Automotive OS में एक से ज़्यादा उपयोगकर्ताओं के लिए सुरक्षा

Android Automotive OS, अन्य डिवाइसों के साइज़, डाइमेंशन या कॉन्फ़िगरेशन के मुकाबले, कई उपयोगकर्ताओं के लिए सुरक्षा वाला एक अलग मॉडल अपनाता है. Android खाते का इस्तेमाल, एक से ज़्यादा लोगों के लिए नहीं किया जा सकता. उदाहरण के लिए, किसी दोस्त को कुछ समय के लिए मेहमान उपयोगकर्ता के तौर पर असाइन किया जा सकता है, जो कार के मालिक से गाड़ी उधार लेता है. इस तरह के इस्तेमाल के उदाहरणों को ध्यान में रखते हुए, उपयोगकर्ताओं के पास डिफ़ॉल्ट रूप से, गाड़ी का इस्तेमाल करने के लिए ज़रूरी कॉम्पोनेंट का ऐक्सेस होता है. जैसे, वाई-फ़ाई और मोबाइल नेटवर्क की सेटिंग.

जिस कॉम्पोनेंट पर असर पड़ा है

गड़बड़ी को ठीक करने की ज़िम्मेदारी किस डेवलपमेंट टीम की है, यह इस बात पर निर्भर करता है कि गड़बड़ी किस कॉम्पोनेंट में है. यह Android प्लैटफ़ॉर्म का मुख्य कॉम्पोनेंट, ओरिजनल इक्विपमेंट मैन्युफ़ैक्चरर (OEM) से मिला कर्नेल ड्राइवर या Pixel डिवाइसों पर पहले से लोड किया गया कोई ऐप्लिकेशन हो सकता है.

AOSP कोड में मौजूद गड़बड़ियों को Android की इंजीनियरिंग टीम ठीक करती है. कम गंभीरता वाले बग, कुछ कॉम्पोनेंट में मौजूद बग या ऐसे बग जिन्हें पहले से ही सार्वजनिक तौर पर जाना जाता है, उन्हें सीधे तौर पर सार्वजनिक तौर पर उपलब्ध AOSP की मुख्य शाखा में ठीक किया जा सकता है. अगर ऐसा नहीं किया जाता है, तो उन्हें पहले हमारे इंटरनल रिपॉज़िटरी में ठीक किया जाता है.

इस कॉम्पोनेंट से यह भी तय होता है कि उपयोगकर्ताओं को अपडेट कैसे मिलेंगे. फ़्रेमवर्क या कर्नेल में मौजूद गड़बड़ी को ठीक करने के लिए, ओवर-द-एयर (ओटीए) फ़र्मवेयर अपडेट की ज़रूरत होती है. इसे हर OEM को पॉइंट करना होता है. Google Play पर पब्लिश किए गए किसी ऐप्लिकेशन या लाइब्रेरी (उदाहरण के लिए, Gmail, Google Play services या वेबव्यू) में मौजूद बग को, Android उपयोगकर्ताओं को Google Play से अपडेट के तौर पर भेजा जा सकता है.

पार्टनर को सूचना देना

जब Android सुरक्षा बुलेटिन में AOSP की सुरक्षा से जुड़ी किसी समस्या को ठीक कर दिया जाता है, तो हम Android पार्टनर को समस्या की जानकारी देंगे और उन्हें पैच उपलब्ध कराएंगे. बैकपोर्ट की सुविधा वाले वर्शन की सूची, Android के हर नए वर्शन के साथ बदलती रहती है. जिन डिवाइसों पर इसका इस्तेमाल किया जा सकता है उनकी सूची पाने के लिए, डिवाइस बनाने वाली कंपनी से संपर्क करें.

AOSP में कोड रिलीज़ करना

अगर सुरक्षा से जुड़ा बग AOSP कॉम्पोनेंट में है, तो उपयोगकर्ताओं के लिए ओटीए रिलीज़ होने के बाद, उसे ठीक कर दिया जाता है. कम गंभीर समस्याओं को ठीक करने के लिए, सीधे AOSP के मुख्य ब्रैंच में सुधार सबमिट किए जा सकते हैं. ऐसा, डिवाइसों पर ओटीए के ज़रिए सुधार उपलब्ध होने से पहले किया जा सकता है.

Android के अपडेट पाना

आम तौर पर, Android सिस्टम के अपडेट, डिवाइसों पर ओटीए अपडेट पैकेज के ज़रिए डिलीवर किए जाते हैं. ये अपडेट, डिवाइस बनाने वाली ओईएम कंपनी या डिवाइस के लिए सेवा देने वाली मोबाइल और इंटरनेट सेवा देने वाली कंपनी से मिल सकते हैं. Google Pixel डिवाइस के अपडेट, Google Pixel टीम से मिलते हैं. ये अपडेट, मोबाइल और इंटरनेट सेवा देने वाली कंपनी की तकनीकी तौर पर मंज़ूरी (टीए) की जांच की प्रक्रिया से गुज़रने के बाद मिलते हैं. Google, Pixel फ़ैक्ट्री इमेज भी पब्लिश करता है. इन्हें डिवाइसों पर साइड-लोड किया जा सकता है.

Google की सेवाएं अपडेट करना

Android की सुरक्षा टीम, सुरक्षा से जुड़े बग के लिए पैच उपलब्ध कराने के साथ-साथ, सुरक्षा से जुड़े बग की समीक्षा भी करती है. इससे यह पता चलता है कि उपयोगकर्ताओं को सुरक्षित रखने के लिए, और क्या-क्या किया जा सकता है. उदाहरण के लिए, Google Play सभी ऐप्लिकेशन को स्कैन करता है और सुरक्षा से जुड़े किसी भी बग का फ़ायदा उठाने वाले ऐप्लिकेशन को हटा देता है. Google Play से बाहर के ऐप्लिकेशन इंस्टॉल करने पर, Google Play Services वाले डिवाइसों पर ऐप्लिकेशन की पुष्टि करें सुविधा का इस्तेमाल भी किया जा सकता है. इससे, उपयोगकर्ताओं को ऐसे ऐप्लिकेशन के बारे में चेतावनी दी जा सकती है जो नुकसान पहुंचा सकते हैं.

अन्य संसाधन

Android ऐप्लिकेशन डेवलपर के लिए जानकारी: https://developer.android.com

सुरक्षा से जुड़ी जानकारी, Android Open Source और Developer साइटों पर मौजूद होती है. शुरू करने के लिए ये जगहें अच्छी हैं:

रिपोर्ट

कभी-कभी, Android की सुरक्षा टीम रिपोर्ट या व्हाइटपेपर पब्लिश करती है. ज़्यादा जानकारी के लिए, सुरक्षा रिपोर्ट देखें.