การดำเนินการด้านความปลอดภัย

ทีมความปลอดภัยของ Android ได้รับคำขอข้อมูลเกี่ยวกับการป้องกันปัญหาด้านความปลอดภัยที่อาจเกิดขึ้นบนอุปกรณ์ Android เป็นประจำ นอกจากนี้เรายังตรวจสอบอุปกรณ์เป็นครั้งคราวและแจ้งให้ผู้ผลิตอุปกรณ์และพันธมิตรที่ได้รับผลกระทบทราบถึงปัญหาที่อาจเกิดขึ้น

หน้านี้ให้แนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยตามประสบการณ์ของเรา ขยายเอกสาร การออกแบบเพื่อความปลอดภัย ที่เราจัดเตรียมไว้สำหรับนักพัฒนา และรวมถึงรายละเอียดเฉพาะสำหรับการสร้างหรือการติดตั้งซอฟต์แวร์ระดับระบบบนอุปกรณ์

เพื่ออำนวยความสะดวกในการนำแนวทางปฏิบัติที่ดีที่สุดเหล่านี้มาใช้ หากเป็นไปได้ ทีมรักษาความปลอดภัยของ Android จะรวมการทดสอบเข้ากับ ชุดทดสอบความเข้ากันได้ของ Android (CTS) และ Android Lint เราสนับสนุนให้ผู้ใช้อุปกรณ์มีส่วนร่วมในการทดสอบที่สามารถช่วยเหลือผู้ใช้ Android คนอื่น ๆ (ดูการทดสอบที่เกี่ยวข้องกับความปลอดภัยที่ root/cts/tests/tests/security/src/android/security/cts )

กระบวนการพัฒนา

ใช้แนวทางปฏิบัติที่ดีที่สุดต่อไปนี้ในกระบวนการพัฒนาและสภาพแวดล้อมของคุณ

การตรวจสอบซอร์สโค้ด

การตรวจสอบซอร์สโค้ดสามารถตรวจพบปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาที่ระบุไว้ในเอกสารนี้ Android ขอแนะนำอย่างยิ่งให้ตรวจสอบซอร์สโค้ดทั้งแบบด้วยตนเองและแบบอัตโนมัติ ปฏิบัติที่ดีที่สุด:

• เรียกใช้ Android Lint บนโค้ดแอปพลิเคชันทั้งหมดโดยใช้ Android SDK และแก้ไขปัญหาที่ระบุ
• โค้ดแบบเนทีฟควรได้รับการวิเคราะห์โดยใช้เครื่องมืออัตโนมัติที่สามารถตรวจจับปัญหาการจัดการหน่วยความจำ เช่น บัฟเฟอร์ล้นและข้อผิดพลาดแบบออฟไลน์
• ระบบบิลด์ Android รองรับตัวฆ่าเชื้อ LLVM จำนวนมาก เช่น AddressSanitizer และ UndefiorSanitizer ซึ่งสามารถใช้เพื่อจุดประสงค์นี้ได้

การใช้การทดสอบอัตโนมัติ

การทดสอบอัตโนมัติสามารถตรวจพบปัญหาด้านความปลอดภัยได้หลากหลาย รวมถึงปัญหาต่างๆ ที่กล่าวถึงด้านล่าง ปฏิบัติที่ดีที่สุด:

• CTS ได้รับการอัปเดตเป็นประจำด้วยการทดสอบความปลอดภัย เรียกใช้ CTS เวอร์ชันล่าสุดเพื่อตรวจสอบความเข้ากันได้
• เรียกใช้ CTS อย่างสม่ำเสมอตลอดกระบวนการพัฒนาเพื่อตรวจพบปัญหาตั้งแต่เนิ่นๆ และลดเวลาในการแก้ไข Android ใช้ CTS เป็นส่วนหนึ่งของการผสานรวมอย่างต่อเนื่องในกระบวนการสร้างอัตโนมัติของเรา ซึ่งสร้างหลายครั้งต่อวัน
• ผู้ผลิตอุปกรณ์ควรทำการทดสอบความปลอดภัยของอินเทอร์เฟซโดยอัตโนมัติ รวมถึงการทดสอบด้วยอินพุตที่มีรูปแบบไม่ถูกต้อง (การทดสอบฟัซ)

