Google สาธิตการใช้ประโยชน์จากช่องโหว่ของ Spectre ผ่านการเรียกใช้ JavaScript ในเบราว์เซอร์

Google ได้เผยแพร่ต้นแบบการหาประโยชน์หลายรายการที่แสดงความเป็นไปได้ในการใช้ประโยชน์จากช่องโหว่ระดับ Spectre เมื่อรันโค้ด JavaScript ในเบราว์เซอร์ โดยข้ามวิธีการป้องกันที่เพิ่มไว้ก่อนหน้านี้ การใช้ประโยชน์สามารถใช้เพื่อเข้าถึงหน่วยความจำของกระบวนการประมวลผลเนื้อหาเว็บในแท็บปัจจุบัน เพื่อทดสอบการทำงานของช่องโหว่ดังกล่าว จึงได้มีการเปิดตัวเว็บไซต์ Leaky.page และโค้ดที่อธิบายตรรกะของงานได้ถูกโพสต์บน GitHub

ต้นแบบที่นำเสนอได้รับการออกแบบมาเพื่อโจมตีระบบด้วยโปรเซสเซอร์ Intel Core i7-6500U ในสภาพแวดล้อมที่มี Linux และ Chrome 88 หากต้องการใช้ช่องโหว่สำหรับสภาพแวดล้อมอื่น จำเป็นต้องมีการแก้ไข วิธีการหาประโยชน์ไม่ได้เฉพาะเจาะจงกับโปรเซสเซอร์ของ Intel - หลังจากดัดแปลงอย่างเหมาะสมแล้ว การใช้ประโยชน์ดังกล่าวได้รับการยืนยันว่าทำงานบนระบบที่มี CPU จากผู้ผลิตรายอื่น รวมถึง Apple M1 ที่ใช้สถาปัตยกรรม ARM หลังจากการปรับเปลี่ยนเล็กน้อย การใช้ประโยชน์ดังกล่าวยังสามารถใช้งานได้ในระบบปฏิบัติการอื่นและในเบราว์เซอร์อื่นที่ใช้ Chromium engine

ในสภาพแวดล้อมที่ใช้โปรเซสเซอร์ Chrome 88 มาตรฐานและ Intel Skylake มาตรฐาน เป็นไปได้ที่จะรั่วไหลข้อมูลจากกระบวนการที่รับผิดชอบในการประมวลผลเนื้อหาเว็บในแท็บ Chrome ปัจจุบัน (กระบวนการเรนเดอร์) ด้วยความเร็ว 1 กิโลไบต์ต่อวินาที นอกจากนี้ ต้นแบบทางเลือกยังได้รับการพัฒนา เช่น การใช้ประโยชน์ที่ช่วยให้สามารถเพิ่มอัตราการรั่วไหลเป็น 8kB/s เมื่อใช้ตัวจับเวลา Performance.now() ด้วยความแม่นยำ 5 ไมโครวินาที (0.005 มิลลิวินาที) โดยต้องเสียค่าใช้จ่ายในการลดความเสถียร ). นอกจากนี้ยังมีการเตรียมเวอร์ชันที่ทำงานด้วยความแม่นยำของตัวจับเวลาหนึ่งมิลลิวินาทีซึ่งสามารถใช้เพื่อจัดระเบียบการเข้าถึงหน่วยความจำของกระบวนการอื่นด้วยความเร็วประมาณ 60 ไบต์ต่อวินาที

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

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

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

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

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

เพื่อลดความเสี่ยง เจ้าของไซต์ได้รับการสนับสนุนให้ใช้ส่วนหัว Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), Cross-Origin Resource Policy (CORP), Fetch Metadata Request, X-Frame- ตัวเลือก X -ประเภทเนื้อหา-ตัวเลือก และคุกกี้ SameSite กลไกเหล่านี้ไม่ได้ป้องกันการโจมตีโดยตรง แต่ช่วยให้คุณสามารถแยกข้อมูลไซต์ออกจากการรั่วไหลไปยังกระบวนการที่สามารถเรียกใช้โค้ด JavaScript ของผู้โจมตีได้ (การรั่วไหลเกิดขึ้นจากหน่วยความจำของกระบวนการปัจจุบัน ซึ่งนอกเหนือจากโค้ดของผู้โจมตี ยังสามารถประมวลผลข้อมูลจากไซต์อื่นที่เปิดในแท็บเดียวกันนั้นได้) แนวคิดหลักคือการแยกการดำเนินการโค้ดของไซต์ในกระบวนการที่แตกต่างจากโค้ดของบุคคลที่สามที่ได้รับจากแหล่งที่ไม่น่าเชื่อถือ เช่น รวมผ่าน iframe



ที่มา: opennet.ru

เพิ่มความคิดเห็น