Stagefright: การใช้ประโยชน์ที่เปลี่ยนแปลง Android

Stagefright เป็นหนึ่งในช่องโหว่ที่เลวร้ายที่สุดของ Android ที่เคยเห็นมาในช่วงไม่กี่ปีที่ผ่านมา คลิกเพื่ออ่านข้อมูลเพิ่มเติมเกี่ยวกับข้อมูลเฉพาะและวิธีป้องกันตัวเอง!

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

ที่ Google I/O 2014 Google ได้ผลักดันครั้งแรกไปสู่ระบบนิเวศที่ปลอดภัยและเป็นมิตรกับองค์กรมากขึ้นด้วยการเปิดตัว โปรแกรม Android For Work. Android For Work นำแนวทางโปรไฟล์คู่มาใช้ตามความต้องการขององค์กร โดยที่ผู้ดูแลระบบไอทีสามารถสร้าง โปรไฟล์ผู้ใช้ที่แตกต่างกันสำหรับพนักงาน - โปรไฟล์หนึ่งเน้นไปที่การทำงาน และเหลือโปรไฟล์อื่นไว้สำหรับส่วนตัวของพนักงาน ใช้. การใช้การเข้ารหัสด้วยฮาร์ดแวร์และนโยบายที่จัดการโดยผู้ดูแลระบบ ข้อมูลงานและข้อมูลส่วนบุคคลยังคงแตกต่างและปลอดภัย ต่อมา Android For Work ได้รับความสนใจมากขึ้นในช่วงหลายเดือนต่อมา โดยเน้นไปที่ความปลอดภัยของอุปกรณ์จากมัลแวร์เป็นหลัก Google ยังวางแผนที่จะ

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

การผลักดันให้มี Android ที่ปลอดภัยไม่ใช่งานของ Google ทั้งหมด เนื่องจาก Samsung มีบทบาทสำคัญในเรื่องนี้ผ่านทางมัน KNOX สนับสนุน AOSPซึ่งท้ายที่สุดแล้ว เสริมความแข็งแกร่งให้กับ Android For Work. อย่างไรก็ตาม ช่องโหว่ด้านความปลอดภัยและช่องโหว่ล่าสุดใน Android ชี้ให้เห็นถึงงานที่ยากลำบากเมื่อพูดถึงความนิยมในการนำไปใช้ในองค์กร กรณีตัวอย่างคือช่องโหว่ Stagefright ล่าสุด

สารบัญ:

  • Stagefright คืออะไร?
  • Stagefright ร้ายแรงแค่ไหน?
  • อะไรทำให้ Stagefright แตกต่างจาก "ช่องโหว่ขนาดใหญ่" อื่นๆ
  • ภาวะที่กลืนไม่เข้าคายไม่ออกของการอัปเดต
  • Android, หลังการแสดงบนเวที
  • หมายเหตุปิดท้าย

Stagefright คืออะไร?

พูดง่ายๆ ก็คือ Stagefright เป็นช่องโหว่ที่ใช้ไลบรารีโค้ดสำหรับการเล่นสื่อใน Android ที่เรียกว่า libstagefright. เอ็นจิ้น libstagefright ใช้ในการรันโค้ดที่ได้รับในรูปแบบของวิดีโอที่เป็นอันตรายผ่าน MMS ดังนั้นจึงต้องใช้เพียงหมายเลขโทรศัพท์มือถือของเหยื่อเท่านั้นจึงจะโจมตีได้สำเร็จ

เราติดต่อผู้เชี่ยวชาญภายในของเรา XDA Senior Recognized Developer และ Developer Admin พัลเซอร์_g2 เพื่อให้คำอธิบายที่ละเอียดยิ่งขึ้น

"ขณะที่ฉันเขียนสิ่งนี้ จะมีการอธิบายการหาประโยชน์จาก [Stagefright] ที่ BlackHat [ลิงค์] แม้ว่าจะไม่มีรายละเอียดสไลด์หรือกระดาษขาวก็ตาม

ดังนั้นฉันจึงให้คำอธิบายนี้เป็นเพียงแนวคิดคร่าวๆ เกี่ยวกับสิ่งที่เกิดขึ้น แทนที่จะเป็นคำอธิบายเชิงลึกที่มีความถูกต้องครบถ้วน ฯลฯ

