در سال‌های اخیر، کارت‌های گرافیکی (GPUs) دیگر فقط ابزار پردازش گرافیک یا بازی نیستند. از آموزش مدل‌های هوش مصنوعی گرفته تا تحلیل داده‌های عظیم، GPUها به بخش کلیدی مراکز داده و زیرساخت‌های ابری تبدیل شده‌اند. اما دقیقاً همین تحول، سطح حمله (attack surface) جدیدی را پدید آورده است. حمله‌ی GPUHammer یکی از تهدیدات پیشرفته‌ در این حوزه است که می‌تواند بدون نیاز به دسترسی سیستمی بالا، حافظه‌ی گرافیکی را هدف قرار دهد — حتی از درون sandbox یا ماشین مجازی.

GPUHammer  چیست؟

حمله‌ی GPUHammer الهام‌گرفته از حملات کلاسیک RowHammer  است، اما با تفاوتی مهم: هدف آن حافظه GDDR (حافظه اختصاصی GPU) است، نه RAM معمولی سیستم.

در این حمله، با ایجاد الگوهای خاصی از دسترسی‌های سریع و تکراری به بلوک‌های حافظه گرافیکی، مهاجم می‌تواند باعث بروز تداخل در سلول‌های حافظه مجاور شده و داده‌ها را بدون مجوز ویرایش یا خراب کند (bit flipping) .

🔍 ویژگی‌های کلیدی GPUHammer

ریشه‌ آسیب‌پذیری:  Bit Flipping ناشی از تداخل الکترومغناطیسی (EMI)

در حافظه‌های DRAM (و به‌ویژه GDDR)، داده‌ها در سلول‌های خازنی ذخیره می‌شوند که در ردیف‌هایی (Rows) سازمان‌دهی شده‌اند. اگر دسترسی‌های پی‌در‌پی به یک ردیف خاص (Row A) با فرکانس بالا انجام شود، میدان‌های الکترومغناطیسی ایجاد‌شده ممکن است باعث نشت شارژ الکتریکی به ردیف‌های مجاور (مثل Row B) شوند. این پدیده باعث تغییر بیت‌های داده‌ای در ردیف مجاور بدون دسترسی مستقیم می‌شود — دقیقاً همان چیزی که در حمله‌ی RowHammer رخ می‌دهد.

در GPUHammer نیز همین اصل حاکم است، با این تفاوت که محیط هدف، حافظه‌ی GDDR5/6/6X است، که به‌طور خاص برای سرعت بالا طراحی شده‌اند و به همین دلیل حساسیت بیشتری به تداخل دارند.

چرا GDDR در برابر چنین حمله‌ای آسیب‌پذیرتر است؟

1. سرعت بسیار بالا (تا 21 Gbps در GDDR6X) :نرخ بالای دسترسی می‌تواند باعث تحریک شدیدتر میدان‌های الکترومغناطیسی شود.
2. عدم طراحی با فرض تهدیدهای امنیتی: بیشتر کارت‌های گرافیک به‌ویژه در معماری قدیمی‌تر (pre-2025)  مکانیزم‌های محافظتی مانند ECC (Error Correction Code) ندارند.
3. نبود سیستم کنترل سخت‌گیرانه در استفاده از GPU توسط VM یا sandbox : GPUها برخلاف CPUها، هنوز به‌طور کامل virtualized نشده‌اند و سطح کنترل بر حافظه‌ی آنها پایین‌تر است.

  چگونه حمله انجام می‌شود؟ مرحله به مرحله

یافتن الگوی فیزیکی دسترسی به حافظه GPU :

✔️ مهاجم با استفاده از CUDA یا WebGL، داده‌هایی را در حافظه GPU تخصیص می‌دهد و سعی می‌کند mapping فیزیکی ردیف‌ها را کشف کند.

✔️ این کار با اجرای تست‌های آماری روی نرخ خطا انجام می‌شود.

ایجاد بار فشرده روی یک یا چند Row هدف (aggressor rows) :

✔️ به‌کمک حلقه‌هایی با الگوی "hammering" مثل for(i=0; i<N; i++) { access(rowA); access(rowB); } مهاجم هزاران بار به یک یا چند ردیف خاص دسترسی پیدا می‌کند.

مشاهده بیت‌های تغییر یافته (victim rows) :