ภาพระบบการลงนาม

ลายเซ็นของอิมเมจระบบมีความสำคัญอย่างยิ่งต่อการพิจารณาความสมบูรณ์ของอุปกรณ์ ปฏิบัติที่ดีที่สุด:

• อุปกรณ์จะต้องไม่ลงนามด้วยรหัสที่เป็นที่รู้จักต่อสาธารณะ
• คีย์ที่ใช้ในการลงนามอุปกรณ์ควรได้รับการจัดการในลักษณะที่สอดคล้องกับแนวปฏิบัติมาตรฐานอุตสาหกรรมสำหรับการจัดการคีย์ที่ละเอียดอ่อน รวมถึงโมดูลความปลอดภัยของฮาร์ดแวร์ (HSM) ที่ให้การเข้าถึงที่จำกัดและตรวจสอบได้

การลงนามแอปพลิเคชัน (APK)

ลายเซ็นแอปพลิเคชันมีบทบาทสำคัญในการรักษาความปลอดภัยของอุปกรณ์ และใช้สำหรับการตรวจสอบสิทธิ์รวมถึงการอัปเดตซอฟต์แวร์ เมื่อเลือกคีย์ที่จะใช้สำหรับการเซ็นชื่อแอปพลิเคชัน สิ่งสำคัญคือต้องพิจารณาว่าแอปพลิเคชันจะพร้อมใช้งานบนอุปกรณ์เครื่องเดียวเท่านั้นหรือทั่วไปในอุปกรณ์หลายเครื่อง ปฏิบัติที่ดีที่สุด:

• การสมัครจะต้องไม่ลงนามด้วยรหัสที่เป็นที่รู้จักต่อสาธารณะ
• คีย์ที่ใช้ในการลงนามแอปพลิเคชันควรได้รับการจัดการในลักษณะที่สอดคล้องกับหลักปฏิบัติมาตรฐานอุตสาหกรรมสำหรับการจัดการคีย์ที่ละเอียดอ่อน รวมถึง HSM ที่ให้การเข้าถึงที่จำกัดและตรวจสอบได้
• ไม่ควรลงนามแอปพลิเคชันด้วยคีย์แพลตฟอร์ม
• แอปพลิเคชันที่มีชื่อแพ็คเกจเดียวกันไม่ควรลงนามด้วยคีย์ที่แตกต่างกัน สิ่งนี้มักเกิดขึ้นเมื่อสร้างแอปพลิเคชันสำหรับอุปกรณ์ต่าง ๆ โดยเฉพาะเมื่อใช้คีย์แพลตฟอร์ม หากแอปพลิเคชันไม่ขึ้นอยู่กับอุปกรณ์ ให้ใช้คีย์เดียวกันในอุปกรณ์ต่างๆ หากแอปพลิเคชันเป็นแบบเฉพาะอุปกรณ์ ให้สร้างชื่อแพ็กเกจที่ไม่ซ้ำกันต่ออุปกรณ์และคีย์

การเผยแพร่แอปพลิเคชัน

Google Play ช่วยให้ผู้ผลิตอุปกรณ์สามารถอัปเดตแอปพลิเคชันโดยไม่ต้องอัปเดตระบบทั้งหมด วิธีนี้สามารถเร่งการตอบสนองต่อปัญหาด้านความปลอดภัยและการนำเสนอคุณสมบัติใหม่ ตลอดจนให้วิธีการตรวจสอบให้แน่ใจว่าแอปพลิเคชันของคุณมีชื่อแพ็คเกจที่ไม่ซ้ำใคร ปฏิบัติที่ดีที่สุด:

