Meltdown & Specter - การแพตช์เคอร์เนลเกสต์ของไฮเปอร์ไวเซอร์ที่ไม่ตรงกันจะป้องกันการรั่วไหลของหน่วยความจำ cross-VM หรือไม่?


12

24 ชั่วโมงหลังจากที่ปล่อยช่องโหว่ในวงกว้าง Rackspace เงียบเกี่ยวกับ Specter และ Meltdown พวกเขาไม่มีแผนที่จะปะแก้ hypervisors ทั้งหมดของ Xen เซิร์ฟเวอร์แพลตฟอร์มใหม่ทั้งหมดของพวกเขาคือเซิร์ฟเวอร์ HVM ซึ่งมีช่องโหว่ เซิร์ฟเวอร์ PV ที่เก่ากว่านั้นไม่มีช่องโหว่

ฉันได้อัปเดตเคอร์เนล Linux ของผู้เยี่ยมชม HVM ของฉันแล้ว แต่ Rackspace ไม่ได้อัพเดต hypervisors ใด ๆ ของพวกเขา การอัปเดตเคอร์เนลของผู้เยี่ยมชมบนไฮเปอร์ไวเซอร์ที่ไม่ตรงกันจะป้องกันไม่ให้ "คนเลว" VMs เข้าถึงหน่วยความจำที่รั่วไหลออกมาจากโฮสต์ที่ถูกปะแก้ของฉันหรือไม่


1
ดูเพิ่มเติมsecurity.stackexchange.com/q/176709/11291
Michael Hampton

คำตอบ:


12

จากสิ่งที่ฉันเข้าใจเกี่ยวกับช่องโหว่นั้นไม่มี - การโจมตีแคชแบบเก็งกำไรข้ามการป้องกันของ CPU ทั้งหมดจากกระบวนการที่จับหน่วยความจำจากสิ่งใดก็ได้ตามอำเภอใจ

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

แน่นอนว่าคุณไม่ต้องการเสี่ยงต่อการใช้งานเวิร์กโหลดที่ละเอียดอ่อนบนไฮเปอร์ไวเซอร์ที่ไม่ตรงกันทุกประเภทหากคุณไม่ไว้วางใจ VMs ทั้งหมดที่กำลังทำงานอยู่


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

สวัสดีเชนนั่นคือความเชื่อของฉันเช่นกัน คุณมีเอกสารใด ๆ ในการสำรองข้อมูลหรือไม่? จุดเฉพาะเกี่ยวกับหน่วยความจำของแขกที่ได้รับการแก้ไขจะมีความเสี่ยงต่อแขกคนอื่น ๆ บนฮาร์ดแวร์เดียวกัน ขอบคุณ
Danny F

2
@DannyF การอ้างอิงโดยตรงที่สุดที่ฉันสามารถหาได้คือในกระดาษหลอมละลาย - "หน่วยความจำกายภาพของกระบวนการอื่น ๆ เคอร์เนลและในกรณีของการแก้ปัญหา Sandbox ที่ใช้ร่วมกันเคอร์เนล (เช่น Docker, LXC) หรือ Xen ในโหมด paravirtualization หน่วยความจำของเคอร์เนล (หรือไฮเปอร์ไวเซอร์) และอินสแตนซ์ร่วมอื่น ๆ "
Shane Madden

-4

Spectre และ Meltdown

เราจะเริ่มที่ไหน ไม่ดีฉันหมายถึงข่าวประชาสัมพันธ์ที่แย่มากของสิ่งที่อาจมีหรือไม่มีผลกับคอมพิวเตอร์เวิร์กสเตชันเซิร์ฟเวอร์หรือเซิร์ฟเวอร์ในระบบคลาวด์ ใช่มันคือทั้งหมด แต่คุณต้องมีการเข้าถึงซีพียูที่เกี่ยวข้องซึ่งอาจเป็นพีซีหรือโทรศัพท์ที่ดูเหมือนว่า Apple ได้รับการทำตัวอย่าง แต่ให้คิดว่าซีพียู ARM เพื่อให้ทุกแพลตฟอร์มมือถือที่รองรับ (คุณสมบัติ / microcode exposure / การควบคุม CPU จาก OS / etc / etc มากเกินไป)

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

