بررسی آسیب پذیری تازه کشف شده پردازه‌های Intel و تاثیر آن در محیط‌های مجازی

در تاریخ 17 مرداد 1397 (18 آگوست 2018) متخصصان شرکت Intel یک آسیب پذیری جدی با نام L1 Terminal Fault -L1TF را روی طیف وسیعی از پردازنده‌های این شرکت شناسایی کردند. این آسیب پذیری باعث خواهد شد که یک کاربر با دسترسی محلی بتواند از طریق Terminal Page Fault و Side-Channel Analysis، به محتویات L1 Cache پردازنده دسترسی پیدا کند! پردازنده‌های تحت تاثیر این آسیب پذیری عبارتند از:

Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Xeon® Processor D (1500, 2100)

این آسیب پذیری علاوه بر اینکه سیستم عامل‌ها در محیط‌های فیزیکی را تحت تاثیر قرار می‌دهد، باعث آسیب پذیری در محیط‌های مجازی و Hypervisorها نیز خواهد شد. در این پست می‌خواهیم در مورد این آسیب پذیری در محیط‌های مجازی صحبت کنیم.
جهت کسب اطلاعات بیشتر به INTEL-SA-00161 و CVE-2018-3646 مراجعه کنید.

L1 Terminal Fault – VMM 

این آسیب پذیری در محیط‌های مجازی می‌تواند باعث شود یک ماشین مجازیMalicious که در حال حاضر یک Core را در اختیار گرفته (توسط Hypervisor روی آن Schedule شده است)، قادر باشد به واسطه L1 Cache، به اطلاعات سایر ماشین‌های مجازی یا حتی خود VMkernel دسترسی پیدا کند! این مشکل خصوصاً در زمانی که قابلیت Hyperthreading فعال باشد، بیشتر از پیش مشکل ساز خواهد شد.
به طور کلی دو نوع خطر برای این آسیب پذیری متصور خواهد بود:
1. Sequential-Context Attack: در این حالت Malicious VM زمانی که یک Logical Processor (در صورت فعال بودن Hyperthreading) و یا Core Processor را در اختیار می‌گیرد، به محتویات L1 Cache، Context قبلی (ماشین مجازی یا VMkernel) دسترسی خواهد داشت! توجه داشته باشید که در این حالت پردازش قبلی یا به عبارت دقیق‌تر ماشین مجازی یا VMkernel که این Processor را در اختیار داشته، با وجود تحویل منابع به Malicious VM، هنوز اطلاعات خود را در داخل L1 Cache باقی گذاشته است.
حل این مشکل چندان پبچیده نیست! مسلماً لازم است که Hypervisor قبل از تحویل منابع به ماشین مجازی تازه Schedule شده، محتویات L1 Cache پردازش‌ قبلی را خالی کند (مکانیزمی که ESXi برای تحویل حافظه رم هم از قبل استفاده می‌کرد). برای این منظور کافی است Patchها و Updateهای مربوط به ESXi را نصب کنید.
توجه دارید که این کار مشکل Sequential-Context Attack را حل خواهد کرد اما بلاشک خالی شدن اطلاعات Cache کارایی را اندکی کاهش خواهد داد. بر اساس اعلام شرکت VMware این افت کارایی کمتر از 3% خواهد بود!
جدول زیر خلاصه‌ای از نتایج مربوط به افت کارایی پس از انجام بروز رسانی‌های مربوطه است که توسط شرکت VMware تست و اعلام شده است.

Performance Degradation

after applying patch

Application Workload / Guest OS
3% Database OLTP / Windows
3% Database OLTP / Linux
1% Mixed Workload / Linux
1%> Java / Linux
3% VDI / Windows

