เพลโต ดาต้า อินเทลลิเจนซ์
ค้นหาแนวตั้ง & Ai

Windows 11 ยังเสี่ยงต่อการรั่วไหลของข้อมูลภาพ “aCropalypse”

วันที่:

เมื่อวานเราได้เขียนเกี่ยวกับบั๊กในโทรศัพท์ Google Pixel ไปแล้ว ตอนนี้ได้รับการแก้ไขแล้วด้วยผลที่อาจเป็นอันตราย

ผู้ค้นหาจุดบกพร่องรู้สึกตื่นเต้น (และกังวล) ในสิ่งที่พวกเขาพบ จึงตัดสินใจปฏิบัติตามหลักการ BWAIN อย่างสูงสุด โดยเปลี่ยนให้เป็น ข้อผิดพลาดด้วยชื่อที่น่าประทับใจ: aCropalypse.

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

ดังนั้นความหมายเชิงเปรียบเทียบในคำของพจนานุกรม New Oxford American คือ "เหตุการณ์ที่เกี่ยวข้องกับการทำลายล้างหรือความเสียหายในระดับที่น่ากลัวหรือภัยพิบัติ"

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

การ “ครอบตัด” ใน “aCropalypse”

ส่วน "ครอบตัด" ของชื่อมาจากกิจกรรมที่มีแนวโน้มมากที่สุดที่จะเรียกจุดบกพร่อง CVE-2023-20136 ในรูปแบบของ Google: การครอบตัดรูปภาพหรือภาพหน้าจอเพื่อลบส่วนที่ละเอียดอ่อนหรือส่วนที่ไม่ต้องการออกก่อนที่คุณจะแบ่งปัน

พูดอย่างหลวม ๆ คุณสามารถจินตนาการได้ว่าถ้าคุณถ่ายภาพหน้าจอขนาด 1080×1980 ของหน้าจอโทรศัพท์ทั้งหน้าจอ คุณอาจไม่ต้องการโพสต์ภาพทั้งหมดทางออนไลน์หรือส่งภาพทั้งหมดให้เพื่อน

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

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

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

อย่างไรก็ตาม คุณอาจสันนิษฐานได้ว่าหากคุณตัดชิ้นส่วนของต้นฉบับออก บดบังรายละเอียดบางส่วนด้วยบล็อกสีทึบ (ซึ่งบีบอัดได้ง่ายกว่าข้อมูลภาพทั่วไป) และบันทึกภาพใหม่ทับภาพเก่า...

…ว่าภาพใหม่เกือบจะเล็กลงอย่างแน่นอน อาจจะเล็กกว่าต้นฉบับมาก

เพราะสิ่งที่คุณทิ้งไป!

แต่นั่นไม่ใช่สิ่งที่เกิดขึ้นกับโทรศัพท์ Google Pixel อย่างน้อยก็จนกว่าจะถึงการอัปเดตความปลอดภัยของ Android ในเดือนมีนาคม 2023

เขียนทับแต่ไม่ถูกตัดทอน

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

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

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

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

ภาพหน้าจอส่วนใหญ่บันทึกเป็นไฟล์ PNG ย่อมาจาก กราฟิกเครือข่ายแบบพกพาและถูกบีบอัดภายในโดยใช้อัลกอริธึมการบีบอัดที่เรียกกันทั่วไปว่า ยุบ.

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

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

ข้อ จำกัด เหล่านั้นไม่ได้ขึ้นอยู่กับข้อเท็จจริงที่ว่ารูปแบบย้อนกลับไปที่ 1990sเมื่อพื้นที่หน่วยความจำมีค่ามากกว่าวันนี้

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

อาจมีการบูรณะครั้งใหญ่

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

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

…มีโอกาสอย่างชัดเจนที่ข้อมูลที่เหลือในตอนท้าย ซึ่งควรจะถูกตัดออก จะมีส่วนของภาพที่กู้คืนได้ เปิดเผยส่วนที่คุณต้องการลบออกจากภาพอย่างถาวร!

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

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

Windows 11 ก็ได้รับผลกระทบเช่นกัน

ข้อตกลงคือปัญหาของไฟล์ที่ไม่ถูกตัดทอนเมื่อถูกแทนที่ด้วยเวอร์ชันใหม่นี้มีผลกับ Windows 11 ด้วย โดยที่ เครื่องมือ snippingเช่นเดียวกับแอป Google Pixel Markup ที่จะให้คุณครอบตัดรูปภาพโดยไม่ต้องครอบตัดไฟล์ที่บันทึกอย่างถูกต้อง

ตัวอย่างเช่น นี่คือไฟล์ PNG ที่เราสร้างด้วย GIMP และบันทึกด้วยชุดส่วนหัวขั้นต่ำและไม่มีการบีบอัด:

ไฟล์มีขนาด 320×200 พิกเซลของข้อมูล RGB 8 บิต (สามไบต์ต่อพิกเซล) ดังนั้นไฟล์จึงมีความยาว 320x200x3 ไบต์ (192,000) บวกกับส่วนหัวสองสามร้อยไบต์และข้อมูลเมตาอื่นๆ ที่จำกัด รวมเป็นขนาดรวม 192,590 ไบต์ .

