เครื่องเสมือน (VM)“ แฮ็ค” VM อีกเครื่องหนึ่งที่ใช้งานบนเครื่องจริงได้หรือไม่

คำถาม:

• หาก VM เกิดความเสียหาย (แฮ็ค) ฉันจะต้องเสี่ยงกับ VM ตัวอื่นที่ทำงานบนเครื่องจริงหรือไม่?
• มีปัญหาด้านความปลอดภัยใดบ้างระหว่าง VM ที่ใช้งานบนฟิสิคัลโฮสต์เดียวกัน
• มีรายการจุดอ่อนและ / หรือปัญหาที่อาจเกิดขึ้นหรือไม่

คำเตือน:

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

โปรดให้ข้อมูลจริง, การศึกษา (จริงจัง), ปัญหาที่มีประสบการณ์หรือคำอธิบายทางเทคนิค เฉพาะเจาะจง. อย่าเพียง แต่แสดงความคิดเห็นของคุณ

• ตัวอย่าง:

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

แก้ไข:ฉันยังพบการโจมตี "Flush + Reload" นี้ที่สามารถดึงคีย์ลับ GnuPG บนเครื่องทางกายภาพเดียวกันโดยใช้ประโยชน์จากแคช L3 CPU แม้ว่า GnuPG จะทำงานบนVMอื่น GnuPG ได้รับการแก้ไขตั้งแต่

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

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