• อัปโหลดแอปพลิเคชันของคุณไปยัง Google Play เพื่ออนุญาตการอัปเดตอัตโนมัติโดยไม่ต้องมีการอัปเดตแบบ over-the-air (OTA) เต็มรูปแบบ แอปพลิเคชันที่อัปโหลดแต่ไม่ได้เผยแพร่จะไม่สามารถดาวน์โหลดได้โดยผู้ใช้โดยตรง แต่แอปพลิเคชันยังคงได้รับการอัปเดต ผู้ใช้ที่เคยติดตั้งแอปไว้ก่อนหน้านี้สามารถติดตั้งซ้ำและ/หรือติดตั้งบนอุปกรณ์อื่นได้
• สร้างชื่อแพ็คเกจแอปพลิเคชันที่เกี่ยวข้องกับบริษัทของคุณอย่างชัดเจน เช่น โดยใช้เครื่องหมายการค้าของบริษัท
• แอปพลิเคชันที่เผยแพร่โดยผู้ผลิตอุปกรณ์ควรอัปโหลดบน Google Play Store เพื่อหลีกเลี่ยงการแอบอ้างชื่อแพ็คเกจโดยผู้ใช้บุคคลที่สาม หากผู้ผลิตอุปกรณ์ติดตั้งแอปบนอุปกรณ์โดยไม่ต้องเผยแพร่แอปบน Play Store นักพัฒนารายอื่นสามารถอัปโหลดแอปเดียวกัน ใช้ชื่อแพ็กเกจเดียวกัน และเปลี่ยนข้อมูลเมตาสำหรับแอปได้ เมื่อมีการนำเสนอแอปต่อผู้ใช้ ข้อมูลเมตาที่ไม่เกี่ยวข้องนี้อาจสร้างความสับสนได้

ตอบสนองต่อเหตุการณ์ที่เกิดขึ้น

บุคคลภายนอกจะต้องมีความสามารถในการติดต่อผู้ผลิตอุปกรณ์เกี่ยวกับปัญหาด้านความปลอดภัยเฉพาะอุปกรณ์ เราขอแนะนำให้สร้างที่อยู่อีเมลที่เข้าถึงได้แบบสาธารณะเพื่อจัดการเหตุการณ์ด้านความปลอดภัย ปฏิบัติที่ดีที่สุด:

• สร้าง security@your-company.com หรือที่อยู่ที่คล้ายกันและเผยแพร่
• หากคุณทราบถึงปัญหาด้านความปลอดภัยที่ส่งผลต่อระบบปฏิบัติการ Android หรืออุปกรณ์ Android จากผู้ผลิตอุปกรณ์หลายราย คุณควรติดต่อทีมความปลอดภัยของ Android โดยยื่น รายงานข้อบกพร่องด้านความปลอดภัย

การนำผลิตภัณฑ์ไปใช้

ใช้แนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เมื่อนำผลิตภัณฑ์ไปใช้

การแยกกระบวนการรูท

กระบวนการรูทเป็นเป้าหมายที่พบบ่อยที่สุดของการโจมตีเพื่อยกระดับสิทธิ์ ดังนั้นการลดจำนวนกระบวนการรูทจึงช่วยลดความเสี่ยงของการเพิ่มระดับสิทธิ์ CTS มีการทดสอบข้อมูลที่แสดงรายการกระบวนการรูท ปฏิบัติที่ดีที่สุด:

• อุปกรณ์ควรใช้โค้ดที่จำเป็นขั้นต่ำในฐานะรูท หากเป็นไปได้ ให้ใช้กระบวนการ Android ปกติแทนกระบวนการรูท ICS Galaxy Nexus มีกระบวนการรูตเพียงหกกระบวนการ: vold, inetd, zygote, tf_daemon, ueventd และ init หากกระบวนการต้องทำงานในฐานะรูทบนอุปกรณ์ ให้บันทึกกระบวนการในคำขอคุณสมบัติ AOSP เพื่อให้สามารถตรวจสอบแบบสาธารณะได้
• หากเป็นไปได้ ควรแยกรหัสรูทออกจากข้อมูลที่ไม่น่าเชื่อถือและเข้าถึงผ่าน IPC ตัวอย่างเช่น ลดฟังก์ชันการทำงานของรูทลงในบริการขนาดเล็กที่เข้าถึงได้ผ่าน Binder และเปิดเผยบริการที่มีสิทธิ์ลายเซ็นไปยังแอปพลิเคชันที่มีสิทธิ์ต่ำหรือไม่มีเลยในการจัดการการรับส่งข้อมูลเครือข่าย
• กระบวนการรูทต้องไม่ฟังบนซ็อกเก็ตเครือข่าย
• กระบวนการรูทต้องไม่มีรันไทม์เพื่อวัตถุประสงค์ทั่วไปสำหรับแอปพลิเคชัน (เช่น Java VM)

กำลังแยกแอประบบ

โดยทั่วไป แอปที่ติดตั้งไว้ล่วงหน้าไม่ควรทำงานด้วย UID ของระบบที่ใช้ร่วมกัน อย่างไรก็ตาม หากจำเป็นสำหรับแอปที่จะใช้ UID ที่ใช้ร่วมกันของระบบหรือบริการพิเศษอื่น ๆ แอปไม่ควรส่งออกบริการ เครื่องรับการออกอากาศ หรือผู้ให้บริการเนื้อหาใด ๆ ที่แอปบุคคลที่สามซึ่งผู้ใช้ติดตั้งสามารถเข้าถึงได้ ปฏิบัติที่ดีที่สุด:

• อุปกรณ์ควรใช้รหัสขั้นต่ำที่จำเป็นเป็นระบบ หากเป็นไปได้ ให้ใช้กระบวนการ Android ที่มี UID ของตัวเอง แทนที่จะนำ UID ของระบบกลับมาใช้ใหม่
• หากเป็นไปได้ ควรแยกรหัสระบบออกจากข้อมูลที่ไม่น่าเชื่อถือ และเปิดเผย IPC ให้กับกระบวนการอื่นๆ ที่เชื่อถือได้เท่านั้น
• กระบวนการของระบบต้องไม่ฟังบนซ็อกเก็ตเครือข่าย

กระบวนการแยก

Android Application Sandbox จัดเตรียมแอปพลิเคชันที่คาดว่าจะแยกจากกระบวนการอื่นๆ ในระบบ รวมถึงกระบวนการรูทและโปรแกรมแก้ไขข้อบกพร่อง เว้นแต่ว่าแอปพลิเคชันและผู้ใช้จะเปิดใช้งานการดีบักโดยเฉพาะ ไม่มีแอปพลิเคชันใดที่ละเมิดความคาดหวังดังกล่าว ปฏิบัติที่ดีที่สุด:

• กระบวนการรูทจะต้องไม่เข้าถึงข้อมูลภายในโฟลเดอร์ข้อมูลแอปพลิเคชันแต่ละโฟลเดอร์ เว้นแต่จะใช้วิธีการแก้ไขจุดบกพร่อง Android ที่บันทึกไว้
• กระบวนการรูทจะต้องไม่เข้าถึงหน่วยความจำของแอปพลิเคชัน เว้นแต่จะใช้วิธีการดีบัก Android ที่บันทึกไว้
• อุปกรณ์ต้องไม่มีแอปพลิเคชันใดๆ ที่เข้าถึงข้อมูลหรือหน่วยความจำของแอปพลิเคชันหรือกระบวนการอื่นๆ

การรักษาความปลอดภัยไฟล์ SUID

