การอัปเดต Chrome ล่าสุดของ Google ออกแล้ว และคราวนี้บริษัท ยังไม่ได้สับเปลี่ยนคำพูด เกี่ยวกับแพตช์ความปลอดภัยหนึ่งในสองแพตช์ประกอบด้วย:
Google ทราบดีว่าการใช้ประโยชน์จาก CVE-2023-3079 มีอยู่ในป่า
ไม่มีการใช้คำฟุ่มเฟื่อยแบบ XNUMX องศาอย่างที่เรามักจะเห็นจาก Google มาก่อน เพื่อบอกว่าบริษัท “รับทราบรายงาน” ถึงการแสวงประโยชน์
คราวนี้เป็น "เรารับรู้ทั้งหมดด้วยตัวเอง" ซึ่งแปลได้ตรงกว่าคือ "เรารู้ว่ามิจฉาชีพกำลังใช้สิ่งนี้ในทางที่ผิดขณะที่เราพูด" เนื่องจากรายงานข้อบกพร่องนั้นมาจากกลุ่มวิจัยภัยคุกคามของ Google โดยตรง
ตามปกติ นี่หมายความว่า Google กำลังตรวจสอบการโจมตีที่กำลังดำเนินอยู่ (ไม่ว่าจะกับ Google เองหรือองค์กรภายนอกบางแห่ง เราไม่ทราบ) ซึ่ง Chrome ถูกเจาะโดยช่องโหว่ด้านความปลอดภัยที่ไม่รู้จักก่อนหน้านี้
ข้อบกพร่องอธิบายง่ายๆ ดังนี้: พิมพ์ความสับสนใน V8 (เป็นที่เข้าใจกันว่า Google ไม่ได้พูดอะไรมากไปกว่านี้ในขั้นตอนนี้)
ดังที่เราได้อธิบายไปก่อนหน้านี้ ก พิมพ์สับสน จุดบกพร่องเกิดขึ้นเมื่อคุณจัดหาโปรแกรมที่มีข้อมูลจำนวนมากซึ่งควรจะแยกวิเคราะห์ ตรวจสอบ ประมวลผล และดำเนินการด้วยวิธีเดียว...
…แต่ภายหลังคุณสามารถหลอกลวงให้โปรแกรมตีความข้อมูลด้วยวิธีที่แตกต่างออกไป ไม่ได้รับอนุญาต ไม่ถูกต้อง และอาจเป็นอันตรายได้
อธิบายอันตรายจากความสับสนประเภท
ลองนึกภาพว่าคุณกำลังเขียนโปรแกรมในภาษาซี (ไม่สำคัญว่าคุณจะรู้จักภาษาซีหรือไม่ คุณก็สามารถทำตามได้)
ใน C คุณมักจะประกาศตัวแปรทีละตัว ดังนั้นไม่เพียงแต่จองหน่วยความจำที่สามารถจัดเก็บได้ แต่ยังส่งสัญญาณไปยังโปรแกรมว่าควรใช้ตัวแปรเหล่านั้นอย่างไร
ตัวอย่างเช่น:
ยาวยาว int JulianDayNumber; ลงชื่อ char* ชื่อลูกค้า;
การประกาศตัวแปรแรกสงวนไว้ 64 บิตสำหรับจัดเก็บค่าจำนวนเต็มแบบเก่าธรรมดาซึ่งแสดงถึงจำนวนวันทางดาราศาสตร์ (ในกรณีที่คุณสงสัย บ่ายวันนี้คือ JDN 23157 – วันจูเลียนเริ่มต้นตอนเที่ยงวัน ไม่ใช่เที่ยงคืน เนื่องจากนักดาราศาสตร์มักทำงานในตอนกลางคืน โดยเที่ยงคืนเป็นวันทำงานของพวกเขา)
ส่วนที่สองสงวนไว้ 64 บิตสำหรับจัดเก็บที่อยู่หน่วยความจำซึ่งสามารถพบสตริงข้อความของชื่อลูกค้าได้
อย่างที่คุณจินตนาการได้ คุณไม่ควรผสมค่าทั้งสองนี้เข้าด้วยกัน เพราะตัวเลขที่เหมาะสมและปลอดภัย หากใช้เป็นตัวเลขวัน เช่น 23157 แทบจะไม่ปลอดภัยหากใช้เป็นที่อยู่หน่วยความจำ
ดังที่คุณเห็นจากการถ่ายโอนข้อมูลหน่วยความจำของโปรแกรม Windows ที่กำลังทำงานอยู่ ที่อยู่หน่วยความจำต่ำสุดที่จัดสรรไว้สำหรับการใช้งานจะเริ่มต้นที่ 0x00370000ซึ่งมีค่าเป็นทศนิยม 3,604,480 ซึ่งมากกว่าจำนวนวันที่เหมาะสมใดๆ
ที่อยู่หน่วยความจำจริงที่ใช้โดย Windows จะแปรผันไปตามกาลเวลา เพื่อทำให้รูปแบบหน่วยความจำของคุณยากขึ้นสำหรับมิจฉาชีพที่จะคาดเดา ดังนั้นหากคุณเรียกใช้โปรแกรมเดียวกัน คุณจะได้รับค่าต่างๆ แต่ค่าเหล่านั้นจะคล้ายกัน:
และ (แม้ว่าจะอยู่ด้านล่างของภาพด้านบน) ที่อยู่หน่วยความจำของส่วนข้อมูลผู้ใช้รันไทม์เมื่อโปรแกรมนี้ทำงานจาก 0x01130000 ไปยัง 0x01134FFFซึ่งแสดงถึงช่วงวันที่ที่ไม่น่าเป็นไปได้คือ 22 กรกฎาคม 44631 ถึง 16 สิงหาคม 44687
แน่นอน หากคุณพยายามผสมตัวแปรทั้งสองเข้าด้วยกัน คอมไพเลอร์ควรพยายามเตือนคุณ เช่น:
JulianDayNumber = ชื่อลูกค้า; ชื่อลูกค้า = JulianDayNumber; คำเตือน: การกำหนดสร้างจำนวนเต็มจากตัวชี้โดยไม่ต้องโยน คำเตือน: การกำหนดสร้างตัวชี้จากจำนวนเต็มโดยไม่ต้องโยน
ตอนนี้ ถ้าคุณเคยเขียนโปรแกรมด้วยภาษา C คุณจะรู้ว่าเพื่อความสะดวก คุณสามารถประกาศตัวแปรด้วยการตีความที่แตกต่างกันหลายแบบโดยใช้ union คำหลักเช่นนี้:
ยูเนี่ยน { long long int JulianDayNumer; ลงชื่อ char* ชื่อลูกค้า; } ข้อมูล;
ตอนนี้คุณสามารถอ้างอิงตัวแปรเดียวกันในหน่วยความจำได้สองวิธี
ถ้าคุณเขียน data.JulianDayNumberคุณตีความข้อมูลที่เก็บไว้เป็นจำนวนเต็มได้อย่างน่าอัศจรรย์ แต่การเขียน data.CustomerName บอกคอมไพเลอร์ว่าคุณกำลังอ้างอิงที่อยู่หน่วยความจำ แม้ว่าคุณกำลังเข้าถึงข้อมูลที่เก็บไว้เดียวกัน
สิ่งที่คุณทำ ไม่มากก็น้อย กำลังยอมรับกับคอมไพเลอร์ว่าบางครั้งคุณจะปฏิบัติต่อข้อมูลที่คุณมีเป็นวันที่ และในบางครั้งเป็นที่อยู่หน่วยความจำ และนั่น คุณต้องรับผิดชอบในการจดจำว่าการตีความใดใช้ในช่วงเวลาใด ในรหัส
คุณอาจตัดสินใจที่จะมีตัวแปรที่สองหรือที่เรียกว่า a tag (โดยทั่วไปจะเป็นจำนวนเต็ม) เพื่อไปพร้อมกับคุณ union เพื่อติดตามว่าคุณกำลังทำงานกับข้อมูลประเภทใดอยู่ในขณะนี้ ตัวอย่างเช่น:
struct { แท็ก int; ยูเนี่ยน { long long int JulianDayNumer; ลงชื่อ char* ชื่อลูกค้า; } ข้อมูล; } ค่า;
คุณอาจตัดสินใจว่าเมื่อ value.tag ถูกตั้งค่าเป็น 0ข้อมูลยังไม่ถูกเตรียมใช้งาน 1 หมายความว่าคุณกำลังจัดเก็บวันที่ 2 หมายความว่าเป็นที่อยู่หน่วยความจำ และสิ่งอื่นๆ ที่แสดงถึงข้อผิดพลาด
คุณไม่ควรให้ใครมายุ่งกับเรื่องนั้น value.tag การตั้งค่า มิฉะนั้นโปรแกรมของคุณอาจทำงานผิดพลาดอย่างมาก
ตัวอย่างที่น่ากังวลมากขึ้นอาจเป็นดังนี้:
struct { แท็ก int; // 1 = แฮช, 2 = ตัวชี้ฟังก์ชันยูเนี่ยน { แฮชถ่านที่ไม่ได้ลงชื่อ [16]; // เก็บโครงสร้างแฮชแบบสุ่ม { void* openfunc; // หรือ void* closefunc ที่ผ่านการตรวจสอบอย่างระมัดระวังสองตัว; // ตัวชี้รหัสเพื่อดำเนินการในภายหลัง } ตรวจสอบ; } } ค่า;
ขณะนี้ เรากำลังโอเวอร์โหลดบล็อกหน่วยความจำเดียวกัน ดังนั้นบางครั้งเราจึงสามารถใช้หน่วยความจำนี้เพื่อจัดเก็บแฮชขนาด 16 ไบต์ และบางครั้งเพื่อจัดเก็บพอยน์เตอร์ขนาด 8 ไบต์สองตัวสำหรับฟังก์ชันที่โปรแกรมของเราจะเรียกใช้ในภายหลัง
ชัดเจนเมื่อไหร่ value.tag == 1เรายินดีที่จะให้ซอฟต์แวร์ของเราจัดเก็บสตริงขนาด 16 ไบต์ใดๆ ลงในหน่วยความจำที่จัดสรรไว้สำหรับยูเนี่ยน เนื่องจากแฮชเป็นการสุ่มเทียม ดังนั้นการรวบรวมไบต์ใดๆ จึงมีโอกาสเท่าๆ กัน
แต่เมื่อ value.tag == 2โค้ดของเราจะต้องระมัดระวังเป็นพิเศษ ไม่อนุญาตให้ผู้ใช้ให้ที่อยู่ฟังก์ชันที่ไม่ถูกต้อง ไม่น่าเชื่อถือ และไม่รู้จักเพื่อดำเนินการในภายหลัง
ลองจินตนาการว่าคุณสามารถส่งค่าให้กับรหัสนี้ได้ในขณะที่แท็กถูกตั้งค่าเป็น 1 ดังนั้นจึงไม่ได้รับการตรวจสอบและตรวจสอบความถูกต้อง...
…แต่ในภายหลัง ก่อนที่โปรแกรมจะใช้ค่าที่เก็บไว้จริงๆ คุณสามารถหลอกรหัสให้เปลี่ยนแท็กเป็น 2 ได้
จากนั้นรหัสจะยอมรับที่อยู่ฟังก์ชันที่ไม่ผ่านการตรวจสอบของคุณว่า "รู้จักและยืนยันแล้วว่าปลอดภัย" (แม้ว่าจะไม่ใช่ก็ตาม) และจะส่งการทำงานของโปรแกรมอย่างไว้วางใจไปยังตำแหน่งปลอมในหน่วยความจำที่คุณแอบเลือกไว้ล่วงหน้า
และนั่นคือสิ่งที่เกิดขึ้นในข้อผิดพลาดเกี่ยวกับความสับสนของประเภท แม้ว่าจะใช้ตัวอย่างที่ประดิษฐ์ขึ้นและเรียบง่าย
หน่วยความจำที่จะใช้งานได้อย่างปลอดภัยหากได้รับการจัดการทางเดียวจะถูกส่งไปยังโปรแกรมอย่างมุ่งร้ายเพื่อประมวลผลด้วยวิธีอื่นที่ไม่ปลอดภัย
จะทำอย่างไร?
ตรวจสอบว่าคุณใช้ Chrome หรือ Chromium เวอร์ชันล่าสุด
คุณต้องการ Chrome 114.0.5735.106 หรือใหม่กว่าบน Mac และ Linux และ 114.0.5735.110 หรือใหม่กว่าบน Windows
Microsoft Edge ซึ่งใช้ Chromium ก็ได้รับผลกระทบจากข้อผิดพลาดนี้เช่นกัน
Microsoft มีจนถึงตอนนี้ [2023-06-06T16:25:00Z] ตั้งข้อสังเกตว่า
Microsoft ตระหนักถึงช่องโหว่ล่าสุดที่มีอยู่ในธรรมชาติ เรากำลังทำงานอย่างแข็งขันเพื่อออกแพตช์ความปลอดภัย
ขณะนี้ Edge เป็นเวอร์ชัน 114.0.1823.37 ดังนั้นจึงมีหมายเลขกำกับไว้ ช้ากว่านั้น ควรรวมแพทช์ CVE-2023-3079 ของ Microsoft
วิธีตรวจสอบเวอร์ชันของคุณและบังคับให้อัปเดตหากมีเวอร์ชันที่คุณยังไม่ได้รับ:
- Google Chrome. เมนูสามจุด (⋮) > การช่วยเหลือ > เกี่ยวกับโครม
- Microsoft Edge การตั้งค่าและอื่น ๆ (…) > ความช่วยเหลือและข้อเสนอแนะ > เกี่ยวกับไมโครซอฟต์เอดจ์
ยินดีต้อนรับคุณ
- เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
- เพลโตไอสตรีม. ข้อมูลอัจฉริยะ Web3 ขยายความรู้ เข้าถึงได้ที่นี่.
- การสร้างอนาคตโดย Adryenn Ashley เข้าถึงได้ที่นี่.
- ซื้อและขายหุ้นในบริษัท PRE-IPO ด้วย PREIPO® เข้าถึงได้ที่นี่.
- ที่มา: https://nakedsecurity.sophos.com/2023/06/06/chrome-zero-day-this-exploit-is-in-the-wild-so-check-your-version-now/