ทีมความปลอดภัยของ Android เป็นผู้รับผิดชอบในการจัดการช่องโหว่ด้านความปลอดภัยที่พบใน แพลตฟอร์ม Android และแอป Android หลักจำนวนมากที่มาพร้อมกับอุปกรณ์ Android
ทีมรักษาความปลอดภัยของ Android พบช่องโหว่ด้านความปลอดภัยผ่านการวิจัยภายในและ ตอบสนองต่อข้อบกพร่องที่รายงานโดยบุคคลที่สาม แหล่งที่มาของข้อบกพร่องภายนอกรวมถึงปัญหาที่รายงาน ผ่านทาง vulnerability form งานวิจัยทางวิชาการที่เผยแพร่และเผยแพร่ล่วงหน้า ผู้ดูแลโครงการโอเพนซอร์ส การแจ้งเตือนจากพาร์ทเนอร์ผู้ผลิตอุปกรณ์ของเรา และปัญหาที่เปิดเผยต่อสาธารณะที่โพสต์บน บล็อกหรือโซเชียลมีเดีย
การรายงานปัญหาด้านความปลอดภัย
นักพัฒนาซอฟต์แวร์ ผู้ใช้ Android หรือนักวิจัยด้านความปลอดภัยสามารถแจ้งให้ทีมความปลอดภัยของ Android ทราบได้ ปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นผ่าน vulnerability ได้
ข้อบกพร่องที่มีการทำเครื่องหมายว่าเป็นปัญหาด้านความปลอดภัยจะไม่ปรากฏแก่บุคคลภายนอก แต่ในที่สุดแล้วอาจมีการแก้ไข แสดงหลังจากปัญหาได้รับการประเมินหรือแก้ไขปัญหาแล้ว หากคุณวางแผนที่จะส่งแพตช์หรือ ความเข้ากันได้ Test Suite (CTS) การทดสอบเพื่อแก้ไขปัญหาด้านความปลอดภัย โปรดแนบไปกับข้อบกพร่อง รายงาน และรอการตอบกลับก่อนที่จะอัปโหลดโค้ดไปยัง AOSP
การคัดกรองข้อบกพร่อง
งานแรกในการจัดการกับช่องโหว่ด้านความปลอดภัยคือการระบุความรุนแรงของข้อบกพร่องและ คอมโพเนนต์ใดของ Android ที่ได้รับผลกระทบ ความรุนแรงจะเป็นตัวกำหนดวิธีจัดลำดับความสำคัญของปัญหา และคอมโพเนนต์จะกำหนดว่าใครแก้ไขข้อบกพร่อง ใครจะได้รับแจ้ง และทำการแก้ไขอย่างไร ให้แก่ผู้ใช้
ประเภทบริบท
ตารางนี้ครอบคลุมคำจำกัดความของบริบทด้านความปลอดภัยของฮาร์ดแวร์และซอฟต์แวร์ บริบทสามารถ กำหนดโดยความไวของข้อมูลที่การประมวลผลโดยทั่วไป หรือพื้นที่ที่ข้อมูลทำงาน ไม่ใช่ บริบทด้านความปลอดภัยทั้งหมดนั้นสามารถนำไปใช้กับทุกระบบ ตารางนี้เรียงลำดับจากน้อยไปมาก เป็นสิทธิ์เฉพาะบุคคล
ประเภทบริบท | คำจำกัดความของประเภท |
---|---|
บริบทที่จำกัด |
สภาพแวดล้อมการดำเนินการแบบจำกัดซึ่งมีเพียงสิทธิ์น้อยที่สุด
ที่มีให้ ตัวอย่างเช่น แอปพลิเคชันที่เชื่อถือซึ่งประมวลผลข้อมูลที่ไม่น่าเชื่อถือภายในแซนด์บ็อกซ์ ของคุณ |
บริบทที่ไม่มีสิทธิ์ |
สภาพแวดล้อมการดำเนินการทั่วไปซึ่งคาดหวังจากโค้ดที่ไม่มีสิทธิ์ ตัวอย่างเช่น แอปพลิเคชัน Android ที่ทำงานในโดเมน SELinux untrusted_app_all
|
บริบทที่มีสิทธิพิเศษ |
สภาพแวดล้อมการดำเนินการที่ได้รับสิทธิ์ซึ่งอาจเข้าถึงสิทธิ์ในระดับสูงขึ้นและจัดการได้
PII ของผู้ใช้หลายคน และ/หรือรักษาความสมบูรณ์ของระบบ ตัวอย่างเช่น แอปพลิเคชัน Android ที่มีขีดความสามารถซึ่งจะถูกห้ามโดย โดเมน SELinux untrusted_app หรือมีสิทธิ์เข้าถึง
สิทธิ์ privileged|signature รายการ
|
เคอร์เนลของระบบปฏิบัติการ |
ฟังก์ชันการทำงานที่
|
ฐานฮาร์ดแวร์ที่เชื่อถือได้ (THB) | ส่วนประกอบของฮาร์ดแวร์แยกกัน โดยทั่วไปแล้วจะอยู่ใน SoC ซึ่งมีฟังก์ชันการทำงานที่สำคัญ กับกรณีการใช้งานหลักของอุปกรณ์ (เช่น เครือข่ายมือถือเบสแบนด์, DSP, GPU และ ML ผู้ประมวลผลข้อมูล) |
เชน Bootloader | คอมโพเนนต์ที่กำหนดค่าอุปกรณ์เมื่อเปิดเครื่องแล้วส่งการควบคุมไปยังระบบปฏิบัติการ Android |
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) | คอมโพเนนต์ที่ออกแบบมาเพื่อปกป้องจากเคอร์เนลระบบปฏิบัติการที่เป็นอันตราย (ตัวอย่างเช่น TrustZone และไฮเปอร์ไวเซอร์ เช่น pKVM ซึ่งปกป้องเครื่องเสมือนจากระบบปฏิบัติการ เคอร์เนล) |
เครือข่ายที่ปลอดภัย / องค์ประกอบความปลอดภัย (SE) |
ส่วนประกอบฮาร์ดแวร์เสริมที่ออกแบบมาเพื่อป้องกันจากคอมโพเนนต์อื่นๆ ทั้งหมดใน
และจากการโจมตีทางกายภาพตามที่กำหนดไว้ใน
ข้อมูลเบื้องต้นเกี่ยวกับองค์ประกอบความปลอดภัย ซึ่งรวมถึงชิป Titan-M ที่มีอยู่ในอุปกรณ์ Android บางรุ่น |
ความรุนแรง
โดยทั่วไป ความรุนแรงของข้อบกพร่องแสดงถึงอันตรายที่อาจเกิดขึ้นหากข้อบกพร่อง ประสบความสำเร็จได้ ใช้เกณฑ์ต่อไปนี้เพื่อระบุความรุนแรง
Rating | ผลที่ตามมาของการแสวงหาประโยชน์ที่ประสบความสำเร็จ |
---|---|
วิกฤต |
|
สูง |
|
ปานกลาง |
|
ต่ำ |
|
ผลกระทบด้านความปลอดภัยที่ไม่มีนัยสำคัญ (NSI) |
|
ตัวแก้ไขการให้คะแนน
แม้ว่าความรุนแรงของช่องโหว่ด้านความปลอดภัยนั้นมักจะระบุได้ง่าย แต่การจัดประเภทอาจมีการเปลี่ยนแปลง ตามสถานการณ์
เหตุผล | เอฟเฟ็กต์ |
---|---|
ต้องเรียกใช้เป็นบริบทที่ได้รับสิทธิ์เพื่อดำเนินการโจมตี (ใช้ไม่ได้กับ TEE, SE, และไฮเปอร์ไวเซอร์ เช่น pKVM) | ความรุนแรง -1 |
รายละเอียดเกี่ยวกับช่องโหว่โดยเฉพาะจะจำกัดผลกระทบของปัญหา | ความรุนแรง -1 |
การข้ามการตรวจสอบสิทธิ์ด้วยข้อมูลไบโอเมตริกที่ต้องใช้ข้อมูลไบโอเมตริกโดยตรงจาก เจ้าของอุปกรณ์ | ความรุนแรง -1 |
การกำหนดค่าคอมไพเลอร์หรือแพลตฟอร์มช่วยลดช่องโหว่ในซอร์สโค้ด | ความรุนแรงปานกลาง หากช่องโหว่ที่ซ่อนอยู่คือปานกลางหรือสูงกว่า |
ต้องเข้าถึงอุปกรณ์ภายในอุปกรณ์และยังเป็นไปได้หากอุปกรณ์ปิดอยู่ หรือ ยังไม่ได้ปลดล็อกตั้งแต่เปิด | ความรุนแรง -1 |
ต้องมีสิทธิ์เข้าถึงอุปกรณ์ภายในขณะที่อุปกรณ์เปิดอยู่และก่อนหน้านี้ ปลดล็อกแล้ว | -2 ความรุนแรง |
การโจมตีในเครื่องที่จำเป็นต้องปลดล็อกเชน Bootloader | ไม่สูงกว่าค่าต่ำ |
การโจมตีในเครื่องที่จำเป็นต้องใช้โหมดนักพัฒนาซอฟต์แวร์หรือการตั้งค่าโหมดนักพัฒนาซอฟต์แวร์ถาวรเพื่อ บนอุปกรณ์ที่กำลังเปิดใช้อยู่ (และไม่ใช่ข้อบกพร่องในโหมดนักพัฒนาซอฟต์แวร์) | ไม่สูงกว่าค่าต่ำ |
หากไม่มีโดเมน SELinux ที่สามารถดำเนินการภายใต้ SEPolicy ที่ Google จัดหาให้ | ผลกระทบด้านความปลอดภัยเพียงเล็กน้อย |
ในพื้นที่เทียบกับที่อยู่บริเวณใกล้เคียงกับระยะไกล
เวกเตอร์การโจมตีระยะไกลบ่งชี้ว่าข้อบกพร่องนี้อาจถูกใช้ประโยชน์โดยไม่ต้องติดตั้งแอปหรือ โดยไม่ต้องเข้าถึงตัวอุปกรณ์ ซึ่งรวมถึงข้อบกพร่องที่อาจเกิดจากการท่องเว็บ หน้าเว็บ การอ่านอีเมล รับข้อความ SMS หรือการเชื่อมต่อกับเครือข่ายที่ไม่เป็นมิตร
เวกเตอร์การโจมตีที่พึงประสงค์จะถือว่าเป็นเวกเตอร์ระยะไกล ซึ่งรวมถึงข้อบกพร่องที่ อาจนำไปใช้ประโยชน์เท่านั้น โดยผู้โจมตีที่อยู่ใกล้อุปกรณ์เป้าหมาย เช่น ข้อบกพร่องที่ การส่งแพ็กเก็ต 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
และการตอกนิ้ว
สำหรับข้อมูลเกี่ยวกับนโยบาย SYSTEM_ALERT_WINDOW
และการหลอกแตะ
ดู "ช่องโหว่การเจาะระบบ/โฆษณาซ้อนทับ SYSTEM_ALERT_WINDOW ในหน้าจอที่ไม่สำคัญด้านความปลอดภัย" ใน BugHunter University
ข้อบกพร่องที่ไม่มีผลด้านความปลอดภัย
การรักษาความปลอดภัยแบบผู้ใช้หลายคนใน Android Automotive OS
Android Automotive OS ใช้โมเดลการรักษาความปลอดภัยแบบผู้ใช้หลายคน แตกต่างจากอุปกรณ์รูปแบบอื่นๆ ผู้ใช้ Android แต่ละคนมีจุดประสงค์ที่จะใช้โดย เป็นมนุษย์ ตัวอย่างเช่น ผู้ใช้ชั่วคราวสามารถมอบหมายให้เพื่อนที่ยืมเงินได้ รถยนต์จากเจ้าของรถ เพื่อรองรับกรณีการใช้งานเช่นนี้ โดยค่าเริ่มต้นแล้ว ผู้ใช้ เข้าถึงองค์ประกอบที่จำเป็นต่อการใช้รถ เช่น Wi-Fi และเครือข่ายมือถือ การตั้งค่า
คอมโพเนนต์ที่ได้รับผลกระทบ
ทีมพัฒนาที่รับผิดชอบในการแก้ไขข้อบกพร่องจะขึ้นอยู่กับว่าข้อบกพร่องนั้นอยู่ในองค์ประกอบใด นี่อาจเป็นส่วนประกอบหลักของแพลตฟอร์ม Android ซึ่งเป็นไดรเวอร์เคอร์เนลที่จัดทำโดย ผู้ผลิตอุปกรณ์ (OEM) หรือหนึ่งในแอปที่โหลดไว้ล่วงหน้าในอุปกรณ์ Pixel
ข้อบกพร่องในโค้ด AOSP ได้รับการแก้ไขโดยทีมวิศวกรของ Android ข้อบกพร่องความรุนแรงต่ำ ข้อบกพร่องใน คอมโพเนนต์บางอย่างหรือข้อบกพร่อง ที่ทราบกันแบบสาธารณะอยู่แล้วอาจได้รับการแก้ไขโดยตรง สาขาหลักของ AOSP ที่เปิดให้ใช้แบบสาธารณะ ไม่เช่นนั้นจะมีการแก้ไขในที่เก็บภายในของเรา ก่อน
นอกจากนี้ คอมโพเนนต์ยังเป็นปัจจัยหนึ่งที่ผู้ใช้ได้รับอัปเดตด้วย ข้อบกพร่องในเฟรมเวิร์กหรือเคอร์เนล ต้องอัปเดตเฟิร์มแวร์ผ่านอากาศ (OTA) ที่ OEM แต่ละรายจำเป็นต้องดำเนินการ ข้อบกพร่องในแอป หรือ ไลบรารีที่เผยแพร่ใน Google Play (ตัวอย่างเช่น Gmail, บริการ Google Play หรือ WebView) ได้ ที่ส่งไปยังผู้ใช้ Android โดยส่งเป็นอัปเดตจาก Google Play
การแจ้งเตือนพาร์ทเนอร์
เมื่อแก้ไขช่องโหว่ด้านความปลอดภัยใน AOSP ในกระดานข่าวสารด้านความปลอดภัยของ Android แล้ว เราจะแจ้งให้ทราบ พาร์ทเนอร์ Android ที่ระบุรายละเอียดของปัญหาและระบุแพตช์ รายการเวอร์ชันที่รองรับ Backport จะเปลี่ยนไปใน Android รุ่นใหม่แต่ละรุ่น โปรดติดต่อผู้ผลิตอุปกรณ์เพื่อขอดูรายชื่อ อุปกรณ์ที่รองรับ
กำลังเปิดตัวรหัสไปยัง AOSP
หากมีข้อบกพร่องด้านความปลอดภัยในคอมโพเนนต์ AOSP ระบบจะพุชการแก้ไขไปยัง AOSP หลังจากที่ OTA ดำเนินการแล้ว แก่ผู้ใช้แล้ว คุณอาจส่งการแก้ไขปัญหาที่มีความรุนแรงระดับต่ำไปยัง AOSP หลักโดยตรง Branch ก่อนที่การแก้ไขจะพร้อมให้บริการในอุปกรณ์ผ่าน 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 และเว็บไซต์ของนักพัฒนาซอฟต์แวร์ ดี จุดเริ่มต้น:
- https://source.android.com/docs/security
- https://developer.android.com/training/articles/security-tips
รายงาน
บางครั้งทีมความปลอดภัยของ Android อาจเผยแพร่รายงานหรือสมุดปกขาว โปรดดู รายงานความปลอดภัยสำหรับรายละเอียดเพิ่มเติม