โปรแกรม setuid ใหม่ไม่ควรสามารถเข้าถึงได้โดยโปรแกรมที่ไม่น่าเชื่อถือ โปรแกรม Setuid มักเป็นที่ตั้งของช่องโหว่ที่สามารถใช้เพื่อเข้าถึงรูทได้ ดังนั้นควรพยายามลดความพร้อมใช้งานของโปรแกรม setuid ให้เหลือน้อยที่สุดให้กับแอปพลิเคชันที่ไม่น่าเชื่อถือ ปฏิบัติที่ดีที่สุด:

• กระบวนการ SUID จะต้องไม่มีเชลล์หรือแบ็คดอร์ที่สามารถใช้เพื่อหลีกเลี่ยงโมเดลความปลอดภัยของ Android
• โปรแกรม SUID จะต้องไม่สามารถเขียนโดยผู้ใช้คนใดได้
• โปรแกรม SUID ไม่ควรสามารถอ่านหรือเรียกใช้งานได้ทั่วโลก สร้างกลุ่ม จำกัดการเข้าถึงไบนารี SUID เฉพาะสมาชิกของกลุ่มนั้น และวางแอปพลิเคชันใดๆ ที่ควรจะสามารถรันโปรแกรม SUID ลงในกลุ่มนั้นได้
• โปรแกรม SUID เป็นแหล่งทั่วไปของการรูทอุปกรณ์ของผู้ใช้ เพื่อลดความเสี่ยงนี้ โปรแกรม SUID ไม่ควรรันโดยผู้ใช้เชลล์

ตัวตรวจสอบ CTS รวมถึงรายการทดสอบข้อมูลไฟล์ SUID; ไฟล์ setuid บางไฟล์ไม่ได้รับอนุญาตต่อการทดสอบ CTS

การรักษาความปลอดภัยซ็อกเก็ตการฟัง

การทดสอบ CTS จะล้มเหลวเมื่ออุปกรณ์กำลังฟังบนพอร์ตใดๆ บนอินเทอร์เฟซใดๆ ในกรณีที่เกิดความล้มเหลว Android จะยืนยันว่ามีการใช้แนวทางปฏิบัติที่ดีที่สุดต่อไปนี้:

• ไม่ควรมีพอร์ตการฟังบนอุปกรณ์
• พอร์ตการฟังจะต้องสามารถปิดการใช้งานได้โดยไม่ต้องใช้ OTA นี่อาจเป็นการเปลี่ยนแปลงการกำหนดค่าเซิร์ฟเวอร์หรืออุปกรณ์ของผู้ใช้ก็ได้
• กระบวนการรูทจะต้องไม่ฟังบนพอร์ตใดๆ
• กระบวนการที่เป็นของ UID ของระบบจะต้องไม่ฟังบนพอร์ตใดๆ
• สำหรับ IPC ภายในที่ใช้ซ็อกเก็ต แอปพลิเคชันต้องใช้ซ็อกเก็ตโดเมน UNIX ที่จำกัดการเข้าถึงเฉพาะกลุ่ม สร้าง file descriptor สำหรับ IPC และทำให้เป็น +RW สำหรับกลุ่ม UNIX เฉพาะ แอปพลิเคชันไคลเอนต์ใด ๆ จะต้องอยู่ภายในกลุ่ม UNIX นั้น
• อุปกรณ์บางตัวที่มีโปรเซสเซอร์หลายตัว (เช่น วิทยุ/โมเด็มแยกจากโปรเซสเซอร์แอพพลิเคชั่น) ใช้ซ็อกเก็ตเครือข่ายเพื่อสื่อสารระหว่างโปรเซสเซอร์ ในกรณีดังกล่าว ซ็อกเก็ตเครือข่ายที่ใช้สำหรับการสื่อสารระหว่างโปรเซสเซอร์ต้องใช้อินเทอร์เฟซเครือข่ายแบบแยกเพื่อป้องกันการเข้าถึงโดยแอปพลิเคชันที่ไม่ได้รับอนุญาตบนอุปกรณ์ (นั่นคือ ใช้ iptables เพื่อป้องกันการเข้าถึงโดยแอปพลิเคชันอื่นบนอุปกรณ์)
• Daemon ที่จัดการพอร์ตการฟังจะต้องแข็งแกร่งต่อข้อมูลที่มีรูปแบบไม่ถูกต้อง Google อาจทำการทดสอบ Fuzz กับพอร์ตโดยใช้ไคลเอ็นต์ที่ไม่ได้รับอนุญาต และไคลเอ็นต์ที่ได้รับอนุญาต หากเป็นไปได้ ข้อขัดข้องใด ๆ จะถูกยื่นเป็นข้อบกพร่องโดยมีระดับความรุนแรงที่เหมาะสม