มีข้อบกพร่องต่างๆ มากมายที่ประกอบขึ้นเป็น Stagefright และข้อบกพร่องเหล่านี้มี CVE ของตัวเอง [ช่องโหว่และความเสี่ยงทั่วไป] หมายเลขสำหรับการติดตาม:

  • CVE-2015-1538
  • CVE-2015-1539
  • CVE-2015-3824
  • CVE-2015-3826
  • CVE-2015-3827
  • CVE-2015-3828
  • CVE-2015-3829

น่าเสียดายที่แพตช์ที่พร้อมใช้งานไม่ได้เชื่อมโยงโดยตรงกับ CVE แต่ละตัว (ตามที่ควรจะเป็น) ดังนั้นนี่อาจอธิบายได้ยากเล็กน้อย

1. [CVE-2015-1538]

ในโค้ดการจัดการ MPEG4 ข้อมูลเมตา 3GPP (สิ่งที่อธิบายรูปแบบและข้อมูลเพิ่มเติมอื่นๆ เมื่อวิดีโออยู่ในรูปแบบ 3GPP) โค้ดการจัดการจะมีปัญหา มันไม่ได้ปฏิเสธเมตาดาต้าที่ข้อมูลมีขนาดใหญ่เกินไป แต่เพียงตรวจสอบว่าข้อมูลมีขนาดเล็กเกินไปหรือไม่ ซึ่งหมายความว่าผู้โจมตีสามารถสร้างไฟล์ "แก้ไข" หรือ "เสียหาย" ได้ ซึ่งจะมีส่วนเมทาดาทาที่ยาวเกินกว่าที่ควรจะเป็น

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

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

(อ้างอิง: OmniROM เกอร์ริต)

2. [CVE-2015-1539]

"ขนาด" ที่สั้นที่สุดที่เป็นไปได้ของข้อมูลเมตาควรเป็น 6 ไบต์ เนื่องจากเป็นสตริง UTF-16 รหัสใช้ขนาดค่าจำนวนเต็ม และลบ 6 จากนั้น หากค่านี้น้อยกว่า 6 การลบจะ "น้อยไป" และพันรอบ และเราจะได้ตัวเลขที่มาก ลองนึกภาพว่าคุณสามารถนับได้ตั้งแต่ 0 ถึง 65535 เท่านั้น ถ้าคุณเอาเลข 4 มาลบ 6 คุณจะไปต่ำกว่าศูนย์ไม่ได้ คุณกลับไปที่ 65535 แล้วนับต่อจากนั้น นั่นคือสิ่งที่เกิดขึ้นที่นี่!

หากได้รับความยาวต่ำกว่า 6 อาจทำให้เฟรมถูกถอดรหัสไม่ถูกต้อง เนื่องจาก กระบวนการ byteswap ใช้ตัวแปร len16 ซึ่งค่าที่ได้มาจากการคำนวณเริ่มต้นด้วย (ขนาด-6). ซึ่งอาจทำให้การดำเนินการสลับมีขนาดใหญ่กว่าที่ตั้งใจไว้มาก ซึ่งจะเปลี่ยนค่าในข้อมูลเฟรมในลักษณะที่ไม่คาดคิด

(อ้างอิง: OmniROM เกอร์ริต)

3. [CVE-2015-3824]

ตัวโต! อันนี้น่ารังเกียจ มีสิ่งตรงกันข้ามกับฉบับที่แล้วนี้ นั่นคือจำนวนเต็มล้น โดยที่จำนวนเต็มอาจ "ใหญ่เกินไป" หากคุณถึง 65535 (ตัวอย่าง) และไม่สามารถนับได้สูงกว่านี้ คุณจะกลิ้งไปรอบๆ และไปที่ 0 ถัดไป!

หากคุณกำลังจัดสรรหน่วยความจำตามสิ่งนี้ (ซึ่งเป็นสิ่งที่ Stagefright กำลังทำอยู่!) คุณจะพบว่ามีการจัดสรรหน่วยความจำในอาเรย์น้อยเกินไป เมื่อใส่ข้อมูลลงในสิ่งนี้ อาจมีการเขียนทับข้อมูลที่ไม่เกี่ยวข้องด้วยข้อมูลที่ผู้สร้างไฟล์ที่เป็นอันตรายควบคุม

(อ้างอิง: OmniROM เกอร์ริต)

4. [CVE-2015-3826]

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

(อ้างอิง: OmniROM เกอร์ริต)