• โจมตีไฮเปอร์ไวเซอร์ หากคุณสามารถรับเชลล์ที่มีสิทธิพิเศษอย่างเพียงพอบน hypervisor ที่กำหนดให้กับ VM คุณสามารถควบคุม VM ใด ๆ บนระบบ วิธีการนี้คือค้นหากระแสข้อมูลที่มีอยู่จาก VM ไปยังไฮเปอร์ไวเซอร์และขึ้นอยู่กับไฮเปอร์ไวเซอร์ สิ่งต่างๆเช่นไดรเวอร์ที่ใช้เสมือนจริงการแชร์คลิปบอร์ดเอาต์พุตการแสดงผลและปริมาณการใช้เครือข่ายมักจะสร้างช่องทางประเภทนี้ ตัวอย่างเช่นการโทรที่เป็นอันตรายไปยังอุปกรณ์เครือข่าย paravirtualized อาจนำไปสู่การใช้รหัสโดยอำเภอใจในบริบทไฮเปอร์ไวเซอร์ที่รับผิดชอบในการส่งทราฟฟิกนั้นไปยังไดรเวอร์ NIC แบบฟิสิคัล
• โจมตีฮาร์ดแวร์บนโฮสต์ อุปกรณ์จำนวนมากอนุญาตให้อัปเดตเฟิร์มแวร์และหากเป็นไปได้ที่จะเข้าถึงกลไกสำหรับจาก VM คุณสามารถอัปโหลดเฟิร์มแวร์ใหม่ที่เหมาะกับความตั้งใจของคุณ ตัวอย่างเช่นหากคุณได้รับอนุญาตให้อัปเดตเฟิร์มแวร์ใน NIC คุณสามารถทำให้มันซ้ำซ้อนกับปริมาณการใช้งานสำหรับที่อยู่ MAC หนึ่ง (ของเหยื่อ) แต่ด้วยที่อยู่ MAC ปลายทางอื่น (ของคุณ) ด้วยเหตุนี้ไฮเปอร์ไวเซอร์หลายคนจึงกรองคำสั่งดังกล่าวถ้าเป็นไปได้ ESXi กรองการอัปเดตไมโครโค้ดของ CPU เมื่อเกิดจาก VM
• โจมตีสถาปัตยกรรมของโฮสต์. การโจมตีที่คุณอ้างถึงนั้นเป็นอีกการโจมตีที่สำคัญในการเปิดเผยข้อมูลตามเวลา: มันใช้ประโยชน์จากกลไกการแคชที่ส่งผลกระทบต่อเวลาการดำเนินการเพื่อตรวจสอบข้อมูลที่เหยื่อ VM ใช้ในการดำเนินงาน หัวใจของการจำลองเสมือนคือการแบ่งปันองค์ประกอบ เมื่อมีการแบ่งปันองค์ประกอบความเป็นไปได้ของช่องด้านข้างจะมีอยู่ เท่าที่ VM อื่นบนโฮสต์เดียวกันสามารถมีอิทธิพลต่อพฤติกรรมของฮาร์ดแวร์ในขณะที่ทำงานในบริบทของเหยื่อ VM VM ที่ตกเป็นเหยื่อจะถูกควบคุมโดยผู้โจมตี การโจมตีที่อ้างถึงใช้ประโยชน์จากความสามารถของ VM ในการควบคุมพฤติกรรมของ CPU แคช (สถานะสากลที่ใช้ร่วมกันเป็นหลัก) เพื่อให้การเข้าถึงหน่วยความจำของเหยื่อเวลามีการเปิดเผยข้อมูลที่ถูกต้องมากขึ้น ไม่ว่ารัฐโลกที่ใช้ร่วมกันจะมีอยู่จริง ความเป็นไปได้ของการเปิดเผยยังมีอยู่ ในการก้าวเข้าสู่สมมุติฐานเพื่อเป็นตัวอย่างลองจินตนาการถึงการโจมตีที่จะทำการนวด VMFS ของ ESXi และทำให้ส่วนต่างๆของปริมาณเสมือนอ้างอิงที่อยู่ดิสก์ทางกายภาพเดียวกันหรือการโจมตีซึ่งทำให้ระบบบอลลูนหน่วยความจำเชื่อว่าหน่วยความจำบางส่วนสามารถใช้ร่วมกันได้ ส่วนตัว (ซึ่งคล้ายกับวิธีการหาประโยชน์จากการใช้งานฟรีหรือการจัดสรรสองครั้ง) พิจารณา CPU MSR สมมุติ (การลงทะเบียนเฉพาะรุ่น) ซึ่ง hypervisor ข้าม แต่อนุญาตให้เข้าถึงได้ สิ่งนี้สามารถใช้เพื่อส่งผ่านข้อมูลระหว่าง VMs การแยกการแยกส่วนของไฮเปอร์ไวเซอร์ที่ควรจัดเตรียมไว้ พิจารณาความเป็นไปได้ที่จะใช้การบีบอัดเพื่อให้ส่วนประกอบที่ซ้ำกันของดิสก์เสมือนถูกจัดเก็บเพียงครั้งเดียว - ช่องสัญญาณด้านข้าง (ยากมาก) อาจมีอยู่ในการกำหนดค่าบางอย่างที่ผู้โจมตีสามารถแยกแยะเนื้อหาของดิสก์เสมือนอื่น ๆ ไฮเปอร์ไวเซอร์ทำอะไร แน่นอนว่าไฮเปอร์ไวเซอร์นั้นควรที่จะป้องกันสิ่งนี้และตัวอย่างสมมุติฐานคือบั๊กด้านความปลอดภัยที่สำคัญ แต่บางครั้งสิ่งเหล่านี้ก็ผ่านไป
• โจมตีอื่น ๆ VM โดยตรง หากคุณมีโฮสต์ที่ใกล้เคียงกับเหยื่อของ VM คุณอาจสามารถใช้ประโยชน์จากการควบคุมการเข้าถึงที่ผ่อนคลายหรือการสื่อสารระหว่าง VM โดยเจตนาโดยขึ้นอยู่กับว่ามีการกำหนดค่าโฮสต์ไว้อย่างไรและมีสมมติฐานอะไรบ้างเมื่อปรับใช้การควบคุมการเข้าถึง สิ่งนี้มีความเกี่ยวข้องเพียงเล็กน้อยเท่านั้น แต่มันไม่เกี่ยวข้อง

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

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

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

ตามทฤษฎีแล้ว จุดรวมของไฮเปอร์ไวเซอร์คือการแยกเครื่องเสมือนออกจากกัน

