ทีมรักษาความปลอดภัยของ Android มีหน้าที่จัดการช่องโหว่ด้านความปลอดภัยที่พบในแพลตฟอร์ม Android และแอปหลักๆ ของ Android หลายแอปที่มาพร้อมกับอุปกรณ์ Android
ทีมรักษาความปลอดภัยของ Android จะตรวจหาช่องโหว่ด้านความปลอดภัยผ่านการวิจัยภายในและยังตอบสนองต่อข้อบกพร่องที่บุคคลที่สามรายงานเข้ามาด้วย แหล่งที่มาของข้อบกพร่องภายนอก ได้แก่ ปัญหาที่รายงานผ่านแบบฟอร์มช่องโหว่ งานวิจัยทางวิชาการที่เผยแพร่แล้วและที่เผยแพร่ก่อนการเผยแพร่ ผู้ดูแลโครงการโอเพนซอร์สที่เป็นแหล่งที่มา การแจ้งเตือนจากพาร์ทเนอร์ผู้ผลิตอุปกรณ์ และปัญหาที่เปิดเผยต่อสาธารณะซึ่งโพสต์ในบล็อกหรือโซเชียลมีเดีย
รายงานปัญหาด้านความปลอดภัย
นักพัฒนาแอป ผู้ใช้ Android หรือนักวิจัยด้านความปลอดภัยสามารถแจ้งทีมรักษาความปลอดภัยของ Android เกี่ยวกับปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นได้ผ่านแบบฟอร์มช่องโหว่
ข้อบกพร่องที่มีการทำเครื่องหมายว่าเป็นปัญหาด้านความปลอดภัยจะไม่ปรากฏภายนอก แต่อาจปรากฏขึ้นหลังจากประเมินหรือแก้ไขปัญหาแล้ว หากวางแผนที่จะส่งการแก้ไขหรือชุดเครื่องมือทดสอบความเข้ากันได้ (CTS) เพื่อแก้ไขปัญหาด้านความปลอดภัย โปรดแนบไฟล์มากับรายงานข้อบกพร่องและรอการตอบกลับก่อนที่จะอัปโหลดโค้ดไปยัง AOSP
คัดแยกข้อบกพร่อง
งานแรกในการจัดการช่องโหว่ด้านความปลอดภัยคือการระบุความรุนแรงของข้อบกพร่องและคอมโพเนนต์ของ Android ที่ได้รับผลกระทบ ความรุนแรงจะเป็นตัวกำหนดลำดับความสำคัญของปัญหา ส่วนคอมโพเนนต์จะเป็นตัวกำหนดว่าใครจะแก้ไขข้อบกพร่อง ใครจะได้รับแจ้ง และวิธีนำการแก้ไขไปใช้งานกับผู้ใช้
ประเภทบริบท
ตารางนี้ครอบคลุมคำจำกัดความของบริบทความปลอดภัยของฮาร์ดแวร์และซอฟต์แวร์ บริบทอาจกำหนดโดยความละเอียดอ่อนของข้อมูลที่ประมวลผลตามปกติหรือพื้นที่ที่ทำงาน บริบทความปลอดภัยบางรายการใช้ไม่ได้กับบางระบบ ตารางนี้จัดเรียงจากสิทธิ์น้อยที่สุดไปจนถึงมากที่สุด
ประเภทบริบท | คําจํากัดความของประเภท |
---|---|
บริบทที่มีข้อจำกัด |
สภาพแวดล้อมการเรียกใช้แบบจํากัดที่มีสิทธิ์เพียงน้อยนิด ตัวอย่างเช่น แอปที่เชื่อถือได้ซึ่งประมวลผลข้อมูลที่ไม่น่าเชื่อถือภายในสภาพแวดล้อมที่ใช้แซนด์บ็อกซ์ |
บริบทที่ไม่มีสิทธิ์ |
สภาพแวดล้อมการเรียกใช้ทั่วไปที่โค้ดที่ไม่มีสิทธิ์คาดหวัง ตัวอย่างเช่น แอป Android ที่ทำงานในโดเมน SELinux ด้วยแอตทริบิวต์ untrusted_app_all
|
บริบทที่มีสิทธิ์ |
สภาพแวดล้อมการเรียกใช้ที่มีสิทธิ์ซึ่งอาจมีสิทธิ์เข้าถึงระดับที่สูงขึ้น จัดการ PII ของผู้ใช้หลายคน และ/หรือรักษาความสมบูรณ์ของระบบ ตัวอย่างเช่น แอป Android ที่มีความสามารถที่โดเมน SELinux untrusted_app จะห้ามไว้ หรือมีสิทธิ์เข้าถึงprivileged|signature
|
เคอร์เนลของระบบปฏิบัติการ |
ฟังก์ชันการทำงานที่มีลักษณะดังนี้
|
ฐานฮาร์ดแวร์ที่เชื่อถือได้ (THB) | คอมโพเนนต์ฮาร์ดแวร์แบบแยกส่วน ซึ่งโดยทั่วไปอยู่ใน SoC ที่ให้ฟังก์ชันการทำงานที่สำคัญต่อกรณีการใช้งานหลักของอุปกรณ์ (เช่น แบนด์ฐานเครือข่ายมือถือ, DSP, GPU และโปรเซสเซอร์ ML) |
Bootloader Chain | คอมโพเนนต์ที่กำหนดค่าอุปกรณ์เมื่อบูต จากนั้นส่งการควบคุมไปยังระบบปฏิบัติการ Android |
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) | คอมโพเนนต์ที่ออกแบบมาเพื่อปกป้องแม้กระทั่งเคอร์เนลระบบปฏิบัติการที่เป็นอันตราย (เช่น TrustZone และไฮเปอร์วิซอร์ เช่น pKVM ซึ่งปกป้องเครื่องเสมือนจากเคอร์เนลระบบปฏิบัติการ) |
Secure Enclave / องค์ประกอบความปลอดภัย (SE) |
คอมโพเนนต์ฮาร์ดแวร์ที่ไม่บังคับซึ่งออกแบบมาเพื่อปกป้องจากคอมโพเนนต์อื่นๆ ทั้งหมดในอุปกรณ์และจากการโจมตีทางกายภาพตามที่ระบุไว้ในข้อมูลเบื้องต้นเกี่ยวกับองค์ประกอบที่ปลอดภัย ชิปนี้รวมถึงชิป Titan-M ที่มีอยู่ในอุปกรณ์ Android บางรุ่น |
ความรุนแรง
โดยทั่วไปแล้ว ความรุนแรงของข้อบกพร่องจะแสดงถึงอันตรายที่อาจเกิดขึ้นหากมีการใช้ประโยชน์จากข้อบกพร่องได้ ใช้เกณฑ์ต่อไปนี้เพื่อพิจารณาความรุนแรง
Rating | ผลที่ตามมาของการประพฤติมิชอบที่สำเร็จ |
---|---|
สำคัญมาก |
|
สูง |
|
ปานกลาง |
|
ต่ำ |
|
ผลกระทบด้านความปลอดภัยเล็กน้อย (NSI) |
|
ตัวปรับราคา
แม้ว่าความรุนแรงของช่องโหว่ด้านความปลอดภัยมักจะระบุได้ง่าย แต่การจัดประเภทอาจเปลี่ยนแปลงได้ ทั้งนี้ขึ้นอยู่กับสถานการณ์
เหตุผล | เอฟเฟ็กต์ |
---|---|
ต้องทำงานในบริบทที่มีสิทธิ์เพื่อทำการโจมตี (ใช้ไม่ได้กับ TEE, SE และไฮเปอร์วิซอร์ เช่น pKVM) | ความรุนแรง -1 |
รายละเอียดเฉพาะของช่องโหว่จะจำกัดผลกระทบของปัญหา | ความรุนแรง -1 |
การข้ามการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกที่ต้องใช้ข้อมูลไบโอเมตริกจากเจ้าของอุปกรณ์โดยตรง | ความรุนแรง -1 |
การกําหนดค่าคอมไพเลอร์หรือแพลตฟอร์มช่วยลดช่องโหว่ในซอร์สโค้ด | ความรุนแรงปานกลางหากช่องโหว่พื้นฐานมีความรุนแรงปานกลางขึ้นไป |
ต้องมีการเข้าถึงส่วนภายในของอุปกรณ์ และยังคงทำได้หากอุปกรณ์ปิดอยู่หรือไม่ได้ปลดล็อกตั้งแต่เปิดเครื่อง | ความรุนแรง -1 |
ต้องเข้าถึงส่วนภายในของอุปกรณ์ขณะที่อุปกรณ์เปิดอยู่และเคยปลดล็อกไว้ก่อนหน้านี้ | ความรุนแรงระดับ -2 |
การโจมตีในเครื่องที่กำหนดให้ต้องปลดล็อกเชน Bootloader | ไม่เกิน "ต่ำ" |
การโจมตีในเครื่องที่กำหนดให้ต้องเปิดใช้โหมดนักพัฒนาซอฟต์แวร์หรือการตั้งค่าโหมดนักพัฒนาซอฟต์แวร์แบบถาวรในอุปกรณ์ (และไม่ใช่ข้อบกพร่องในโหมดนักพัฒนาซอฟต์แวร์) | ไม่เกิน "ต่ำ" |
หากไม่มีโดเมน SELinux ที่ดําเนินการภายใต้ SEPolicy ที่ Google ระบุ | ผลกระทบด้านความปลอดภัยเล็กน้อย |
อุปกรณ์ใกล้เคียงกับอุปกรณ์ระยะไกล
เวกเตอร์การโจมตีจากระยะไกลบ่งชี้ว่าสามารถใช้ประโยชน์จากข้อบกพร่องได้โดยไม่ต้องติดตั้งแอปหรือเข้าถึงอุปกรณ์ ซึ่งรวมถึงข้อบกพร่องที่อาจเกิดขึ้นจากการเรียกดูหน้าเว็บ การอ่านอีเมล การรับข้อความ SMS หรือการเชื่อมต่อกับเครือข่ายที่เป็นอันตราย
เวกเตอร์การโจมตีแบบ Proximal จะถือว่าอยู่ระยะไกล ซึ่งรวมถึงข้อบกพร่องที่ผู้โจมตีที่อยู่ใกล้กับอุปกรณ์เป้าหมายเท่านั้นที่จะใช้ประโยชน์ได้ เช่น ข้อบกพร่องที่ต้องใช้การส่งแพ็กเก็ต Wi-Fi หรือบลูทูธที่มีรูปแบบไม่ถูกต้อง เราถือว่าการโจมตีที่ใช้แถบความถี่กว้างยิ่งยวด (UWB) และ NFC เป็นโจมตีระยะใกล้และระยะไกล
การโจมตีในเครื่องกำหนดให้ผู้โจมตีมีสิทธิ์เข้าถึงเหยื่อก่อน ในตัวอย่างนี้ซึ่งสมมติขึ้นเกี่ยวกับซอฟต์แวร์เท่านั้น การดำเนินการนี้อาจเกิดขึ้นผ่านแอปที่เป็นอันตรายซึ่งเหยื่อติดตั้งไว้ หรือInstant App ที่เหยื่อให้ความยินยอมให้ทำงาน
ระบบจะถือว่าอุปกรณ์ที่จับคู่สำเร็จ (เช่น อุปกรณ์เสริมบลูทูธ) เป็นอุปกรณ์ภายใน เราแยกความแตกต่างระหว่างอุปกรณ์ที่จับคู่แล้วกับอุปกรณ์ที่เข้าร่วมขั้นตอนการจับคู่
- ข้อบกพร่องที่ลดความสามารถของผู้ใช้ในการระบุอุปกรณ์เครื่องอื่นที่จับคู่อยู่ (เช่น การตรวจสอบสิทธิ์) จะถือว่าอยู่ใกล้และจึงจัดว่าเป็นข้อบกพร่องระยะไกล
- ข้อบกพร่องที่เกิดขึ้นระหว่างขั้นตอนการจับคู่แต่ก่อนที่จะได้รับความยินยอมจากผู้ใช้ (เช่น การให้สิทธิ์) จะถือว่าอยู่ในช่วงใกล้เคียงและอยู่ระยะไกล
- ข้อบกพร่องที่เกิดขึ้นหลังจากได้รับความยินยอมจากผู้ใช้จะถือว่าเกิดขึ้นในอุปกรณ์ แม้ว่าการจับคู่จะดำเนินการไม่สำเร็จในท้ายที่สุดก็ตาม
เวกเตอร์การโจมตีที่จับต้องได้จะถือว่าอยู่ในพื้นที่ ซึ่งรวมถึงข้อบกพร่องที่ผู้โจมตีที่มีสิทธิ์เข้าถึงอุปกรณ์เท่านั้นที่จะใช้ประโยชน์ได้ เช่น ข้อบกพร่องในหน้าจอล็อกหรือข้อบกพร่องที่ต้องเสียบสาย USB เนื่องจากอุปกรณ์มักจะปลดล็อกอยู่ขณะเสียบ USB การโจมตีที่ต้องใช้การเชื่อมต่อ USB จึงมีความรุนแรงเท่ากัน ไม่ว่าอุปกรณ์จะต้องปลดล็อกหรือไม่ก็ตาม
การรักษาความปลอดภัยของเครือข่าย
Android จะถือว่าเครือข่ายทั้งหมดเป็นเครือข่ายที่เป็นอันตรายและอาจมีการแทรกการโจมตีหรือสอดแนมการเข้าชม แม้ว่าการรักษาความปลอดภัยของเลเยอร์ลิงก์ (เช่น การเข้ารหัส Wi-Fi) จะรักษาความปลอดภัยของการสื่อสารระหว่างอุปกรณ์กับจุดเข้าใช้งานที่เชื่อมต่ออยู่ แต่ก็ไม่ได้รักษาความปลอดภัยของลิงก์ที่เหลือในเชนระหว่างอุปกรณ์กับเซิร์ฟเวอร์ที่สื่อสารด้วย
ในทางตรงกันข้าม HTTPS มักจะปกป้องการสื่อสารทั้งหมดตั้งแต่ต้นจนจบ โดยเข้ารหัสข้อมูลจากแหล่งที่มา จากนั้นจึงถอดรหัสและยืนยันเมื่อข้อมูลไปถึงปลายทางเท่านั้น ด้วยเหตุนี้ ช่องโหว่ที่ส่งผลต่อความปลอดภัยของเครือข่ายเลเยอร์ลิงก์จึงมีระดับความรุนแรงน้อยกว่าช่องโหว่ใน HTTPS/TLS เนื่องจากการเข้ารหัส Wi-Fi เพียงอย่างเดียวไม่เพียงพอสําหรับการสื่อสารส่วนใหญ่บนอินเทอร์เน็ต
ตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริก
การยืนยันตัวตนด้วยข้อมูลไบโอเมตริกเป็นงานที่ท้าทาย และแม้แต่ระบบที่ดีที่สุดก็อาจถูกหลอกให้ยอมรับข้อมูลที่คล้ายกัน (ดูบล็อกของนักพัฒนาแอป Android: การปรับปรุงหน้าจอล็อกและการยืนยันตัวตนใน Android 11) การจัดประเภทความรุนแรงเหล่านี้จะแยกความแตกต่างระหว่างการโจมตี 2 ระดับและมีไว้เพื่อแสดงถึงความเสี่ยงจริงต่อผู้ใช้ปลายทาง
การโจมตีระดับแรกช่วยให้สามารถข้ามการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกได้ทั่วไป โดยไม่ต้องใช้ข้อมูลไบโอเมตริกที่มีคุณภาพสูงจากผู้เป็นเจ้าของ ตัวอย่างเช่น หากผู้โจมตีวางหมากฝรั่งบนเซ็นเซอร์ลายนิ้วมือ และเซ็นเซอร์ให้สิทธิ์เข้าถึงอุปกรณ์ตามเศษที่หลงเหลืออยู่บนเซ็นเซอร์ นี่เป็นรูปแบบการโจมตีง่ายๆ ที่อาจเกิดขึ้นกับอุปกรณ์ที่เปราะบาง โดยไม่จำเป็นต้องมีความรู้เกี่ยวกับเจ้าของอุปกรณ์ เนื่องจากสามารถนำไปใช้ได้ทั่วไปและอาจส่งผลกระทบต่อผู้ใช้จำนวนมากขึ้น การโจมตีนี้จึงได้รับคะแนนความรุนแรงเต็มรูปแบบ (เช่น สูงสําหรับการหลบเลี่ยงหน้าจอล็อก)
การโจมตีอีกประเภทหนึ่งโดยทั่วไปเกี่ยวข้องกับเครื่องมือโจมตีแบบนำเสนอ (การปลอมแปลง) โดยอิงตามเจ้าของอุปกรณ์ บางครั้งข้อมูลไบโอเมตริกนี้หาได้ง่าย (เช่น หากรูปโปรไฟล์ของบุคคลในโซเชียลมีเดียเพียงพอที่จะหลอกการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกได้ การลักลอบใช้ข้อมูลไบโอเมตริกจะได้รับคะแนนความรุนแรงเต็มรูปแบบ) แต่หากผู้โจมตีต้องการรับข้อมูลไบโอเมตริกจากเจ้าของอุปกรณ์โดยตรง (เช่น การสแกนอินฟราเรดใบหน้า) นี่เป็นอุปสรรคที่สำคัญมากพอที่จะจำกัดจำนวนผู้ที่ได้รับผลกระทบจากการโจมตี ดังนั้นจึงมีตัวคูณ -1
SYSTEM_ALERT_WINDOW และ Tapjacking
ดูข้อมูลเกี่ยวกับนโยบายของเราที่เกี่ยวข้องกับ SYSTEM_ALERT_WINDOW
และ Tapjacking ได้ในส่วน "ช่องโหว่ Tapjacking/การวางซ้อน SYSTEM_ALERT_WINDOW ในหน้าจอที่ไม่สำคัญต่อความปลอดภัย" ของหน้า
ข้อบกพร่องที่ไม่มีผลต่อความปลอดภัยจาก BugHunter University
ความปลอดภัยสำหรับผู้ใช้หลายคนใน Android Automotive OS
Android Automotive OS ใช้รูปแบบการรักษาความปลอดภัยแบบผู้ใช้หลายคนซึ่งแตกต่างจากอุปกรณ์รูปแบบอื่นๆ ผู้ใช้ Android แต่ละรายมีไว้สำหรับบุคคลที่แตกต่างกัน เช่น คุณสามารถกำหนดผู้ใช้ชั่วคราวที่เป็นผู้ที่มาเยือนให้กับเพื่อนที่ยืมรถจากเจ้าของรถ โดยค่าเริ่มต้น ผู้ใช้จะมีสิทธิ์เข้าถึงคอมโพเนนต์ที่จำเป็นในการใช้งานยานพาหนะ เช่น การตั้งค่า Wi-Fi และเครือข่ายมือถือ เพื่อรองรับกรณีการใช้งานเช่นนี้
คอมโพเนนต์ที่ได้รับผลกระทบ
ทีมพัฒนาซอฟต์แวร์ที่รับผิดชอบในการแก้ไขข้อบกพร่องจะขึ้นอยู่กับว่าข้อบกพร่องนั้นอยู่ในคอมโพเนนต์ใด อาจเป็นคอมโพเนนต์หลักของแพลตฟอร์ม Android, ไดร์เวอร์เคอร์เนลที่ผู้ผลิตอุปกรณ์ดั้งเดิม (OEM) จัดหาให้ หรือแอปที่โหลดไว้ล่วงหน้าในอุปกรณ์ Pixel
ทีมวิศวกรของ Android จะเป็นผู้แก้ไขข้อบกพร่องในโค้ด AOSP ข้อบกพร่องที่มีความรุนแรงต่ำ ข้อบกพร่องในคอมโพเนนต์บางอย่าง หรือข้อบกพร่องที่เป็นที่รู้จักต่อสาธารณะอยู่แล้วอาจได้รับการแก้ไขในสาขาหลักของ AOSP ที่เผยแพร่ต่อสาธารณะโดยตรง หรือจะแก้ไขในที่เก็บข้อมูลภายในของเราก่อนก็ได้
คอมโพเนนต์นี้ยังเป็นปัจจัยในวิธีที่ผู้ใช้จะได้รับข้อมูลอัปเดตด้วย ข้อบกพร่องในเฟรมเวิร์กหรือเคอร์เนลต้องใช้การอัปเดตเฟิร์มแวร์ผ่านอากาศ (OTA) ที่ OEM แต่ละรายต้องพุช ระบบสามารถส่งข้อบกพร่องในแอปหรือไลบรารีที่เผยแพร่ใน Google Play (เช่น Gmail, Google Play Services หรือ WebView) ไปยังผู้ใช้ Android เป็นการอัปเดตจาก Google Play
แจ้งให้พาร์ทเนอร์ทราบ
เมื่อมีการแก้ไขช่องโหว่ด้านความปลอดภัยใน AOSP ในประกาศข่าวสารด้านความปลอดภัยของ Android เราจะแจ้งรายละเอียดปัญหาและมอบแพตช์ให้พาร์ทเนอร์ Android รายการเวอร์ชันที่รองรับการพอร์ตย้อนกลับจะเปลี่ยนแปลงไปในแต่ละรุ่นของ 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 ตัวอย่างแหล่งข้อมูลที่ดีในการเริ่มต้น
รายงาน
บางครั้งทีมรักษาความปลอดภัยของ Android จะเผยแพร่รายงานหรือเอกสารประกอบ ดูรายละเอียดเพิ่มเติมได้ในรายงานความปลอดภัย