5. [CVE-2015-3827]

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

(อ้างอิง: OmniROM เกอร์ริต)

นอกจากนี้ยังมีการแก้ไขที่เกี่ยวข้อง (อาจ) บางอย่างที่ดูเหมือนว่าจะทำให้เป็น [Android] 5.1 เช่นกัน

(อ้างอิง: OmniROM เกอร์ริต)

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

(อ้างอิง: OmniROM เกอร์ริต)

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

(อ้างอิง: OmniROM เกอร์ริต)

และสุดท้ายก็มีจำนวนเต็มล้นอีกจำนวนหนึ่ง เหมือนเมื่อก่อนกำลังจะไปใช้ที่อื่นและอาจล้นได้

(อ้างอิง: OmniROM เกอร์ริต)"

Stagefright ร้ายแรงแค่ไหน?

ตามที่ โพสต์บล็อก เผยแพร่โดยบริษัทวิจัยหลัก Zimperium Research Labs การใช้ประโยชน์จาก Stagefright อาจเปิดเผยได้ 95% ของอุปกรณ์ Android - ประมาณ 950 ล้านเครื่อง - ถึงช่องโหว่นี้เนื่องจากส่งผลกระทบต่ออุปกรณ์ที่ใช้ Android 2.2 และ ขึ้น. ที่แย่กว่านั้นคือ อุปกรณ์รุ่นก่อนหน้า Jelly Bean 4.3 มี “ความเสี่ยงที่เลวร้ายที่สุด” เนื่องจากอุปกรณ์เหล่านี้ไม่มีมาตรการบรรเทาผลกระทบที่เพียงพอต่อการโจมตีช่องโหว่นี้

เกี่ยวกับความเสียหายที่ Stagefright สามารถทำได้ Pulser_g2 ตั้งข้อสังเกต:

[blockquote author="pulser_g2"]"ในตัวมันเอง Stagefright จะให้สิทธิ์การเข้าถึงแก่ผู้ใช้ระบบบนโทรศัพท์ คุณจะต้องข้าม ASLR (การสุ่มเค้าโครงพื้นที่ที่อยู่) เพื่อใช้งานในทางที่ผิด ความสำเร็จนี้สำเร็จหรือไม่นั้นยังไม่เป็นที่ทราบแน่ชัด ช่องโหว่นี้ทำให้สามารถเรียกใช้ "รหัสที่กำหนดเอง" บนอุปกรณ์ของคุณในฐานะผู้ใช้ระบบหรือสื่อได้ สิ่งเหล่านี้สามารถเข้าถึงเสียงและกล้องบนอุปกรณ์ได้ และผู้ใช้ระบบก็เป็นสถานที่ที่ดีเยี่ยมในการเริ่มการใช้ประโยชน์จากรูท จำการรูทช่องโหว่ที่น่าทึ่งทั้งหมดที่คุณใช้รูทโทรศัพท์ของคุณได้ไหม?

สิ่งเหล่านี้อาจถูกนำมาใช้อย่างเงียบ ๆ เพื่อรูทอุปกรณ์ของคุณ! ผู้ที่มีรูทจะเป็นเจ้าของโทรศัพท์ พวกเขาจะต้องเลี่ยงผ่าน SELinux แต่ TowelRoot ก็จัดการเรื่องนั้นได้ และ PingPong ก็สามารถจัดการได้เช่นกัน เมื่อพวกเขารูทแล้ว ทุกอย่างในโทรศัพท์ของคุณจะถูกเปิดให้พวกเขา ข้อความ กุญแจ ฯลฯ"[/blockquote]เมื่อพูดถึงสถานการณ์กรณีที่เลวร้ายที่สุด มีเพียง MMS เท่านั้นที่จำเป็นในการส่งโค้ดและกระตุ้นการโจมตีนี้ ผู้ใช้งาน ไม่จำเป็นต้องเปิดข้อความด้วยซ้ำ เนื่องจากแอปส่งข้อความจำนวนมากจะประมวลผล MMS ล่วงหน้าก่อนที่ผู้ใช้จะโต้ตอบ สิ่งนี้แตกต่างจากการโจมตีแบบฟิชชิ่งแบบหอก เนื่องจากผู้ใช้อาจลืมการโจมตีที่ประสบความสำเร็จได้โดยสิ้นเชิง โดยกระทบต่อข้อมูลปัจจุบันและอนาคตทั้งหมดในโทรศัพท์