การบันทึกข้อมูล

การบันทึกข้อมูลจะเพิ่มความเสี่ยงต่อการเปิดเผยข้อมูลดังกล่าวและลดประสิทธิภาพของระบบ เหตุการณ์ด้านความปลอดภัยสาธารณะหลายครั้งเกิดขึ้นอันเป็นผลมาจากการบันทึกข้อมูลผู้ใช้ที่ละเอียดอ่อนโดยแอปพลิเคชันที่ติดตั้งโดยค่าเริ่มต้นบนอุปกรณ์ Android ปฏิบัติที่ดีที่สุด:

• แอปพลิเคชันหรือบริการของระบบไม่ควรบันทึกข้อมูลที่ให้มาจากแอปพลิเคชันบุคคลที่สามที่อาจมีข้อมูลที่ละเอียดอ่อน
• แอปพลิเคชันจะต้องไม่บันทึกข้อมูลส่วนบุคคลที่สามารถระบุตัวตนได้ (PII) เป็นส่วนหนึ่งของการดำเนินการตามปกติ

CTS มีการทดสอบที่จะตรวจสอบการมีอยู่ของข้อมูลที่ละเอียดอ่อนที่อาจอยู่ในบันทึกของระบบ

การจำกัดการเข้าถึงไดเรกทอรี

ไดเร็กทอรีที่เขียนได้ทั่วโลกสามารถนำเสนอจุดอ่อนด้านความปลอดภัยและทำให้แอปพลิเคชันสามารถเปลี่ยนชื่อไฟล์ที่เชื่อถือได้ ทดแทนไฟล์ หรือทำการโจมตีโดยใช้ Symlink (ผู้โจมตีอาจใช้ Symlink ไปยังไฟล์เพื่อหลอกให้โปรแกรมที่เชื่อถือได้ดำเนินการตามที่ไม่ควรทำ) ไดเร็กทอรีที่เขียนได้ยังสามารถป้องกันการถอนการติดตั้งแอปพลิเคชันจากการล้างไฟล์ทั้งหมดที่เกี่ยวข้องกับแอปพลิเคชันอย่างเหมาะสม

ตามแนวทางปฏิบัติที่ดีที่สุด ไดเร็กทอรีที่สร้างโดยระบบหรือผู้ใช้รูทไม่ควรสามารถเขียนได้ทั่วโลก การทดสอบ CTS ช่วยบังคับใช้แนวทางปฏิบัติที่ดีที่สุดนี้โดยการทดสอบไดเรกทอรีที่รู้จัก

การรักษาความปลอดภัยไฟล์การกำหนดค่า

ไดรเวอร์และบริการจำนวนมากอาศัยการกำหนดค่าและไฟล์ข้อมูลที่จัดเก็บไว้ในไดเร็กทอรี เช่น /system/etc และ /data หากไฟล์เหล่านี้ได้รับการประมวลผลโดยกระบวนการพิเศษและสามารถเขียนได้ทั่วโลก ก็เป็นไปได้ที่แอปจะใช้ประโยชน์จากช่องโหว่ในกระบวนการโดยการสร้างเนื้อหาที่เป็นอันตรายในไฟล์ที่เขียนได้ทั่วโลก ปฏิบัติที่ดีที่สุด:

