คุณกำลังดูเวอร์ชันก่อนหน้าของกระดานข่าวความปลอดภัย สำหรับเวอร์ชันล่าสุดโปรดไปที่ "การเปิดเผยการวิจัยการดำเนินการแบบคาดเดาของตัวประมวลผล"
เกี่ยวกับ: CVE-2017-5715, CVE-2017-5753, CVE-2017-5754
อัปเดตเมื่อ: 05/02/2018 16:30 น. PST
นี่คือการอัปเดตสำหรับปัญหานี้
เคอร์เนลที่ได้รับการอัปเดตสำหรับ Amazon Linux จะพร้อมใช้งานภายในที่เก็บ Amazon Linux EC2 instance ที่เปิดใช้งานด้วยการกำหนดค่าเริ่มต้นของ Amazon Linux ณ เวลาหรือหลังจากวันที่ 13 มกราคม 2018 จะรวมอยู่ในแพคเกจที่ได้รับการอัปเดต ซึ่งรวมถึงการปรับปรุงความปลอดภัยของ Linux แบบโอเพนซอร์สที่มีความเสถียรรุ่นล่าสุดเพื่อจัดการ CVE-2017-5715 ภายในเคอร์เนลและรุ่นใน Kernel Page Table Isolation (KPTI) ที่จัดการ CVE-2017-5754 ซึ่งรวมไว้ก่อนหน้านี้ ลูกค้าต้องอัปเกรดเป็นเคอร์เนลของ Amazon Linux หรือ AMI รุ่นล่าสุดเพื่อลดข้อกังวลระหว่างกระบวนการต่อกระบวนการของ 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.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html
โปรดติดต่อ Support หากคุณต้องการความช่วยเหลือเกี่ยวกับเส้นทางการอัปเกรดอินสแตนซ์ PV ต่างๆ
การอัปเดตสำหรับบริการของ AWS
บริการต่อไปนี้จำเป็นต้องได้รับแพตช์ของ EC2 instance ที่จัดการในนามของลูกค้า ทำงานทั้งหมดให้เสร็จสมบูรณ์ และลูกค้าไม่จำเป็นต้องดำเนินการใดๆ:
- 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 เสร็จสิ้น จำเป็นต้องรีบูตเพื่อให้การอัปเดตมีผล
เราขอแนะนำให้ลูกค้า Linux ที่ไม่ได้ใช้ ECS Optimized AMI ติดต่อผู้จำหน่ายระบบปฏิบัติการ ซอฟต์แวร์ หรือ 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 เราจะปล่อยระบบปฏิบัติการและแพตช์กลไกฐานข้อมูลตามที่ Microsoft จัดเตรียมไว้ให้ ซึ่งช่วยให้ลูกค้าสามารถอัปเกรดได้ในเวลาที่ตนเลือก เราจะอัปเดตกระดานข่าวนี้เมื่อทุกอย่างเสร็จสมบูรณ์ ในระหว่างนี้ ลูกค้าที่เปิดใช้งาน CLR (ปิดใช้งานตามค่าเริ่มต้น) ควรตรวจสอบคำแนะนำของ Microsoft เกี่ยวกับปิดใช้งานส่วนขยาย CLR ที่ 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 ปรับใช้การอัปเดตด้านความปลอดภัยให้กับ WorkSpaces ที่ใช้งานประสบการณ์ Windows 10 บน Windows Server 2016 Windows 10 มีซอฟต์แวร์ Windows Defender AntiVirus ในตัว ซึ่งเข้ากันได้กับการอัปเดตด้านความปลอดภัยเหล่านี้ ลูกค้าไม่จำเป็นต้องดำเนินการเพิ่มเติม
สำหรับ BYOL และลูกค้าที่ปรับเปลี่ยนการตั้งค่าการอัปเดตเริ่มต้น:
โปรดทราบว่าลูกค้าที่ใช้คุณสมบัติ Bring Your Own License (BYOL) ของ WorkSpaces และลูกค้าที่เปลี่ยนแปลงการตั้งค่าการอัปเดตเริ่มต้นใน WorkSpaces ของตนควรปรับใช้การอัปเดตด้านความปลอดภัยที่ Microsoft มอบให้ด้วยตนเอง หากคุณเป็นลูกค้ากลุ่มนี้ โปรดปฏิบัติตามคำแนะนำที่การให้คำปรึกษาด้านความปลอดภัยของ Microsoft ระบุไว้ที่ https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180002 การให้คำปรึกษาด้านความปลอดภัยมีลิงก์ไปยังบทความฐานความรู้สำหรับทั้งระบบปฏิบัติการ Windows Server และไคลเอ็นต์ที่มีข้อมูลเฉพาะเพิ่มเติม
ชุด WorkSpaces ที่ได้รับการอัปเดตจะพร้อมใช้งานกับการอัปเดตด้านความปลอดภัยเร็วๆ นี้ ลูกค้าที่ได้สร้าง Custom Bundles ควรอัปเดตชุดของตนให้มีการอัปเดตด้านความปลอดภัยด้วยตนเอง WorkSpaces ใหม่ใดก็ตามที่เปิดใช้งานจากชุดที่ไม่มีการอัปเดตจะได้รับแพตช์ทันทีที่เปิดใช้งาน เว้นเสียแต่ว่าลูกค้าจะเปลี่ยนแปลงการตั้งค่าการอัปเดตเริ่มต้นใน WorkSpaces หรือติดตั้งซอฟต์แวร์ป้องกันไวรัสที่เข้ากันไม่ได้ ในกรณีที่พวกเขาควรปฏิบัติตามขั้นตอนข้างต้นเพื่อปรับใช้การอัปเดตด้านความปลอดภัยที่ 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"