อะไรทำให้ Stagefright แตกต่างจาก “ช่องโหว่ขนาดใหญ่” อื่นๆ?

“ช่องโหว่ทั้งหมดก่อให้เกิดความเสี่ยงต่อผู้ใช้ สิ่งนี้มีความเสี่ยงเป็นพิเศษ เนื่องจากหากมีคนพบวิธีโจมตีมันจากระยะไกล (ซึ่งก็คือ เป็นไปได้ หากพบวิธีแก้ไข ASLR) อาจถูกกระตุ้นก่อนที่คุณจะรู้ตัวว่าอยู่ใต้นั้น จู่โจม"

การหาประโยชน์แบบเก่าๆ เช่น Android Installer Hijacking, FakeID รวมถึงการหาประโยชน์จากรูท เช่น TowelRoot และ PingPong จำเป็นต้องมีการโต้ตอบจากผู้ใช้ ณ จุดใดจุดหนึ่งเพื่อที่จะดำเนินการ แม้ว่าพวกมันจะยังคง “แสวงหาประโยชน์” ในความจริงที่ว่าความเสียหายมากมายสามารถเกิดขึ้นได้หากนำไปใช้ในทางที่ผิด แต่ความจริงก็คือ Stagefright ตามทฤษฎีแล้ว ต้องการเพียงหมายเลขโทรศัพท์มือถือของเหยื่อเท่านั้นที่จะเปลี่ยนโทรศัพท์ของพวกเขาให้เป็นโทรจัน และด้วยเหตุนี้จึงได้รับความสนใจอย่างมากในช่วงไม่กี่ปีที่ผ่านมา วัน

แม้ว่า Android จะไม่ได้อยู่ในความเมตตาของการใช้ประโยชน์นี้ก็ตาม Adrian Ludwig หัวหน้าวิศวกรฝ่ายความปลอดภัยของ Android กล่าวถึงข้อกังวลบางประการใน โพสต์ของ Google+:

[blockquote author="Adrian Ludwig"]"มีสมมติฐานทั่วไปที่เข้าใจผิดว่าข้อบกพร่องของซอฟต์แวร์ใดๆ สามารถกลายเป็นช่องโหว่ด้านความปลอดภัยได้ ในความเป็นจริง ข้อบกพร่องส่วนใหญ่ไม่สามารถหาประโยชน์ได้ และมีหลายสิ่งที่ Android ทำเพื่อปรับปรุงโอกาสเหล่านั้น...

รายชื่อเทคโนโลยีบางส่วนที่เปิดตัวตั้งแต่ Ice Cream Sandwich (Android 4.0) อยู่ในรายการ ที่นี่. สิ่งที่เป็นที่รู้จักมากที่สุดเรียกว่าการสุ่มเค้าโครงพื้นที่ที่อยู่ (ASLR) ซึ่งเสร็จสมบูรณ์อย่างสมบูรณ์ ใน Android 4.1 พร้อมรองรับ PIE (Position Independent Executables) และตอนนี้ใช้งานบน Android มากกว่า 85% อุปกรณ์ เทคโนโลยีนี้ทำให้ผู้โจมตีคาดเดาตำแหน่งของโค้ดได้ยากขึ้น ซึ่งจำเป็นสำหรับพวกเขาในการสร้างช่องโหว่ที่ประสบความสำเร็จ...

เราไม่ได้หยุดแค่ ASLR เรายังเพิ่ม NX, FortifySource, การย้ายตำแหน่งแบบอ่านอย่างเดียว, Stack Canaries และอื่นๆ อีกมากมาย"[/blockquote]

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

ภาวะที่กลืนไม่เข้าคายไม่ออกของการอัปเดต

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

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

OEM อื่นๆ ที่เข้าร่วมกลุ่มนี้ ได้แก่ LG ที่จะเข้าร่วมด้วย การอัปเดตความปลอดภัยรายเดือน. โมโตโรล่ายังได้ประกาศว่า รายการอุปกรณ์ที่จะอัพเดต พร้อมการแก้ไข Stagefright และรายการนี้รวมอุปกรณ์เกือบทั้งหมดที่บริษัทผลิตมาตั้งแต่ปี 2013 โซนี่ยังได้กล่าวอีกว่า อุปกรณ์ของมันจะได้รับแพตช์ในไม่ช้า ด้วย.