✔️ داده‌ها در ردیف‌های مجاور بررسی می‌شوند. تغییر حتی یک بیت نشان‌دهنده‌ی موفقیت حمله است.

سوءاستفاده از Bit Flip :

✔️ تغییر بیت‌ها می‌تواند منجر به خراب شدن داده، تغییر مقدار پارامتر حساس (مثلاً در مدل ML)، یا bypass کردن چک‌های منطقی در سطح GPU شود.

تست اثبات آسیب‌پذیری در پژوهش‌های اخیر

بر اساس مقاله ارائه‌شده در IEEE S&P 2025، پژوهشگران توانستند با استفاده از کد WebGL اجرا‌شده در مرورگر Chrome، داده‌های حافظه GPU را با موفقیت تغییر دهند بدون نیاز به فرار از sandbox .

آن‌ها نشان دادند که در کارت‌های NVIDIA RTX 3080 و AMD Radeon 6800 XT، حمله GPUHammer  می‌تواند طی چند ثانیه باعث bit flip در داده‌های GPU شود — حتی در حالتی که GPU  توسط ماشین مجازی یا container مدیریت می‌شود.

چرا ECC کافی نیست؟

اگرچه برخی از GPUهای مدرن از ECC (Error Correction Code) پشتیبانی می‌کنند، اما:

✔️ ECC در بسیاری از مدل‌ها به‌صورت پیش‌فرض غیرفعال است.

✔️ ECC فقط تغییرات 1-bit را تشخیص داده و اصلاح می‌کند؛ حملاتی که چندین بیت را تغییر دهند می‌توانند از ECC فرار کنند.

✔️ GDDR ECC معمولاً در سطح معماری GPU نیست، بلکه در سطح کنترلر انجام می‌شود — که آسیب‌پذیر باقی می‌ماند.

نتیجه: ترکیب معماری حافظه حساس +  APIهای GPU-friendly  + نبود ایزولاسیون

GPUHammer  از ترکیب سه فاکتور خطرناک سوءاستفاده می‌کند:

1. معماری حافظه گرافیکی که برای عملکرد بهینه‌شده، نه امنیت.
2. زبان‌های برنامه‌نویسی سطح‌بالا مثل WebGL/CUDA که امکان hammer کردن حافظه را به‌صورت غیرمستقیم فراهم می‌کنند.
3. عدم ایزولاسیون واقعی میان حافظه‌ی GPU کاربران در محیط‌های مولتیتنت ابری.

مقایسه با RowHammer

چرا GPUHammer خطرناک‌تر از RowHammer است؟

با اینکه GPUHammer از نظر مفهومی مشابه RowHammer است (ایجاد تداخل در سلول‌های حافظه از طریق دسترسی مکرر)، اما دلایلی وجود دارد که این تهدید را به‌مراتب خطرناک‌تر می‌کند، به‌ویژه در فضای ابری و زیرساخت‌های مدرن:

🔺  ۱. سطح دسترسی پایین‌تر مورد نیاز

RowHammer  اغلب نیازمند اجرای کد در سطح kernel یا درایور بود؛ در حالی‌که GPUHammer می‌تواند از محیط مرورگر یا ماشین مجازی بدون نیاز به دسترسی سیستمی بالا اجرا شود. همین ویژگی، آن را به تهدیدی با سطح حمله گسترده‌تر تبدیل می‌کند.

🔺  ۲. فضای اجرای حمله در محیط‌های اشتراکی

در محیط‌هایی مثل GPU-as-a-Service (مثل AWS EC2 P4, Azure NDv5) GPU میان چند کاربر به اشتراک گذاشته می‌شود. GPUHammer می‌تواند از طریق یک کاربر مخرب، به داده‌های کاربر دیگر حمله کند — حتی اگر این کاربران در VMهای جداگانه باشند.

🔺  ۳. نبود معماری امنیتی کامل برای GPUها

GPUها معمولاً فاقد ایزوله‌سازی حافظه (memory isolation) سطح بالا هستند. برخلاف CPU که فرآیندهایی مثل ASLR، DEP و TPM را برای حفاظت دارد، GPU اغلب در برابر چنین تهدیدهایی بدون سپر باقی مانده است.

🔺 ۴. سرعت و فرکانس بالاتر حافظه GDDR

حافظه GDDR6/6X با سرعت‌های بسیار بالا (مثلاً 21Gbps) کار می‌کند، که باعث می‌شود در برابر تداخلات الکترومغناطیسی حساس‌تر باشند و حمله با تلاش کمتر به نتیجه برسد.