ในเวลานี้วิธีเดียวที่รู้จักในการใช้ประโยชน์จากช่องโหว่เหล่านี้คือจากโลคัล / เข้าถึง CPU โดยตรง (สามารถอยู่ในระยะไกลได้อีกครั้งเมื่อคุณมี SSH / VNC เป็นต้น)

ด้านล่างนี้เป็นแพชที่ฉันได้พบแล้ว

VMWare has released a security advisory for their ESXi, Workstation and Fusion products: VMSA-2018-0002
[https://www.vmware.com/us/security/advisories/VMSA-2018-0002.html][1]

RedHat has released a security advisory for their qemu product:  [https://access.redhat.com/errata/RHSA-2018:0024][1]

Amazon has released a security advisory for their Amazon Linux AMI product: ALAS-2018-939

https://alas.aws.amazon.com/ALAS-2018-939.htm l

ตอนนี้จะต้องมีการตอบสนองที่ดีที่สุดในขณะนี้

เพื่อน BSD ของเราพูดว่าอะไร

ไม่ดี google; (

ตรวจสอบ Powershell สำหรับเดียวกัน;)

เคอร์เนล Linux ตกลงเรามีสัปดาห์ที่น่าสนใจและตอนนี้ทุกคนรู้ว่าทำไมเราจึงรวมแพทช์แยกตาราง x86 หน้าแปลก ๆ เหล่านี้โดยไม่ปฏิบัติตามกฎการกำหนดเวลาการเปิดตัวปกติทั้งหมด

ฉันอาจ / จะกลับมาและแก้ไขโพสต์นี้ ฉันแน่ใจว่าไม่ใช่ปัญหา (จนกว่าจะอยู่ในป่า) จะไม่เป็นปัญหาจริงที่ยาวนาน Google ควรทำตามวันที่เปิดเผยข้อมูลที่นี่จริง ๆ ! -1 สำหรับ Google


"Amazon Linux (AMI)" เป็น distro Linux ของ Amazon ซึ่งได้รับผลกระทบในลักษณะเดียวกับระบบปฏิบัติการทั่วไปอื่น ๆ มีความเกี่ยวข้องมากขึ้นในบริบทนี้คือaws.amazon.com/de/security/security-bulletins/AWS-2018-013 (ส่วนเริ่มต้น) สำหรับการประกาศ EC2 (แพลตฟอร์มเวอร์ชวลไลเซชันของพวกเขา) เนื่องจากคุณดูเหมือนจะพยายามทำรายการโซลูชั่นการจำลองเสมือน
Håkan Lindqvist

1
การอ่านและการอ่านซ้ำนี้ฉันไม่เชื่อว่ามันตอบคำถามได้จริงหรือ? ส่วนใหญ่เป็นเพียงการคุยโวเกี่ยวกับกระบวนการเปิดเผยหรือไม่
Håkan Lindqvist

ฉันขอขอบคุณกองบรรณาธิการและลิงก์สำหรับการแก้ไข แต่คำตอบนี้ทำให้เข้าใจผิดหรืออย่างน้อยก็ทำให้สับสน ฉันเชื่อว่ามันบ่งชี้ว่าสถานการณ์ที่ฉันอธิบายต้องใช้การเข้าถึง xerversver hypervisor ในพื้นที่ซึ่งไม่เป็นความจริง ข้อกำหนดเพียงอย่างเดียวคือคนเลวที่มี VM ของตัวเองบน hypervisor เช่นเดียวกับเหยื่อของ VM
Danny F
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.