เกี่ยวกับ: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754
อัปเดตเมื่อ: 5/3/2018 15:00 น. เวลามาตรฐานแปซิฟิก
นี่คือการอัปเดตสำหรับปัญหานี้
เคอร์เนลที่อัปเดตแล้วสำหรับ Amazon Linux ใช้งานได้แล้วภายในที่เก็บของ Amazon Linux EC2 instance ที่เปิดใช้งานด้วยการกำหนดค่าเริ่มต้นของ Amazon Linux ณ วันที่หรือหลังจากวันที่ 13 มกราคม 2018 จะรวมอยู่ในแพคเกจที่ได้รับการอัปเดต ซึ่งรวมถึงการปรับปรุงความปลอดภัยของ Linux แบบโอเพนซอร์สที่มีความเสถียรรุ่นล่าสุดเพื่อจัดการ CVE-2017-5715 ภายในเคอร์เนลและรุ่นใน Kernel Page Table Isolation (KPTI) ที่จัดการ CVE-2017-5754 ซึ่งรวมไว้ก่อนหน้านี้ ลูกค้าต้องอัปเกรดเป็น AMI หรือเคอร์เนลของ Amazon Linux รุ่นล่าสุดเพื่อลดข้อกังวลระหว่างกระบวนการต่อกระบวนการของ CVE-2017-5715 และข้อกังวลระหว่างกระบวนการต่อเคอร์เนลของ CVE-2017-5754 ภายในอินสแตนซ์ ดูข้อมูลเพิ่มเติมที่ “การดำเนินการแบบคาดเดาของตัวประมวลผล – การอัปเดตระบบปฏิบัติการ”
โปรดดูข้อมูลเพิ่มเติมที่ “คำแนะนำอินสแตนซ์ PV” เกี่ยวกับอินสแตนซ์เสมือนแบบเพิ่มประสิทธิภาพ (PV) ทางด้านล่าง
Amazon EC2
อินสแตนซ์ทั้งหมดในฟลีต Amazon EC2 ได้รับการป้องกันจากข้อกังวลระหว่างอินสแตนซ์ต่ออินสแตนซ์ที่รู้จักทั้งหมดของ CVE-2017-5715, CVE-2017-5753 และ CVE-2017-5754 ข้อกังวลระหว่างอินสแตนซ์ต่ออินสแตนซ์จะสร้างอินสแตนซ์ข้างเคียงที่ไม่น่าเชื่อถือ ซึ่งอาจอ่านหน่วยความจำของอินสแตนซ์อื่นหรือไฮเปอร์ไวเซอร์ AWS ปัญหานี้ได้รับการแก้ไขสำหรับไฮเปอร์ไวเซอร์ AWS แล้ว และจะไม่มีอินสแตนซ์ที่สามารถอ่านหน่วยความจำของอินสแตนซ์อื่น หรือสามารถอ่านหน่วยความจำของไฮเปอร์ไวเซอร์ AWS ตามที่ระบุไว้ข้างต้น เราสังเกตไม่พบผลกระทบด้านประสิทธิภาพที่สำคัญสำหรับปริมาณงาน EC2 ส่วนใหญ่
ในวันที่ 12 มกราคม 2018 เราปิดใช้งานส่วนไมโครโค้ดของ Intel CPU ใหม่สำหรับแพลตฟอร์มใน AWS เสร็จสมบูรณ์ ซึ่งเราพบปัญหาการหยุดทำงานและลักษณะการทำงานที่ไม่สามารถคาดการณ์ได้อื่นๆ ที่เกิดจากการอัปเดตไมโครโค้ดของ Intel ในจำนวนเล็กน้อย การเปลี่ยนแปลงนี้ลดปัญหาเหล่านี้สำหรับอินสแตนซ์ส่วนน้อย
การดำเนินการของลูกค้าที่แนะนำสำหรับ AWS Batch, Amazon EC2, Amazon Elastic Beanstalk, Amazon Elastic Container Service, Amazon Elastic MapReduce และ Amazon Lightsail
แม้ว่าลูกค้าทั้งหมดจะได้รับการป้องกันตามที่อธิบายไว้ข้างต้น เราขอแนะนำให้ลูกค้าแพตช์ระบบปฏิบัติการอินสแตนซ์ของพวกเขาเพื่อจัดการข้อกังวลระหว่างกระบวนการต่อกระบวนการหรือกระบวนการต่อเคอร์เนลของปัญหานี้ โปรดดูคำแนะนำและวิธีการใช้งานเพิ่มเติมสำหรับ Amazon Linux & Amazon Linux 2, CentOS, Debian, Fedora, Microsoft Windows, Red Hat, SUSE และ Ubuntu ที่ “การดำเนินการแบบคาดเดาของตัวประมวลผล – การอัปเดตระบบปฏิบัติการ”
คำแนะนำอินสแตนซ์ PV
หลังจากการวิจัยอย่างต่อเนื่องและการวิเคราะห์โดยละเอียดสำหรับโปรแกรมแก้ไขระบบปฏิบัติการที่ใช้งานได้เพื่อศึกษาปัญหานี้ เราได้พิจารณาเห็นว่าการป้องกันระบบปฏิบัติการนั้นไม่เพียงพอในการแก้ไขข้อกังวลระหว่างกระบวนการต่อกระบวนการภายในอินสแตนซ์เสมือนแบบเพิ่มประสิทธิภาพ (PV) แม้ว่าอินสแตนซ์ PV จะได้รับการป้องกันโดยไฮเปอร์ไวเซอร์ AWS จากข้อกังวลระหว่างอินสแตนซ์ต่ออินสแตนซ์ตามที่อธิบายไว้ข้างต้นแล้วก็ตาม ขอแนะนำอย่างจริงจังให้ลูกค้าที่กังวลเกี่ยวกับการแยกกระบวนการภายในอินสแตนซ์ PV (เช่น ประมวลผลข้อมูลที่ไม่น่าเชื่อถือ เรียกใช้โค้ดที่ไม่น่าเชื่อถือ โฮสต์ผู้ใช้ที่ไม่น่าเชื่อถือ) ย้ายระบบไปยังอินสแตนซ์ประเภท HVM เพื่อให้ได้รับประโยชน์ด้านความปลอดภัยในระยะยาว
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับความแตกต่างระหว่าง PV กับ HVM (ตลอดจนเอกสารเส้นทางการอัปเกรดอินสแตนซ์) ที่:
https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/virtualization_types.html
โปรดติดต่อฝ่ายสนับสนุน หากคุณต้องการความช่วยเหลือเกี่ยวกับเส้นทางการอัปเกรดสำหรับอินสแตนซ์ PV ใดๆ
การอัปเดตต่อบริการอื่นๆ ของ AWS
บริการต่อไปนี้ที่ต้องมีการแก้ไขอินสแตนซ์ EC2 ที่จัดการในนามของลูกค้า ได้ทำงานทั้งหมดเสร็จสิ้นแล้ว และลูกค้าไม่จำเป็นต้องดำเนินการใดๆ
- Fargate
- Lambda
บริการอื่นๆ ของ AWS ทั้งหมดไม่จำเป็นต้องได้รับการดำเนินการจากลูกค้า นอกจากจะมีการระบุไว้เป็นอย่างอื่นทางด้านล่าง
ECS Optimized AMI
เราได้ปล่อย Amazon ECS Optimized AMI เวอร์ชัน 2017.09.g ซึ่งมีการป้องกัน Amazon Linux ทั้งหมดสำหรับปัญหานี้ เราแนะนำให้ลูกค้า Amazon ECS ทั้งหมดอัปเกรดเป็นเวอร์ชันล่าสุดนี้ ซึ่งพร้อมใช้งานใน AWS Marketplace
ลูกค้าที่เลือกอัปเดตอินสแตนซ์ ECS Optimized AMI ที่มีอยู่ ควรเรียกใช้คำสั่งดังต่อไปนี้เพื่อให้แน่ใจว่าได้รับแพคเกจที่อัปเดตแล้ว:
sudo yum update kernel
เช่นเดียวกับมาตรฐานสำหรับการอัปเดตใดๆ สำหรับเคอร์เนลของ Linux หลังจากที่ yum update ทำงานเสร็จแล้ว จะต้องรีบูตเพื่อให้การอัปเดตมีผล
ขอแนะนำให้ลูกค้า Linux ที่ไม่ได้ใช้ AMI ที่ปรับให้เหมาะสมกับ ECS ปรึกษาผู้จำหน่ายระบบปฏิบัติการ ซอฟต์แวร์ หรือ AMI อื่นๆ/ของบริษัทอื่น เพื่อขอรับการอัปเดตและคำแนะนำตามความจำเป็น สามารถดูคำแนะนำเกี่ยวกับ Amazon Linux ได้ในศูนย์ความปลอดภัยของ Amazon Linux AMI
เราได้ปล่อย Amazon ECS Optimized Windows AMI เวอร์ชัน 2018.01.10 แล้ว ดูรายละเอียดเกี่ยวกับวิธีการปรับใช้แพตช์เพื่อเรียกใช้อินสแตนซ์ที่ “การดำเนินการแบบคาดเดาของตัวประมวลผล – การอัปเดตระบบปฏิบัติการ”
Elastic Beanstalk
เราได้อัปเดตแพลตฟอร์มที่ใช้ Linux ทั้งหมดไว้แล้วเพื่อรวมการป้องกัน Amazon Linux ทั้งหมดสำหรับปัญหานี้ ดูเวอร์ชันแพลตฟอร์มโดยเฉพาะที่บันทึกประจำรุ่น เราขอแนะนำให้ลูกค้า Elastic Beanstalk อัปเดตสภาพแวดล้อมของตนเป็นแพลตฟอร์มเวอร์ชันที่ใช้งานได้ล่าสุด สภาพแวดล้อมที่ใช้การอัปเดตที่มีการจัดการจะได้รับการอัปเดตโดยอัตโนมัติในช่วงกำหนดเวลาการบำรุงรักษาที่ได้กำหนดค่าไว้
แพลตฟอร์มที่ใช้ Windows จะได้รับการอัปเดตเช่นกันเพื่อรวมการป้องกัน EC2 Windows ทั้งหมดสำหรับปัญหานี้ ขอแนะนำให้ลูกค้าอัปเดตสภาพแวดล้อม Elastic Beanstalk ที่ใช้ Windows เป็นการกำหนดค่าแพลตฟอร์มที่ใช้งานได้ล่าสุด
ElastiCache
แต่ละโหนดแคชของลูกค้าที่จัดการโดย ElastiCache ใช้ในการเรียกใช้กลไกแคชสำหรับลูกค้ารายเดียวโดยเฉพาะ โดยไม่มีกระบวนการอื่นๆ ที่ลูกค้าสามารถเข้าถึงได้และลูกค้าจะไม่สามารถเรียกใช้โค้ดกับอินสแตนซ์เบื้องหลังได้ เมื่อ AWS ป้องกันโครงสร้างพื้นฐานที่สนับสนุน ElastiCache เสร็จแล้ว ข้อกังวลระหว่างกระบวนการต่อเคอร์เนลหรือกระบวนการต่อกระบวนการของปัญหานี้จะไม่ทำให้เกิดความเสี่ยงต่อลูกค้า การสนับสนุนกลไกแคช ElastiCache ทั้งคู่ได้รายงานว่ายังไม่มีข้อกังวลเกี่ยวกับกระบวนการภายในที่ทราบในขณะนี้
EMR
Amazon EMR เปิดใช้คลัสเตอร์อินสแตนซ์ของ Amazon EC2 ที่ใช้งาน Amazon Linux ในนามของลูกค้าในบัญชีของลูกค้า ลูกค้าที่กังวลเกี่ยวกับการแยกกระบวนการภายในอินสแตนซ์ของคลัสเตอร์ Amazon EMR ควรอัปเกรดเป็นเคอร์เนล Amazon Linux ล่าสุดตามที่แนะนำข้างต้น เราได้รวมเคอร์เนล Amazon Linux ล่าสุดในรุ่นย่อยใหม่ใน 5.11.1, 5.8.1, 5.5.1 และ 4.9.3 ลูกค้าสามารถสร้างคลัสเตอร์ Amazon EMR ได้ในรุ่นเหล่านี้
สำหรับรุ่น Amazon EMR ปัจจุบันและอินสแตนซ์ที่เกี่ยวข้องที่ทำงานอยู่ที่ลูกค้าอาจมี เราขอแนะนำให้อัปเดตเป็นเคอร์เนล Amazon Linux ล่าสุดตามที่แนะนำข้างต้น สำหรับคลัสเตอร์ใหม่ ลูกค้าสามารถใช้การเริ่มต้นระบบเพื่ออัปเดตเคอร์เนล Linux และรีบูตแต่ละอินสแตนซ์ สำหรับคลัสเตอร์ที่กำลังทำงานอยู่ ลูกค้าสามารถช่วยในการอัปเดตและรีสตาร์ทเคอร์เนล Linux ได้สำหรับแต่ละอินสแตนซ์ในคลัสเตอร์โดยทยอยทำทีละอินสแตนซ์ โปรดทราบว่าการรีสตาร์ทบางกระบวนการอาจส่งผลกระทบต่อแอปพลิเคชันที่กำลังทำงานภายในคลัสเตอร์ได้
RDS
แต่ละอินสแตนซ์ฐานข้อมูลของลูกค้าที่จัดการโดย RDS ใช้ในการเรียกใช้กลไกฐานข้อมูลสำหรับลูกค้ารายเดียวโดยเฉพาะ โดยไม่มีกระบวนการอื่นๆ ที่ลูกค้าสามารถเข้าถึงได้และลูกค้าจะไม่สามารถเรียกใช้โค้ดกับอินสแตนซ์เบื้องหลังได้ เมื่อ AWS ป้องกันโครงสร้างพื้นฐานที่สนับสนุน RDS เสร็จแล้ว ข้อกังวลระหว่างกระบวนการต่อเคอร์เนลหรือกระบวนการต่อกระบวนการของปัญหานี้จะไม่ทำให้เกิดความเสี่ยงต่อลูกค้า การสนับสนุน RDS ของกลไกฐานข้อมูลส่วนใหญ่ยังไม่มีการรายงานข้อกังวลเกี่ยวกับกระบวนการภายในที่ทราบในขณะนี้ รายละเอียดเพิ่มเติมเกี่ยวกับเอนจินฐานข้อมูลอยู่ทางด้านล่าง และลูกค้าไม่จำเป็นต้องดำเนินการใดๆ นอกจากจะมีการระบุไว้เป็นอย่างอื่นทางด้านล่าง
สำหรับอินสแตนซ์ RDS สำหรับฐานข้อมูล SQL Server เราเผยแพร่ OS และแพตช์เอนจินที่มีแพตช์ของ Microsoft ในเอนจินเวอร์ชันต่อไปนี้:
SQL Server 2017 (14.00.3015.40.v1)
SQL Server 2016 (13.00.4466.4.v1)
SQL Server 2014 (12.00.5571.0.v1)
SQL Server 2012 (11.00.7462.6.v1)
SQL Server 2008 R2 (10.50.6560.0.v1)
ลูกค้าควรดูคำแนะนำของ Microsoft เกี่ยวกับการปรับใช้แพตช์เหล่านี้และปรับใช้ตามเวลาที่ต้องการที่:
https://support.microsoft.com/en-us/help/4073225/guidance-for-sql-server
สำหรับ RDS PostgreSQL และ Aurora PostgreSQL นั้น อินสแตนซ์ DB จะทำงานตามการกำหนดค่าเริ่มต้นในปัจจุบัน โดยลูกค้าไม่จำเป็นต้องดำเนินการ เราจะมอบแพตช์ที่เหมาะสมให้กับผู้ใช้ส่วนขยาย plv8 เมื่อพร้อมใช้งาน ในระหว่างนี้ ลูกค้าที่เปิดใช้งานส่วนขยาย plv8 (ซึ่งปิดใช้งานตามค่าเริ่มต้น) ควรพิจารณาปิดใช้งานและตรวจสอบคำแนะนำของ V8 ที่ https://github.com/v8/v8/wiki/Untrusted-code-mitigations
ในขณะนี้ ลูกค้าไม่จำเป็นต้องดำเนินการใดๆ สำหรับ RDS สำหรับ MariaDB, RDS สำหรับ MySQL, Aurora MySQL และ RDS สำหรับอินสแตนซ์ฐานข้อมูล Oracle
VMware Cloud on AWS
ตาม VMware “วิธีแก้ไขที่บันทึกไว้ใน VMSA-2018-0002 แสดงอยู่ใน VMware Cloud on AWS ตั้งแต่ต้นเดือนธันวาคม 2017”
โปรดดูรายละเอียดเพิ่มเติมในบล็อกความปลอดภัย & การปฏิบัติตามข้อกำหนดของ VMware และดูสถานะที่อัปเดตแล้วที่ https://status.vmware-services.io
WorkSpaces
สำหรับการใช้งาน Windows 7 กับลูกค้า Windows Server 2008 R2:
Microsoft ได้ออกการอัปเดตด้านความปลอดภัยใหม่สำหรับ Windows Server 2008 R2 สำหรับปัญหานี้ การส่งมอบการอัปเดตเหล่านี้ให้ได้ผลสำเร็จจะต้องมีซอฟต์แวร์ป้องกันไวรัสที่เข้ากันได้ทำงานบนเซิร์ฟเวอร์ตามที่ Microsoft อธิบายไว้ในการอัปเดตด้านความปลอดภัย: https://support.microsoft.com/en-us/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software ลูกค้า WorkSpaces จำเป็นต้องดำเนินการเพื่อรับการอัปเดตเหล่านี้ โปรดปฏิบัติตามคำแนะนำที่ Microsoft อธิบายไว้ที่ https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution
สำหรับการใช้งาน Windows 10 กับลูกค้า Windows Server 2016:
AWS ได้นำการอัปเดตด้านความปลอดภัยมาใช้กับ WorkSpace ที่ใช้งาน Windows 10 บน Windows Server 2016 Windows 10 มีซอฟต์แวร์ Windows Defender AntiVirus ในตัว ซึ่งเข้ากันได้กับการอัปเดตด้านความปลอดภัยเหล่านี้ ลูกค้าไม่จำเป็นต้องดำเนินการเพิ่มเติม
สำหรับ BYOL และลูกค้าที่มีการปรับเปลี่ยนการตั้งค่าการอัปเดตตามค่าเริ่มต้น:
โปรดทราบว่าลูกค้าที่ใช้คุณสมบัติ Bring Your Own License (BYOL) ของ WorkSpace และลูกค้าที่เปลี่ยนการตั้งค่าการอัปเดตเริ่มต้นใน WorkSpace ควรนำการอัปเดตด้านความปลอดภัยที่จัดให้โดย Microsoft มาใช้ด้วยตนเอง หากคุณเป็นลูกค้ากลุ่มนี้ โปรดปฏิบัติตามคำแนะนำที่ให้มาโดยการให้คำปรึกษาด้านความปลอดภัยของ Microsoft ที่ https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002 การให้คำปรึกษาด้านความปลอดภัยมีลิงก์ไปยังบทความฐานความรู้สำหรับทั้งระบบปฏิบัติการ Windows Server และระบบปฏิบัติการของไคลเอ็นต์ ซึ่งจะให้ข้อมูลเฉพาะเพิ่มเติม
ชุดรวม WorkSpace ที่อัปเดตแล้วจะใช้งานได้พร้อมกับการอัปเดตด้านความปลอดภัยในเร็วๆ นี้ ลูกค้าที่สร้างชุดรวมแบบกำหนดเองควรจะอัปเดตชุดรวมของตนให้รวมการอัปเดตด้านความปลอดภัยด้วยตนเอง WorkSpace ใหม่ใดๆ ที่เปิดใช้จากชุดรวมที่ไม่มีการอัปเดตจะได้รับโปรแกรมแก้ไขในทันทีที่เปิดใช้ เว้นแต่ลูกค้าจะเปลี่ยนการตั้งค่าการอัปเดตตามค่าเริ่มต้นใน WorkSpace ของตน หรือติดตั้งซอฟต์แวร์ป้องกันไวรัสที่เข้ากันไม่ได้ ซึ่งในกรณีนี้ ควรปฏิบัติตามขั้นตอนข้างต้นเพื่อนำการอัปเดตด้านความปลอดภัยที่จัดให้โดย Microsoft มาใช้ด้วยตนเอง
WorkSpaces Application Manager (WAM)
เราขอแนะนำให้ลูกค้าเลือกขั้นตอนการดำเนินการอย่างใดอย่างหนึ่งต่อไปนี้
ตัวเลือกที่ 1: นำการอัปเดตของ Microsoft มาใช้ด้วยตนเองกับอินสแตนซ์ที่กำลังทำงานของ WAM Packager และ Validator โดยปฏิบัติตามขั้นตอนที่ Microsoft ให้ไว้ที่ https://support.microsoft.com/en-us/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution หน้านี้มีคำแนะนำเพิ่มเติมและการดาวน์โหลดที่เกี่ยวข้อง
ตัวเลือกที่ 2: สิ้นสุดการทำงานของอินสแตนซ์ Packager และ Validator ที่มีอยู่ของคุณ เปิดใช้งานอินสแตนซ์ใหม่โดยใช้ AMI ที่ได้รับการอัปเดต ชื่อว่า "Amazon WAM Admin Studio 1.5.1" และ "Amazon WAM Admin Player 1.5.1"