• ไฟล์การกำหนดค่าที่ใช้โดยกระบวนการพิเศษไม่ควรสามารถอ่านได้ทั่วโลก
• ไฟล์การกำหนดค่าที่ใช้โดยกระบวนการพิเศษจะต้องไม่สามารถเขียนได้ทั่วโลก

การจัดเก็บไลบรารีโค้ดเนทิฟ

รหัสใดๆ ที่ใช้โดยกระบวนการของผู้ผลิตอุปกรณ์ที่มีสิทธิพิเศษจะต้องอยู่ใน /vendor หรือ /system ; ระบบไฟล์เหล่านี้ติดตั้งแบบอ่านอย่างเดียวเมื่อบู๊ตเครื่อง ตามแนวทางปฏิบัติที่ดีที่สุด ไลบรารีที่ใช้โดยระบบหรือแอปสิทธิพิเศษสูงอื่นๆ ที่ติดตั้งบนอุปกรณ์ควรอยู่ในระบบไฟล์เหล่านี้ด้วย วิธีนี้สามารถป้องกันช่องโหว่ด้านความปลอดภัยที่อาจทำให้ผู้โจมตีสามารถควบคุมโค้ดที่กระบวนการที่มีสิทธิ์ดำเนินการได้

การจำกัดการเข้าถึงไดรเวอร์อุปกรณ์

เฉพาะรหัสที่เชื่อถือได้เท่านั้นจึงควรเข้าถึงไดรเวอร์ได้โดยตรง หากเป็นไปได้ สถาปัตยกรรมที่ต้องการคือจัดเตรียม daemon วัตถุประสงค์เดียวที่พร็อกซีเรียกไปยังไดรเวอร์ และจำกัดการเข้าถึงของไดรเวอร์ไปยัง daemon นั้น ตามแนวทางปฏิบัติที่ดีที่สุด โหนดอุปกรณ์ไดรเวอร์ไม่ควรสามารถอ่านหรือเขียนได้ทั่วโลก การทดสอบ CTS ช่วยบังคับใช้แนวทางปฏิบัติที่ดีที่สุดนี้โดยการตรวจสอบอินสแตนซ์ที่ทราบของไดรเวอร์ที่ถูกเปิดเผย

ปิดการใช้งาน ADB

Android Debug Bridge (adb) เป็นเครื่องมือในการพัฒนาและแก้ไขข้อบกพร่องที่มีคุณค่า แต่ได้รับการออกแบบมาเพื่อใช้ในสภาพแวดล้อมที่มีการควบคุมและปลอดภัย และไม่ควรเปิดใช้งานสำหรับการใช้งานทั่วไป ปฏิบัติที่ดีที่สุด:

• ADB จะต้องปิดใช้งานตามค่าเริ่มต้น
• ADB ต้องกำหนดให้ผู้ใช้เปิดใช้งานก่อนที่จะยอมรับการเชื่อมต่อ

การปลดล็อค bootloaders

อุปกรณ์ Android จำนวนมากรองรับการปลดล็อค ทำให้เจ้าของอุปกรณ์สามารถแก้ไขพาร์ติชันระบบและ/หรือติดตั้งระบบปฏิบัติการแบบกำหนดเองได้ กรณีการใช้งานทั่วไป ได้แก่ การติดตั้ง ROM ของบริษัทอื่นและดำเนินการพัฒนาระดับระบบบนอุปกรณ์ ตัวอย่างเช่น เจ้าของอุปกรณ์ Google Nexus สามารถเรียกใช้ fastboot oem unlock เพื่อเริ่มกระบวนการปลดล็อค ซึ่งจะแสดงข้อความต่อไปนี้แก่ผู้ใช้:

ตามแนวทางปฏิบัติที่ดีที่สุด อุปกรณ์ Android ที่ปลดล็อคได้จะต้องลบข้อมูลผู้ใช้ทั้งหมดอย่างปลอดภัยก่อนที่จะปลดล็อค ความล้มเหลวในการลบข้อมูลทั้งหมดในการปลดล็อคอย่างถูกต้องอาจทำให้ผู้โจมตีที่อยู่ใกล้ทางกายภาพสามารถเข้าถึงข้อมูลผู้ใช้ Android ที่เป็นความลับโดยไม่ได้รับอนุญาต เพื่อป้องกันการเปิดเผยข้อมูลผู้ใช้ อุปกรณ์ที่รองรับการปลดล็อคจะต้องดำเนินการอย่างถูกต้อง (เราได้เห็นหลายครั้งที่ผู้ผลิตอุปกรณ์ดำเนินการปลดล็อคอย่างไม่เหมาะสม) กระบวนการปลดล็อคที่นำไปใช้อย่างถูกต้องมีคุณสมบัติดังต่อไปนี้:

• เมื่อผู้ใช้ยืนยันคำสั่งปลดล็อค อุปกรณ์จะต้องเริ่มการล้างข้อมูลทันที ต้องไม่ตั้งค่าแฟล็ก unlocked จนกว่าการลบแบบปลอดภัยจะเสร็จสิ้น
• หากไม่สามารถลบอย่างปลอดภัยได้ อุปกรณ์จะต้องอยู่ในสถานะล็อค
• หากได้รับการสนับสนุนจากอุปกรณ์บล็อกพื้นฐาน ควรใช้ ioctl(BLKSECDISCARD) หรือเทียบเท่า สำหรับอุปกรณ์ eMMC นี่หมายถึงการใช้คำสั่ง Secure Erase หรือ Secure Trim สำหรับ eMMC 4.5 และใหม่กว่า หมายถึงการใช้การลบหรือตัดแต่งตามปกติตามด้วยการดำเนินการฆ่าเชื้อ
• หากอุปกรณ์บล็อกพื้นฐานไม่รองรับ BLKSECDISCARD จะต้องใช้ ioctl(BLKDISCARD) แทน บนอุปกรณ์ eMMC นี่เป็นการดำเนินการตัดแต่งตามปกติ
• หากไม่รองรับ BLKDISCARD การเขียนทับอุปกรณ์บล็อกด้วยเลขศูนย์ทั้งหมดก็เป็นที่ยอมรับ
• ผู้ใช้จะต้องมีตัวเลือกในการกำหนดให้ล้างข้อมูลผู้ใช้ก่อนที่จะแฟลชพาร์ติชัน ตัวอย่างเช่น บนอุปกรณ์ Nexus สามารถทำได้ผ่านคำสั่ง fastboot oem lock
• อุปกรณ์อาจบันทึกผ่านฟิวส์หรือกลไกที่คล้ายกัน ไม่ว่าอุปกรณ์จะถูกปลดล็อคและ/หรือล็อคซ้ำหรือไม่ก็ตาม

ข้อกำหนดเหล่านี้ช่วยให้แน่ใจว่าข้อมูลทั้งหมดจะถูกทำลายเมื่อการดำเนินการปลดล็อคเสร็จสิ้น ความล้มเหลวในการดำเนินการป้องกันเหล่านี้ถือเป็นช่องโหว่ด้านความปลอดภัยระดับปานกลาง

อุปกรณ์ที่ถูกปลดล็อคอาจถูกล็อคซ้ำในภายหลังโดยใช้คำสั่ง fastboot oem lock การล็อคบูตโหลดเดอร์จะให้การปกป้องข้อมูลผู้ใช้ด้วยระบบปฏิบัติการแบบกำหนดเองใหม่ เช่นเดียวกับที่มีในระบบปฏิบัติการของผู้ผลิตอุปกรณ์ดั้งเดิม (เช่น ข้อมูลผู้ใช้จะถูกล้างหากอุปกรณ์ถูกปลดล็อคอีกครั้ง)