چه محیط‌هایی بیشترین خطر را دارند؟

حمله‌ی GPUHammer در همه‌ی سیستم‌ها خطرناک است، اما در برخی سناریوها که GPU نقش کلیدی دارد، ریسک چند برابر می‌شود:

زیرساخت‌های ابری مبتنی بر GPU (Cloud GPU)

سرویس‌هایی مثل Amazon EC2, Google Cloud Compute و Microsoft Azure، کارت‌های GPU  قدرتمند را میان کاربران مختلف به اشتراک می‌گذارند. در این حالت، GPUHammer می‌تواند به نقض حریم خصوصی میان کاربران اجاره‌کننده‌ی یک GPU منجر شود.

آموزش مدل‌های هوش مصنوعی (AI / ML Training)

مدل‌های یادگیری عمیق به‌شدت متکی به حافظه GPU هستند. تغییر حتی یک بیت در ساختار وزن‌های یک مدل می‌تواند خروجی نهایی را تغییر داده یا منجر به شکست کامل آموزش شود. GPUHammer می‌تواند با خراب‌کردن داده یا مدل، integrity سیستم را زیر سؤال ببرد.

محیط‌های بازی ابری (Cloud Gaming)

در پلتفرم‌هایی مانند GeForce NOW یا Xbox Cloud، پردازش GPU برای رندر بازی انجام می‌شود و داده‌ها به‌صورت real-time استریم می‌شوند. مهاجم می‌تواند با GPUHammer کیفیت رندر را تخریب کند یا باعث کرش GPU شود.

دسکتاپ‌های مجازی گرافیکی (GPU-based VDI)

در شرکت‌هایی که از دسکتاپ‌های مجازی برای کار گرافیکی، طراحی یا تحلیل استفاده می‌شود (مثلاً Citrix یا VMware Horizon) دستکاری داده‌های گرافیکی یا کدهای GPU می‌تواند به افشای اطلاعات یا اختلال در عملیات منجر شود.

اقدامات امنیتی پیشنهادی

برای تیم‌های SOC و MDR :

✔️ نظارت پیوسته بر بار GPU با ابزارهایی مانند nvidia-smi یا intel_gpu_top  

✔️ فعال‌سازی هشدار برای الگوهای غیرعادی memory access .

✔️ تعریف الگوهای رفتاری (behavioral baselines) برای GPU usage .

برای مدیران دیتاسنتر و DevOps :

✔️ جدا‌سازی سخت‌افزاری GPU بین کاربران در محیط‌های مولتیتنت.

✔️ اجرای GPU passthrough با policyهای محدود و audit دقیق.

✔️ غیرفعال‌سازی direct GPU access در محیط‌های sandbox یا containerهای عمومی.

برای توسعه‌دهندگان نرم‌افزار:

✔️ تحلیل کدهای WebGL، CUDA و OpenCL برای کشف سوءاستفاده‌های احتمالی از الگوی دسترسی به حافظه.

✔️ عدم استفاده از GPU برای پردازش داده‌های حساس در کدهایی که در محیط‌های sandbox یا مرورگر اجرا می‌شوند.

✔️ استفاده از تکنیک‌های rate-limiting در دسترسی به حافظه GPU در برنامه‌های

ابزارها و راهکارهای دفاعی موجود

آینده‌ی امنیت GPUها

در حال حاضر، هیچ patch  نرم‌افزاری جامع برای مقابله با GPUHammer ارائه نشده است. شرکت‌هایی مانند NVIDIA و AMD تحقیقات داخلی خود را آغاز کرده‌اند، اما تا عرضه سخت‌افزارهای مقاوم‌ به تداخل حافظه، آسیب‌پذیری باقی خواهد ماند.

به‌عنوان یک کارشناس امنیت شبکه، توجه ویژه به GPUها در مدل‌های تهدید (Threat Models) و طراحی سیاست‌های جداسازی دقیق برای منابع گرافیکی، اکنون بیش از همیشه ضروری است.

منابع و رفرنس‌ها:

GPUHammer: Flipping Bits in GPUs from Your Web Browser – IEEE S&P 2025

Google Project Zero: Exploring RowHammer Attacks

Cloud Security Alliance: Security Concerns in Shared GPU Environments (2024)