2. Concurrent-Context Attack: این مدل از حملات مربوط به زمانی است که Hyperthreading روی BIOS و ESXi فعال است. در این شرایط Malicious VM همزمان در کنار یک ماشین مجازی دیگر و یا خود VMkernel در حال اجرا و استفاده از L1 Cache است. واضح است که در این حالت نمی‌توان Cache را پاک سازی کرد! حل این مشکل کمی پیچیده‌تر خواهد بود. شرکت VMware یک قابلیت جدید با نام ESXi Side-Channel-Aware Scheduler معرفی کرده است که در پیاده سازی نسخه اولیه، اجازه نخواهد داد که دو ماشین مجازی روی یک Core همزمان اجرا شوند بلکه فقط VMkernel می‌تواند در کنار VM روی یک Core با قابلیت Hyperthreading قرار بگیرد!
اما دو نکته مهم…
اولاً شخصاً معتقدم که این راه حل هنوز کامل نیست؛ چراکه هنوز خود VMkernel در معرض خطر است. به نظر من حذف کامل این آسیب پذیری نیازمند همکاری شرکت Intel و ارائه راه حل‌های سخت افزاری خواهد بود. شاید هم یک راه حل، حذف صورت مساله و چشم پوشی از مزایای Hyperthreading با غیر فعال سازی آن باشد.
ثانیاً اگر قرار باشد ESXi Side-Channel-Aware Scheduler فعال شود، می‌تواند تاثیر بسیار مخربی در عملکرد محیط شما داشته باشد و Performance را به شدت کاهش دهد (دیگر دو ماشین مجازی بر خلاف گذشته نمی‌توانند همزمان روی یک Core زمانبندی شوند)! متاسفانه این قابلیت تمام امیدها و دانش قبلی ما در رابطه با تخصیص vCPU، نسبت vCPU:PCPU و… را به شکل ویران کننده‌ای به چالش خواهد کشید و شما را در دو راهی بین امنیت و Performance قرار خواهد داد!!
بر اساس اعلام شرکت VMware، حداکثر افت کارایی در صورت فعال سازی ESXi Side-Channel-Aware Scheduler برابر 30% خواهد بود (شخصاً اعتقاد چندانی به صداقت این عدد ندارم!). دو جدول زیر خلاصه‌ای از نتایج مربوط به این آزمایشات را نمایش می‌دهد.

Performance Degradation after enabling the ESXi SCA Scheduler Remaining usable Host CPU Capacity before enabling ESXi SCA Scheduler Host CPU Utilization before Enabling 
the ESXi SCA Scheduler
Application Workload / 
Guest OS
32% 0% 90% OLTP Database /
Linux
20% 15%~ 77%
1% 30%~ 62%
Performance degradation after enabling the ESXi
Side-Channel-Aware Scheduler
Application Workload / Guest OS
32% Database OLTP / Windows
32% Database OLTP / Linux (with vSAN)
25% Mixed Workload / Linux
22% Java / Linux
30% VDI / Windows

اگر در محیط مجازی شما یکی از شرایط لیست زیر برقرار باشد، احتمالاً با فعال سازی ESXi Side-Channel-Aware Scheduler، با مشکلاتی مواجه خواهید شد و نیاز خواهد بود که یا از این کار منصرف شوید، یا اینکه در این شرایط بد اقتصادی بودجه بیشتری تخصیص داده و منابع پردازشی خود را افزایش دهید!
• VMهایی دارید که تعداد vCPU تخصیص داده شده به آن‌ها بیشتر از Physical Coreهای موجود سرور است (قبلاً Logical Processor برای ما ملاک بود).
• VMهایی دارید که Latency-Sensitive را برای آن‌ها تنظیم کرده‌ایم.
• سرورهایی داریم که میانگین CPU Usage آن‌ها از 70% بیشتر است.
• کلاستری دارید که در شرایطی نظیر Rolling Upgrade، میانگین CPU Usage به 100% نزدیک می‌شود.

اگر هنوز هم بین دو راهی فعال سازی یا عدم فعال سازی این قابلیت امنیتی قرار گرفته‌اید، نگاهی به درخت تصمیم زیر بیندازید….

همانطور که در شکل مشاهده می‌کنید، عدم فعال سازی این قابلیت، منوط به ارزیابی‌های دقیق امنیتی (Risk Assessment) و اعتماد کامل به محیط است. در هر صورت VMware عدم فعال سازی را به هیچ وجه توصیه نکرده است!
همچنین شرکت VMware در راستای کمک به انجام فرآیند تصمیم گیری و فعال سازی ESXi Side-Channel-Aware، ابزاری با نام HTAware Mitigation Tool معرفی کرده است که با مانیتورینگ محیط شما و شناسایی مشکلات بالقوه در صورت فعال سازی این قابلیت، شما را در تصمیم گیری کمک خواهد نمود. پیشنهاد میکنم حتماً از این ابزار استفاده کنید! راهنمای کاملی از این ابزار و همچنین لیک دانلود در KB56931 موجود است.
در نهایت در صورتی که تصمیم نهایی خود را گرفتید و خواستید ESXi Side-Channel-Aware را فعال کنید کافی است، سرور ESXi خود را انتخاب کنید، به قسمت Configuration و سپس Settings رفته و Advanced System Settings را انتخاب کنید. دکمه Edit را بزنید و VMkernel.Boot.hyperthreadingMitigation را از false به true تغییر دهید و یا از دستور زیر استفاده کنید.

esxcli system settings kernel set -s hyperthreadingMitigation -v TRUE

جهت کسب اطلاعات بیشتر به KB55806 و KB55767 مراجعه فرمایید.