ทีมรักษาความปลอดภัยของ Android มีหน้าที่จัดการช่องโหว่ด้านความปลอดภัยที่ค้นพบในแพลตฟอร์ม Android และแอปหลักของ Android ที่มาพร้อมกับอุปกรณ์ Android
ทีมรักษาความปลอดภัยของ Android พบช่องโหว่ด้านความปลอดภัยผ่านการวิจัยภายในและตอบสนองต่อข้อบกพร่องที่รายงานโดยบุคคลที่สาม แหล่งที่มาของบั๊กภายนอกรวมถึงปัญหาที่รายงานผ่าน แบบฟอร์มช่องโหว่ งานวิจัยทางวิชาการที่เผยแพร่และเผยแพร่ล่วงหน้า ผู้ดูแลโครงการโอเพนซอร์สอัปสตรีม การแจ้งเตือนจากพันธมิตรผู้ผลิตอุปกรณ์ของเรา และปัญหาที่เปิดเผยต่อสาธารณะที่โพสต์บนบล็อกหรือโซเชียลมีเดีย
การรายงานปัญหาด้านความปลอดภัย
นักพัฒนาซอฟต์แวร์ ผู้ใช้ Android หรือนักวิจัยด้านความปลอดภัยสามารถแจ้งทีมรักษาความปลอดภัยของ Android เกี่ยวกับปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นผ่าน แบบฟอร์มช่องโหว่
ข้อบกพร่องที่ทำเครื่องหมายว่าเป็นปัญหาด้านความปลอดภัยจะไม่ปรากฏให้เห็นจากภายนอก แต่ในที่สุดอาจทำให้มองเห็นได้หลังจากปัญหาได้รับการประเมินหรือแก้ไข หากคุณวางแผนที่จะส่งแพตช์หรือการทดสอบ Compatibility Test Suite (CTS) เพื่อแก้ไขปัญหาด้านความปลอดภัย โปรดแนบแพตช์ดังกล่าวกับรายงานจุดบกพร่องและรอการตอบกลับก่อนที่จะอัปโหลดโค้ดไปยัง AOSP
ข้อผิดพลาดในการทดสอบ
ภารกิจแรกในการจัดการช่องโหว่ด้านความปลอดภัยคือการระบุความรุนแรงของข้อบกพร่องและส่วนประกอบของ Android ที่ได้รับผลกระทบ ความรุนแรงจะกำหนดวิธีการจัดลำดับความสำคัญของปัญหา และคอมโพเนนต์จะกำหนดว่าใครแก้ไขข้อบกพร่อง ใครได้รับแจ้ง และจะนำการแก้ไขไปใช้กับผู้ใช้อย่างไร
ประเภทบริบท
ตารางนี้ครอบคลุมคำจำกัดความของบริบทความปลอดภัยของฮาร์ดแวร์และซอฟต์แวร์ บริบทสามารถกำหนดได้โดยความละเอียดอ่อนของข้อมูลที่ประมวลผลโดยทั่วไปหรือพื้นที่ที่เรียกใช้ บริบทความปลอดภัยบางอย่างอาจไม่สามารถใช้ได้กับทุกระบบ ตารางนี้เรียงลำดับจากสิทธิพิเศษน้อยไปมาก
ประเภทบริบท | คำจำกัดความของประเภท |
---|---|
บริบทที่จำกัด | สภาพแวดล้อมการดำเนินการแบบจำกัดที่มีการให้สิทธิ์น้อยที่สุดเท่านั้น ตัวอย่างเช่น แอปพลิเคชันที่เชื่อถือได้ประมวลผลข้อมูลที่ไม่น่าเชื่อถือภายในสภาพแวดล้อมแบบแซนด์บ็อกซ์ |
บริบทที่ไม่มีสิทธิพิเศษ | สภาพแวดล้อมการดำเนินการทั่วไปที่คาดหวังโดยรหัสที่ไม่มีสิทธิพิเศษ ตัวอย่างเช่น แอปพลิเคชัน Android ที่ทำงานในโดเมน SELinux ที่มีแอตทริบิวต์ untrusted_app_all |
บริบทที่ได้รับสิทธิพิเศษ | สภาพแวดล้อมการดำเนินการที่มีสิทธิพิเศษซึ่งอาจมีการเข้าถึงการอนุญาตขั้นสูง จัดการ PII ของผู้ใช้หลายคน และ/หรือรักษาความสมบูรณ์ของระบบ ตัวอย่างเช่น แอปพลิเคชัน Android ที่มีความสามารถซึ่งถูกห้ามโดยโดเมน SELinux untrusted_app หรือมีสิทธิ์เข้าถึงสิทธิ privileged|signature |
เคอร์เนลระบบปฏิบัติการ | ฟังก์ชั่นที่:
|
ฐานฮาร์ดแวร์ที่เชื่อถือได้ (บาท) | ส่วนประกอบฮาร์ดแวร์แบบแยก ซึ่งโดยทั่วไปอยู่บน SoC ซึ่งมีฟังก์ชันที่สำคัญต่อกรณีการใช้งานหลักของอุปกรณ์ (เช่น เซลลูลาร์เบสแบนด์, DSP, GPU และโปรเซสเซอร์ ML) |
ห่วงโซ่ Bootloader | คอมโพเนนต์ที่กำหนดค่าอุปกรณ์เมื่อบู๊ตแล้วส่งการควบคุมไปยังระบบปฏิบัติการ Android |
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) | คอมโพเนนต์ที่ได้รับการออกแบบให้ได้รับการปกป้องจากแม้แต่ OS Kernel ที่ไม่เป็นมิตร (เช่น TrustZone และไฮเปอร์ไวเซอร์ เช่น pKVM ซึ่งปกป้อง Virtual Machines จาก OS Kernel) |
Secure Enclave / องค์ประกอบที่ปลอดภัย (SE) | ส่วนประกอบฮาร์ดแวร์ทางเลือกที่ออกแบบมาให้ได้รับการปกป้องจากส่วนประกอบอื่นๆ ทั้งหมดบนอุปกรณ์และจากการโจมตีทางกายภาพ ตามที่กำหนดไว้ใน Introduction to Secure Elements ซึ่งรวมถึงชิป Titan-M ที่มีอยู่ในอุปกรณ์ Android บางรุ่น |
ความรุนแรง
โดยทั่วไป ความรุนแรงของข้อบกพร่องจะสะท้อนถึงอันตรายที่อาจเกิดขึ้นหากใช้ประโยชน์จากข้อบกพร่องได้สำเร็จ ใช้เกณฑ์ต่อไปนี้เพื่อกำหนดความรุนแรง
คะแนน | ผลที่ตามมาของการแสวงหาผลประโยชน์ที่ประสบความสำเร็จ |
---|---|
วิกฤต |
|
สูง |
|
ปานกลาง |
|
ต่ำ |
|
ผลกระทบด้านความปลอดภัยเล็กน้อย (NSI) |
|
ตัวแก้ไขการให้คะแนน
แม้ว่าความรุนแรงของช่องโหว่ด้านความปลอดภัยมักจะระบุได้ง่าย แต่การให้คะแนนอาจเปลี่ยนแปลงตามสถานการณ์
เหตุผล | ผล |
---|---|
ต้องเรียกใช้เป็นบริบทที่มีสิทธิพิเศษเพื่อดำเนินการโจมตี (ไม่สามารถใช้ได้กับ TEE, SE และไฮเปอร์ไวเซอร์ เช่น pKVM) | -1 ความรุนแรง |
รายละเอียดเฉพาะช่องโหว่จะจำกัดผลกระทบของปัญหา | -1 ความรุนแรง |
บายพาสการรับรองความถูกต้องทางชีวภาพที่ต้องการข้อมูลไบโอเมตริกซ์โดยตรงจากเจ้าของอุปกรณ์ | -1 ความรุนแรง |
การกำหนดค่าคอมไพเลอร์หรือแพลตฟอร์มช่วยลดช่องโหว่ในซอร์สโค้ด | ความรุนแรงปานกลาง หากช่องโหว่พื้นฐานอยู่ในระดับปานกลางหรือสูงกว่า |
ต้องมีการเข้าถึงทางกายภาพเพื่อเข้าถึงอุปกรณ์ภายใน และยังทำได้หากอุปกรณ์ปิดอยู่หรือไม่ได้ปลดล็อกตั้งแต่เปิดเครื่อง | -1 ความรุนแรง |
ต้องมีการเข้าถึงทางกายภาพกับอุปกรณ์ภายในในขณะที่เปิดอุปกรณ์และปลดล็อคก่อนหน้านี้ | -2 ความรุนแรง |
การโจมตีแบบโลคัลที่ต้องการปลดล็อค bootloader chain | ไม่สูงกว่าต่ำ |
การโจมตีในเครื่องที่ต้องใช้โหมดนักพัฒนาซอฟต์แวร์หรือการตั้งค่าโหมดนักพัฒนาถาวรใดๆ ที่ต้องเปิดใช้งานบนอุปกรณ์ในปัจจุบัน (และไม่ใช่ข้อบกพร่องในโหมดนักพัฒนาซอฟต์แวร์เอง) | ไม่สูงกว่าต่ำ |
หากไม่มีโดเมน SELinux สามารถดำเนินการภายใต้ SEPolicy ที่ Google จัดเตรียมไว้ให้ได้ | ผลกระทบด้านความปลอดภัยเล็กน้อย |
Local กับ Proximal กับ Remote
เวกเตอร์การโจมตีจากระยะไกลบ่งชี้ว่าบั๊กสามารถถูกโจมตีได้โดยไม่ต้องติดตั้งแอพหรือไม่มีการเข้าถึงอุปกรณ์ ซึ่งรวมถึงข้อบกพร่องที่สามารถเรียกใช้ได้จากการเรียกดูหน้าเว็บ อ่านอีเมล รับข้อความ SMS หรือการเชื่อมต่อกับเครือข่ายที่ไม่เป็นมิตร สำหรับจุดประสงค์ของการให้คะแนนความรุนแรง เรายังถือว่าเวกเตอร์การโจมตี "ใกล้เคียง" เป็นระยะไกลอีกด้วย ซึ่งรวมถึงข้อบกพร่องที่สามารถใช้ประโยชน์ได้โดยผู้โจมตีที่อยู่ใกล้อุปกรณ์เป้าหมายเท่านั้น ตัวอย่างเช่น ข้อบกพร่องที่ต้องส่งแพ็กเก็ต Wi-Fi หรือบลูทูธที่มีรูปแบบไม่ถูกต้อง เราถือว่าการโจมตีแบบอัลตร้าไวด์แบนด์ (UWB) และ NFC เป็นการโจมตีแบบใกล้เคียง ดังนั้นจึงเป็นระยะไกล
การโจมตีในพื้นที่ต้องการให้เหยื่อเรียกใช้แอป ไม่ว่าจะโดยการติดตั้งและเรียกใช้แอป หรือโดยการยินยอมให้เรียกใช้ Instant App อุปกรณ์คู่หูที่จับคู่จะถือเป็นอุปกรณ์ในเครื่อง สำหรับวัตถุประสงค์ในการให้คะแนนความรุนแรง ทีมรักษาความปลอดภัยของ Android ยังถือว่าเวกเตอร์การโจมตีทางกายภาพเป็นแบบเฉพาะที่ ซึ่งรวมถึงข้อบกพร่องที่สามารถใช้ประโยชน์ได้โดยผู้โจมตีที่สามารถเข้าถึงอุปกรณ์ได้เท่านั้น เช่น ข้อบกพร่องในหน้าจอล็อกหรือที่ต้องเสียบสาย USB
ความปลอดภัยของเครือข่าย
Android ถือว่าเครือข่ายทั้งหมดเป็นศัตรูกันและอาจทำการโจมตีหรือสอดแนมการรับส่งข้อมูล แม้ว่าการรักษาความปลอดภัยระดับลิงก์ (เช่น การเข้ารหัส Wi-Fi) จะรักษาความปลอดภัยในการสื่อสารระหว่างอุปกรณ์กับจุดเข้าใช้งานที่เชื่อมต่ออยู่ แต่ก็ไม่ได้ทำอะไรเพื่อรักษาความปลอดภัยลิงก์ที่เหลือในห่วงโซ่ระหว่างอุปกรณ์และเซิร์ฟเวอร์ที่สื่อสารด้วย
ในทางตรงกันข้าม HTTPS มักจะปกป้องการสื่อสารทั้งหมดตั้งแต่ต้นทางจนถึงปลายทาง โดยเข้ารหัสข้อมูลที่ต้นทาง จากนั้นจะถอดรหัสและตรวจสอบข้อมูลเมื่อถึงปลายทางสุดท้ายเท่านั้น ด้วยเหตุนี้ ช่องโหว่ที่ส่งผลต่อความปลอดภัยของเครือข่ายลิงค์เลเยอร์จึงได้รับการจัดอันดับว่ามีความรุนแรงน้อยกว่าช่องโหว่ใน HTTPS/TLS: การเข้ารหัส Wi-Fi เพียงอย่างเดียวไม่เพียงพอสำหรับการสื่อสารส่วนใหญ่บนอินเทอร์เน็ต
การรับรองความถูกต้องทางชีวภาพ
การรับรองความถูกต้องด้วยไบโอเมตริกเป็นพื้นที่ที่ท้าทาย และแม้แต่ระบบที่ดีที่สุดก็อาจถูกหลอกได้เมื่อเกือบตรงกัน (ดู บล็อกนักพัฒนาซอฟต์แวร์ Android: การปรับปรุงหน้าจอล็อกและการรับรองความถูกต้องใน Android 11 ) การจัดอันดับความรุนแรงเหล่านี้แยกแยะระหว่างการโจมตี 2 ประเภท และมีวัตถุประสงค์เพื่อสะท้อนถึงความเสี่ยงที่แท้จริงต่อผู้ใช้ปลายทาง
การโจมตีระดับเฟิร์สคลาสช่วยให้สามารถข้ามการพิสูจน์ตัวตนด้วยไบโอเมตริกในลักษณะทั่วไปได้ โดยไม่ต้องอาศัยข้อมูลไบโอเมตริกคุณภาพสูงจากเจ้าของ ตัวอย่างเช่น หากผู้โจมตีสามารถวางหมากฝรั่งลงบนเซ็นเซอร์ลายนิ้วมือ และอนุญาตให้เข้าถึงอุปกรณ์โดยพิจารณาจากสิ่งที่เหลืออยู่บนเซ็นเซอร์ นั่นเป็นการโจมตีง่ายๆ ที่สามารถดำเนินการกับอุปกรณ์ที่อ่อนแอได้ ไม่ต้องการความรู้ใด ๆ จากเจ้าของอุปกรณ์ เนื่องจากการโจมตีนี้ทำให้เป็นแบบทั่วไปได้และอาจส่งผลกระทบต่อผู้ใช้จำนวนมากขึ้น การโจมตีนี้จึงได้รับคะแนนความรุนแรงเต็ม (เช่น สูง สำหรับการบายพาสหน้าจอล็อก)
การโจมตีประเภทอื่นมักเกี่ยวข้องกับเครื่องมือโจมตีการนำเสนอ (การปลอมแปลง) ตามเจ้าของอุปกรณ์ บางครั้งข้อมูลไบโอเมตริกนี้ค่อนข้างง่ายที่จะได้รับ (เช่น หากรูปโปรไฟล์ของใครบางคนบนโซเชียลมีเดียเพียงพอต่อการหลอกใช้ไบโอเมตริกแล้ว การบายพาสไบโอเมตริกจะได้รับคะแนนความรุนแรงเต็มจำนวน) แต่ถ้าผู้โจมตีจำเป็นต้องได้รับข้อมูลไบโอเมตริกซ์โดยตรงจากเจ้าของอุปกรณ์ (เช่น การสแกนใบหน้าด้วยอินฟราเรด) นั่นเป็นอุปสรรคสำคัญเพียงพอที่จะจำกัดจำนวนผู้ที่ได้รับผลกระทบจากการโจมตี ดังนั้นจึงมีตัวแก้ไข -1 .
SYSTEM_ALERT_WINDOW
และ Tapjacking
สำหรับข้อมูลเกี่ยวกับนโยบายของเราเกี่ยวกับ SYSTEM_ALERT_WINDOW
และการเจาะระบบ โปรดดูส่วน " การเจาะระบบแบบแท็ป/โอเวอร์เลย์ ช่องโหว่ SYSTEM_ALERT_WINDOW บนหน้าจอที่ไม่สำคัญต่อความปลอดภัย " ในหน้า ข้อบกพร่องของ BugHunter University ที่ไม่มีผลกระทบด้านความปลอดภัย
การรักษาความปลอดภัยสำหรับผู้ใช้หลายคนใน Android Automotive OS
Android Automotive OS ใช้รูปแบบการรักษาความปลอดภัยแบบผู้ใช้หลายคนซึ่งแตกต่างจากฟอร์มแฟกเตอร์อื่นๆ ผู้ใช้ Android แต่ละคนมีวัตถุประสงค์เพื่อใช้โดยบุคคลที่แตกต่างกัน ตัวอย่างเช่น สามารถกำหนดผู้ใช้ชั่วคราวให้กับเพื่อนที่ยืมรถจากเจ้าของรถได้ เพื่อรองรับกรณีการใช้งานเช่นนี้ โดยค่าเริ่มต้น ผู้ใช้จะสามารถเข้าถึงส่วนประกอบที่จำเป็นในการใช้รถ เช่น Wi-Fi และการตั้งค่าเครือข่ายเซลลูลาร์
ส่วนประกอบที่ได้รับผลกระทบ
ทีมพัฒนาที่รับผิดชอบในการแก้ไขข้อบกพร่องนั้นขึ้นอยู่กับส่วนประกอบที่ข้อบกพร่องนั้นอยู่ อาจเป็นองค์ประกอบหลักของแพลตฟอร์ม Android ไดรเวอร์เคอร์เนลที่จัดทำโดยผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) หรือหนึ่งในแอปที่โหลดไว้ล่วงหน้าบนอุปกรณ์ Pixel .
ข้อบกพร่องในโค้ด AOSP ได้รับการแก้ไขโดยทีมวิศวกรของ Android ข้อบกพร่องที่มีความรุนแรงต่ำ ข้อบกพร่องในส่วนประกอบบางอย่าง หรือข้อบกพร่องที่ทราบโดยสาธารณะอยู่แล้วอาจได้รับการแก้ไขโดยตรงในสาขาหลัก AOSP ที่เผยแพร่ต่อสาธารณะ มิฉะนั้นจะได้รับการแก้ไขในที่เก็บข้อมูลภายในของเราก่อน
คอมโพเนนต์นี้ยังเป็นปัจจัยในการที่ผู้ใช้จะได้รับการอัปเดต จุดบกพร่องในเฟรมเวิร์กหรือเคอร์เนลจำเป็นต้องมีการอัปเดตเฟิร์มแวร์แบบ over-the-air (OTA) ซึ่ง OEM แต่ละรายจำเป็นต้องพุช จุดบกพร่องในแอปหรือไลบรารีที่เผยแพร่ใน Google Play (เช่น Gmail, Google Play Services หรือ WebView) สามารถส่งไปยังผู้ใช้ Android เป็นการอัปเดตจาก Google Play
แจ้งคู่ค้า
เมื่อช่องโหว่ด้านความปลอดภัยใน AOSP ได้รับการแก้ไขใน Android Security Bulletin เราจะแจ้งให้พาร์ทเนอร์ Android ทราบถึงรายละเอียดของปัญหาและจัดเตรียมแพตช์ รายการเวอร์ชันที่รองรับ backport จะเปลี่ยนไปตาม Android รุ่นใหม่แต่ละรุ่น ติดต่อผู้ผลิตอุปกรณ์ของคุณสำหรับรายการอุปกรณ์ที่รองรับ
ปล่อยรหัสไปยัง AOSP
หากจุดบกพร่องด้านความปลอดภัยอยู่ในคอมโพเนนต์ AOSP การแก้ไขจะถูกส่งไปยัง AOSP หลังจากปล่อย OTA ให้กับผู้ใช้ การแก้ไขสำหรับปัญหาที่มีความรุนแรงต่ำอาจถูกส่งโดยตรงไปยังสาขาหลัก AOSP ก่อนที่การแก้ไขจะพร้อมใช้งานสำหรับอุปกรณ์ผ่าน OTA
รับการอัปเดต Android
โดยทั่วไปการอัปเดตระบบ Android จะถูกส่งไปยังอุปกรณ์ผ่านแพ็คเกจการอัปเดต OTA การอัปเดตเหล่านี้อาจมาจาก OEM ที่ผลิตอุปกรณ์หรือผู้ให้บริการที่ให้บริการอุปกรณ์ การอัปเดตอุปกรณ์ Google Pixel มาจากทีม Google Pixel หลังจากผ่านขั้นตอนการทดสอบการยอมรับทางเทคนิค (TA) ของผู้ให้บริการ Google ยังเผยแพร่ ภาพโรงงาน Pixel ที่สามารถโหลดด้านข้างไปยังอุปกรณ์ได้
การอัปเดตบริการของ Google
นอกเหนือจากการให้แพตช์สำหรับข้อบกพร่องด้านความปลอดภัยแล้ว ทีมความปลอดภัยของ Android จะตรวจสอบข้อบกพร่องด้านความปลอดภัยเพื่อพิจารณาว่ามีวิธีอื่นในการปกป้องผู้ใช้หรือไม่ ตัวอย่างเช่น Google Play จะสแกนแอปทั้งหมดและลบแอปใดๆ ที่พยายามใช้ประโยชน์จากข้อบกพร่องด้านความปลอดภัย สำหรับแอปที่ติดตั้งจากภายนอก Google Play อุปกรณ์ที่มีบริการ Google Play อาจใช้คุณลักษณะ ยืนยันแอป เพื่อเตือนผู้ใช้เกี่ยวกับแอปที่อาจเป็นอันตราย
แหล่งข้อมูลอื่นๆ
ข้อมูลสำหรับนักพัฒนาแอป Android: https://developer.android.com
ข้อมูลความปลอดภัยมีอยู่ในไซต์ Android Open Source และ Developer จุดเริ่มต้นที่ดี:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
รายงาน
บางครั้งทีมรักษาความปลอดภัยของ Android จะเผยแพร่รายงานหรือเอกสารรายงาน ดู รายงานความปลอดภัย สำหรับรายละเอียดเพิ่มเติม