ผู้ให้บริการก็กำลังเตรียมการอัพเดตด้วยเช่นกัน สปริ้นท์ก็มี ออกแถลงการณ์ ว่าอุปกรณ์บางตัวได้รับแพตช์ Stagefright แล้ว และมีอุปกรณ์อีกจำนวนหนึ่งที่กำหนดไว้สำหรับการอัพเดต AT&T ก็ได้ปฏิบัติตามเช่นกัน โดยการออกแพตช์ให้กับอุปกรณ์บางตัว Verizon ยังได้ออกแพทช์ แม้ว่านี่จะเป็นการเปิดตัวที่ช้าซึ่งให้ความสำคัญกับสมาร์ทโฟนระดับไฮเอนด์เช่น Galaxy S6 Edge และ Note 4 T-Mobile Note 4 ได้รับการอัพเดตแพตช์ Stagefright เช่นกัน

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

ในฐานะผู้ใช้ระดับสูงของ XDA คุณก็สามารถทำได้เช่นกัน ทำการแก้ไขบน build prop ของคุณเพื่อปิดการใช้งาน Stagefright. นี่ไม่ใช่วิธีที่สมบูรณ์และแน่นอนในการช่วยตัวเองจาก Stagefright แต่คุณสามารถใช้โอกาสในการลดโอกาสที่การโจมตีจะสำเร็จได้หากคุณติดอยู่กับ Android รุ่นเก่า นอกจากนี้ยังมีโซลูชัน ROM แบบกำหนดเอง ซึ่งส่วนใหญ่ซิงค์แหล่งที่มากับ AOSP เป็นประจำ ดังนั้น จึงรวมการแก้ไข Stagefright ไว้ด้วย หากคุณใช้งาน ROM ที่ใช้ AOSP ขอแนะนำเป็นอย่างยิ่งให้คุณอัปเดตเป็น ROM รุ่นใหม่ที่รวมแพตช์ Stagefright ไว้ด้วย คุณสามารถใช้ได้ แอพนี้ เพื่อตรวจสอบว่าไดรเวอร์รายวันปัจจุบันของคุณได้รับผลกระทบจาก Stagefright หรือไม่

Android, หลังการแสดงบนเวที

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

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

เนื่องจาก Android M ใกล้จะเปิดตัวสู่ตลาดในแต่ละวัน จึงไม่น่าแปลกใจหาก Google เลือกที่จะแยกส่วนประกอบของ AOSP ออกไปมากขึ้นเรื่อยๆ เพื่อสนับสนุนแพ็คเกจบริการ Play ท้ายที่สุดแล้ว นั่นคือพื้นที่หนึ่งที่ Google ยังคงควบคุมได้อย่างสมบูรณ์หากอุปกรณ์จะจัดส่งพร้อมกับ Google Play Store นี้ มีข้อเสียของตัวเอง ในรูปแบบของการแทนที่พื้นที่เปิดแหล่งที่มาด้วยผนังแหล่งที่มาปิด

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

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

หมายเหตุปิดท้าย

นี่ยังคงเป็นการคาดเดาที่ดีที่สุดเนื่องจากไม่มีวิธีที่สง่างามในการแก้ไขปัญหานี้ หากขาดแนวทางเผด็จการแบบเผด็จการ ก็มักจะมีข้อบกพร่องบางประการในการแก้ไขอยู่เสมอ เนื่องจากมีจำนวนอุปกรณ์ Android ที่มีอยู่มากมาย การติดตามสถานะความปลอดภัยของอุปกรณ์แต่ละเครื่องจึงเป็นงานที่ใหญ่โตมาก ความจำเป็นในชั่วโมงนี้คือการคิดใหม่เกี่ยวกับวิธีอัปเดต Android เนื่องจากวิธีปัจจุบันไม่ใช่วิธีที่ดีที่สุดอย่างแน่นอน พวกเราที่ XDA Developers หวังว่า Android จะยังคงรักษารากฐานของ Open-Source ไว้อย่างแท้จริง ในขณะที่ทำงานร่วมกับแผนซอร์สแบบปิดของ Google

โทรศัพท์ของคุณมีความเสี่ยงต่อ Stagefright หรือไม่? คุณคิดว่าโทรศัพท์ของคุณจะได้รับแพตช์ Stagefright หรือไม่? แจ้งให้เราทราบในความคิดเห็นด้านล่าง!