ในดัมพ์ฐานสิบหกที่แสดงด้านล่าง คุณจะเห็นว่าข้อมูลมีความยาว 0x20F04E ไบต์ ซึ่งมีค่าเป็นทศนิยม 192,590:

จากนั้นเราก็ครอบตัดมันให้เล็กที่สุดเท่าที่ Snipping Tool จะอนุญาต (ดูเหมือนว่า 48×48 พิกเซลจะเป็นขั้นต่ำ) แล้วบันทึกกลับเข้าไปใหม่ แต่ไฟล์ “ใหม่” กลับมีขนาดเท่ากับไฟล์ 320×200 ที่ไม่ได้บีบอัด!

ในดัมพ์ฐานสิบหกด้านล่าง ส่วนที่ไฮไลต์ด้วยสีชมพูที่ด้านบนคือไฟล์ทั้งหมดที่ครอบตัดควรจะมี โดยมีความยาว 0xBD ไบต์ หรือ 189 ตำแหน่งเป็นทศนิยม

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

เมื่อเราใช้ ลด ปุ่มสำหรับเขียนภายใต้ชื่อไฟล์ใหม่ ไฟล์บีบอัดขนาด 48×48 มีความยาวเพียง 189 ไบต์

โปรดทราบว่าข้อมูลในไฟล์ตรงกับ 189 ไบต์ที่เน้นด้วยสีชมพูในภาพก่อนหน้าอย่างไร:

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

ใส่เพียงแค่ไฟล์ที่ครอบตัดคือ เขียนทับบางส่วนแทนที่จะเป็นจริง แทนที่.

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

จะทำอย่างไร?

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

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


เรียนรู้เกี่ยวกับโหมดเปิดไฟล์ด้วยตัวคุณเอง

รวบรวมรหัสนี้และเรียกใช้

บน Windows คุณสามารถใช้ มินิมอล-ซี, ของเราเอง สร้างดูแลจัดการ ของฟรี คอมไพเลอร์ Tiny Cหากคุณไม่ได้ติดตั้งระบบการพัฒนา

มีขนาดต่ำกว่า 500 KBytes (!) รวมถึงซอร์สโค้ดแบบเต็ม เทียบกับแต่ละกิกะไบต์สำหรับ Visual Studio หรือ Clang สำหรับ Windows

#รวม #รวม int main (โมฆะ) { ถ่าน * az = "ABCDEFGHIJLKMNOPQRSTUVWXYZ"; int fd; // สร้างไฟล์ด้วย AZ // Octal 0666 หมายถึง "อ่าน/เขียนสำหรับทุกคน" // O_CREAT หมายถึงสร้างหากจำเป็น fd = open("blah1.txt",O_WRONLY+O_CREAT,0666); เขียน (fd,az,26); ปิด (fd); // สร้างไฟล์อื่นที่มี AZ fd = open("blah2.txt",O_WRONLY+O_CREAT,0666); เขียน (fd,az,26); ปิด (fd); // เขียน 10 ไบต์โดยไม่ตั้งค่า O_TRUNC // 16 ไบต์ที่เหลือควรยังคงอยู่ fd = open("blah1.txt",O_WRONLY); เขียน (fd,"----------",10); ปิด (fd); // เขียน 10 ไบต์ *ด้วย* ชุด O_TRUNC // ควรตัดข้อมูลเก่าที่เหลือออก fd = open("blah2.txt",O_WRONLY+O_TRUNC); เขียน (fd,"==========",10); ปิด (fd); กลับ 0; }

สังเกตความแตกต่างระหว่างการเปิดไฟล์ที่มีอยู่เพื่อเขียน (O_WRONLY) ที่มีและไม่มีการตั้งค่า O_TRUNC ธง.

พิมพ์เนื้อหาของ blah1.txt และ blah2.txt หลังจากรันโปรแกรมทดสอบ:

C:UsersduckCROP> petcc64 -stdinc -stdlib test.c คอมไพเลอร์ Tiny C - ลิขสิทธิ์ (C) 2001-2023 Fabrice Bellard ถอดโดย Paul Ducklin เพื่อใช้เป็นเครื่องมือการเรียนรู้ เวอร์ชัน petcc64-0.9.27 [0006] - สร้าง 64 บิต PE เท่านั้น -> t1.c -> c:/users/duck/tcc/petccinc/fcntl.h . . . -> C:/Windows/system32/msvcrt.dll -> C:/Windows/system32/kernel32.dll -------------------------- ----- ขนาดไฟล์ virt ส่วน 1000 200 2a0 .text 2000 600 1cc .data 3000 800 18 .pdata -------------------------- ----- <- t1.exe (2560 ไบต์) C:UsersduckCROP> t1.exe C:UsersduckCROP>dir blah*.txt วอลุ่มในไดรฟ์ C ไม่มีป้ายกำกับ Volume Serial Number คือ C001-D00D Directory ของ C:UsersduckCROP 22/03/2023 07:20 น. 26 blah1.txt 22/03/2023 07:20 น. 10 blah2.txt 2 ไฟล์ 36 ไบต์ C:UsersduckCROP> ประเภท blah1.txt ----------KLMNOPQRSTUVWXYZ C:UsersduckCROP> พิมพ์ blah2.txt ==========
จุด_img

ข่าวกรองล่าสุด

จุด_img