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

آ

در تاریخ ۱۷ مرداد ۱۳۹۷ (۱۸ آگوست ۲۰۱۸) متخصصان شرکت Intel یک آسیب پذیری جدی با نام L1 Terminal Fault (L1TF) را روی طیف وسیعی از پردازنده‌های Intel شناسایی کردند.

این آسیب پذیری باعث خواهد شد که یک کاربر با دسترسی محلی بتواند از طریق 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)

۲nd generation Intel® Core™ processors

۳rd generation Intel® Core™ processors

۴th generation Intel® Core™ processors

۵th generation Intel® Core™ processors

۶th generation Intel® Core™ processors

۷th generation Intel® Core™ processors

۸th 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 این افت کارایی کمتر از ۳% خواهد بود!

جدول زیر خلاصه‌ای از نتایج مربوط به افت کارایی پس از انجام بروز رسانی‌های مربوطه است که توسط شرکت VMware تست و اعلام شده است.

Performance Degradation

after applying patch

Application Workload / Guest OS
۳% Database OLTP / Windows
۳% Database OLTP / Linux
۱% Mixed Workload / Linux
<1% Java / Linux
۳% VDI / Windows

 

  1. 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 برابر ۳۰% خواهد بود (شخصاً اعتقاد چندانی به صداقت این عدد ندارم!). دو جدول زیر خلاصه‌ای از نتایج مربوط به این آزمایشات را نمایش می‌دهد.

 

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
۳۲% ۰% ۹۰% OLTP Database /
Linux
۲۰% ~۱۵% ۷۷%
۱% ~۳۰% ۶۲%

 

Performance degradation after enabling the ESXi
Side-Channel-Aware Scheduler
Application Workload / Guest OS
۳۲% Database OLTP / Windows
۳۲% Database OLTP / Linux (with vSAN)
۲۵% Mixed Workload / Linux
۲۲% Java / Linux
۳۰% VDI / Windows

 

اگر در محیط مجازی شما یکی از شرایط لیست زیر برقرار باشد، احتمالاً با فعال سازی ESXi Side-Channel-Aware Scheduler، با مشکلاتی مواجه خواهید شد و نیاز خواهد بود که یا از این کار منصرف شوید، یا اینکه در این شرایط بد اقتصادی بودجه بیشتری تخصیص داده و منابع پردازشی خود را افزایش دهید!

  • VMهایی دارید که تعداد vCPU تخصیص داده شده به آن‌ها بیشتر از Physical Coreهای موجود سرور است (قبلاً Logical Processor برای ما ملاک بود).
  • VMهایی دارید که Latency-Sensitive را برای آن‌ها تنظیم کرده‌ایم.
  • سرورهایی داریم که میانگین CPU Usage آن‌ها از ۷۰% بیشتر است.
  • کلاستری دارید که در شرایطی نظیر Rolling Upgrade، میانگین CPU Usage به ۱۰۰% نزدیک می‌شود.

 

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

 همانطور که در شکل مشاهده می‌کنید، عدم فعال سازی این قابلیت، منوط به ارزیابی‌های دقیق امنیتی (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 مراجعه فرمایید.

درباره نویسنده

حسین تابش

حسین کارشناس ارشد مهندسی فناوری، اطلاعات گرایش شبکه‌های کامپیوتری هستش. نزدیک به ۸ سال میشه که از تکنولوژی مجازی استفاده میکنه و به شدت عاشق این تکنولوژی؛ خصوصا گرایش مجازی سازی سرور، شبکه و امنیت مجازی هستش.

افزودن دیدگاه

This site uses Akismet to reduce spam. Learn how your comment data is processed.

نوشته‌های تازه

آخرین دیدگاه‌ها