ในทางปฏิบัติมีข้อบกพร่องด้านความปลอดภัย (และอาจเป็นในอนาคต) ในไฮเปอร์ไวเซอร์ต่างๆซึ่งอาจอนุญาตให้เครื่องเสมือนหนึ่งเครื่องส่งผลกระทบต่อไฮเปอร์ไวเซอร์หรือเครื่องเสมือนอื่น ๆ บนโฮสต์เดียวกัน มาตรการความปลอดภัยเช่นsVirt (สำหรับ KVM / QEMU) มีจุดประสงค์เพื่อแก้ไขปัญหานี้

แก้ไข:ฉันคิดว่าหัวข้อนี้ทำไปแล้วเมื่อหลายเดือนที่ผ่านมา แต่เพิ่งได้รับการฟื้นฟูและตอนนี้ OP กำลังขอข้อมูลเพิ่มเติมเกี่ยวกับ 'ความจริงการศึกษาที่ยกมา' เป็นต้นดังนั้นฉันจึงคิดว่าห่า

การใช้ประโยชน์จากลักษณะนี้คือ:

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

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

ต่อไปนี้เป็นบทความที่น่าสนใจตรงข้ามกับข้อเสนอแนะซึ่งมีการดำเนินการโจมตีโดยใช้ไฮเปอร์ไวเซอร์มากกว่าสองสามรายการ

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

นี่คือข้อความที่ตัดตอนมาจากรายงานแนวโน้มและความเสี่ยงของ IBM X-Force 2010 กลางปี:

(โปรดเปิดภาพนี้ในแท็บใหม่เพื่อดูขนาดเต็ม)

สังเกตเห็นเปอร์เซ็นต์ของช่องโหว่ "Escape to hypervisor" ซึ่งฟังดูน่ากลัวสำหรับฉัน โดยปกติคุณต้องการอ่านรายงานที่เหลือเนื่องจากมีข้อมูลจำนวนมากในการสำรองการเรียกร้อง

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

นี่เป็นบทความที่ยอดเยี่ยมจาก Eric Horschman ของ VMware ซึ่งเขาได้ยินมาว่าฉันเป็นวัยรุ่นที่ต่อต้าน Micro-oft แต่ก็ยังเป็นบทความที่ดี ในบทความนี้คุณจะพบกับเกร็ดความรู้เช่นนี้:

ผู้พักอาศัยในเรือนกระจกของ Microsoft มีหินก้อนอื่น ๆ ที่จะโยนเรา Microsoft ชี้ไปที่ CVE-2009-1244 เป็นตัวอย่างของช่องโหว่การฝ่าวงล้อมของผู้เยี่ยมชมใน ESX และ ESXi การใช้ประโยชน์จากการฝ่าวงล้อมของผู้มาเยือนเป็นเรื่องจริงจัง แต่ไมโครซอฟต์กำลังบิดเบือนข้อเท็จจริง VMware ตอบกลับอย่างรวดเร็วเพื่อแก้ไขช่องโหว่ดังกล่าวในผลิตภัณฑ์ของเราและ ESX ได้รับผลกระทบน้อยกว่า Microsoft มากจะทำให้คุณเชื่อว่า:

เล่นลิ้นในหมู่คู่แข่ง แต่สิ่งที่ชัดเจนที่สุดที่เขาพูดในบทความทั้งหมดคือ:

ความจริงก็คือช่องโหว่และการหาช่องโหว่จะไม่หมดไปกับซอฟต์แวร์ระดับองค์กรใด ๆ

Theo de Raddt ที่อ้างอิงได้ ของโครงการ OpenBSD:

คุณไม่ได้โง่อย่างแน่นอนถ้าคุณคิดว่ากลุ่มวิศวกรซอฟต์แวร์ทั่วโลกที่ไม่สามารถเขียนระบบปฏิบัติการหรือแอพพลิเคชั่นที่ไม่มีช่องโหว่ด้านความปลอดภัยสามารถหันไปรอบ ๆ และเขียนเลเยอร์ virtualization โดยที่ไม่มีช่องโหว่ด้านความปลอดภัย

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

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