یک صفحه وب مخرب میتواند مدل هوش مصنوعی محلی شما را در NVIDIA NemoClaw مسموم کند
اخبار داغ فناوری اطلاعات و امنیت شبکهپژوهشگران امنیتی از شناسایی یک نقص جدی در NVIDIA NemoClaw خبر دادهاند که به یک صفحه وب تحت کنترل مهاجم اجازه میدهد بدون نیاز به هیچ احراز هویتی، کنترل نمونه محلی سرویس Ollama — که یک عامل هوش مصنوعی را تغذیه میکند — را در دست بگیرد و دستورات پنهانی را مستقیماً درون خود مدل کاشته کند.
این مکانیزم چیست؟
پشته مرجع متنباز شرکت انویدیا برای اجرای عاملهای هوش مصنوعی، از جمله عامل معروف OpenClaw، درون محیطهای ایزولهشده این شرکت با نام OpenShell است. یکی از بکاندهای پشتیبانیشده این پلتفرم برای اجرای استنتاج محلی (Local Inference)، همان سرویس شناختهشده Ollama است.
این یافتهها توسط شرکت امنیتی Oasis Security کشف و پیش از انتشار عمومی، در اختیار رسانه The Hacker News قرار گرفته است. این شرکت اعلام کرده موضوع را از پیش به تیم واکنش به حوادث امنیتی محصولات انویدیا (PSIRT) گزارش داده است. تا تاریخ ۲۵ اوت ۲۰۲۶، هیچ شناسه CVE برای این آسیبپذیری تخصیص نیافته و هیچ گزارشی از بهرهبرداری فعال از آن در دنیای واقعی ثبت نشده است.
الاد لوز، مدیر تحقیقات Oasis Security، به The Hacker News گفته این مشکل در نسخه v0.0.35 روی سیستمعاملهای macOS و لینوکس برطرف شده است. اما به گفته او، در مسیر ویندوز و WSL همچنان هیچ وصلهای برای این مشکل ارائه نشده و تنها در نسخه v0.0.34، یک نصبکننده ویندوزی افزوده شده که صرفاً یک پیام هشدار نمایش میدهد.
ریشه فنی مشکل: یک تنظیم شبکه در مسیر ویندوز
طبق این گزارش، NemoClaw سرویس Ollama را با تنظیم متغیر OLLAMA_HOST=0.0.0.0:11434 راهاندازی میکند؛ تنظیمی که سرور مدل را به تمام رابطهای شبکه سیستم متصل میکند، نه صرفاً به آدرس محلی (Loopback). این پیکربندی باعث میشود API این سرویس در دسترس قرار گیرد و مهاجم بتواند قالب گفتوگوی مدل (Chat Template) را تغییر دهد؛ تغییری که دستورات پنهان را به تمام مکالمات آینده اعمال میکند.
Oasis Security در گزارش خود این نکته را بهصراحت مطرح کرده که ایزولهسازی محیط اجرا از اندپوینت محافظت میکند، اما تصاحب خود عامل هوش مصنوعی، به معنای تصاحب کامل دسترسیها و ابزارهای آن نیز هست.
پیکربندی متفاوت Ollama بسته به بستر اجرا
بر اساس مستندات رسمی انویدیا و بررسی کد منبع فعلی این پروژه، نحوه مدیریت Ollama در NemoClaw بسته به بستر اجرا متفاوت است:
- میزبانهای غیر-WSL: سرویس Ollama روی آدرس
127.0.0.1:11434باقی میماند و پشت یک پروکسی معکوس محافظتشده با توکن روی آدرس0.0.0.0:11435قرار میگیرد؛ فرایند راهاندازی اولیه نیز هر دیمنی که از قبل روی آدرس دیگری متصل بوده را دوباره به آدرس Loopback بازمیگرداند. - Docker Desktop روی WSL: این مسیر از پروکسی صرفنظر میکند، چراکه کانتینر میتواند از طریق آدرس
host.docker.internalبه آدرس Loopback میزبان دسترسی پیدا کند. - مسیر Ollama روی میزبان ویندوز: در این مسیر، متغیر
OLLAMA_HOSTروی0.0.0.0:11434تنظیم میشود تا کانتینرهای Docker Desktop بتوانند به دیمن دسترسی داشته باشند؛ و هیچ احراز هویتی نیز روی پورت ۱۱۴۳۴ اعمال نمیشود.
راهنمای رسمی یکپارچهسازی Ollama با NemoClaw نیز توصیه میکند هنگام اجرا درون WSL2 یا یک کانتینر، متغیر OLLAMA_HOST روی 0.0.0.0 تنظیم شود؛ در حالی که اتصال این سرویس به آدرس 0.0.0.0 پیشتر نیز بهعنوان تغییری شناخته شده بود که نمونههای Ollama را فراتر از دستگاه محلی در معرض دسترسی قرار میدهد.
چگونه یک صفحه وب میتواند به سرویس محلی نفوذ کند؟
API روی پورت ۱۱۴۳۴ فاقد هرگونه احراز هویت است و برای مسدودسازی درخواستهای برخاسته از مرورگر، به دو لایه میانافزار (Middleware) متکی است. اما زمانی که آدرس اتصال سرویس، آدرس Loopback نباشد، بررسی هدر Host بهطور کامل نادیده گرفته میشود. در ادامه، لایه اشتراکگذاری منابع میانمبدأ (CORS) نیز این درخواست را «هممبدأ» تلقی کرده و آن را مجاز میشمارد؛ چراکه هدرهای Origin و Host هر دو حاوی دامنه مهاجم هستند — وضعیتی که برای صفحهای که مهاجم روی همان پورت ۱۱۴۳۴ میزبانی میکند، کاملاً برقرار است.
نقش کلیدی تکنیک DNS Rebinding
تکنیک DNS Rebinding دقیقاً همین شکاف را پر میکند. در این روش، دامنه تحت کنترل مهاجم ابتدا به سرور خود او و سپس به آدرس 127.0.0.1 (یعنی همان دستگاه قربانی) Resolve میشود، در حالی که مرورگر همچنان این درخواستها را «هممبدأ» تصور میکند و اجازه ارسال آنها را میدهد.
به گفته لوز، این زنجیره کامل حمله، روی سیستمعامل macOS و با مرورگر Firefox، علیه یک نسخه آسیبپذیر از NemoClaw آزمایش و تأیید شده است. راهکار استاندارد برای مقابله با این دسته از حملات، اعتبارسنجی دقیق هدرهای Host و Origin در سمت سرور است.
نکته قابلتوجه این است که حملات DNS Rebinding علیه API سرویس Ollama، پیشتر نیز بهطور مستند شناسایی شده بود. این سرویس در تاریخ ۱۴ مارس ۲۰۲۴ (نسخه v0.1.29) وصلهای برای این مشکل منتشر کرد و شرکت امنیتی NCC Group نیز یک ماه بعد، این آسیبپذیری را تحت شناسه CVE-2024-28224 منتشر کرد. توصیه اصلی آن گزارش، اعتبارسنجی هدر Host در سمت سرور و مجاز شمردن تنها مقادیر از پیش تأییدشده بود.
به گفته لوز، Ollama در واکنش به همان افشای سال ۲۰۲۴، این اعتبارسنجی را به کد خود اضافه کرده بود. اما مشکل اینجاست که این سرویس، هرگاه به آدرسی غیر از Loopback متصل باشد، این اعتبارسنجی را بهطور کامل نادیده میگیرد؛ و آدرس 0.0.0.0 دقیقاً همان تنظیمی است که NemoClaw برای این سرویس به کار میبرد.
نحوه تزریق دستورات پنهان به مدل
پس از دسترسی به API، بار داده مورد استفاده در این گزارش، یک قالب Go تغییریافته را از طریق نقطه پایانی /api/create مینویسد. این قالب، نحوه تبدیل آرایه پیامهای ساختاریافته به متن خام پیش از پردازش توسط مدل را کنترل میکند؛ نسخه مسمومشده این قالب، متنی تحت کنترل مهاجم را به هر پیام سیستمی (System Message) در زمان استنتاج اضافه میکند.
بر اساس این گزارش، دستوراتی که به این شیوه کاشته میشوند، در تمام مکالمات آینده باقی میمانند و حتی در برابر پیام سیستمی اختصاصی خود عامل هوش مصنوعی نیز پایدار میمانند. Oasis Security در اینباره تأکید کرده که سمت کلاینت اساساً قادر به شناسایی یا جلوگیری از این مشکل نیست، چراکه این قالب، یک ویژگی در سطح مدل است که برای مصرفکنندگان API کاملاً نامرئی است.
بررسی مستقل The Hacker News از کد منبع فعلی
بررسی این رسانه از مخزن کد NemoClaw در کامیت 17f0ca3b (تا تاریخ ۲۵ اوت) نشان میدهد پروکسی محلی Ollama، از راهاندازی در برابر یک بکاند که به آدرس Loopback متصل نیست خودداری میکند؛ این رفتار پیشفرض تازه، از نسخه v0.0.106 در تاریخ ۱۰ اوت به این پلتفرم افزوده شده و در صورت فعال شدن، پروکسی با یک کد وضعیت اختصاصی متوقف شده و پیامی هشدار درباره خطر دور زدن کامل بررسی توکن نمایش میدهد. با این حال، این بررسی از طریق تنظیم متغیر NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1 قابل غیرفعالسازی است و در مواردی که امکان اجرای این بررسی وجود نداشته باشد، بهصورت پیشفرض ایمن (Fail Closed) عمل نمیکند.
نکته مهمتر اینجاست که این بررسی، درون خود پروکسی اجرا میشود؛ در حالی که NemoClaw اساساً این پروکسی را روی مسیرهای WSL راهاندازی نمیکند، و پیکربندی میزبان ویندوز دقیقاً یکی از همین مسیرهاست. به همین دلیل، تغییر پیشفرض نسخه v0.0.106 هرگز به مسیر پلتفرمی که در آن آدرس 0.0.0.0 تنظیم شده، نمیرسد.
همین بررسی مستقل هیچ نوع بررسی صحت (Integrity Check) برای قالب گفتوگو در سراسر مخزن کد پیدا نکرده است؛ NemoClaw تنها از نقطه پایانی /api/show سرویس Ollama برای دریافت طول زمینه بومی مدل و قابلیت فراخوانی ابزار اعلامشده آن استفاده میکند، نه برای بررسی صحت قالب.
مستندات رسمی انویدیا به اپراتورها در مسیر میزبان ویندوز توصیه میکند پورت ۱۱۴۳۴ را در معرض شبکه محلی (LAN) یا اینترنت قرار ندهند. اما این توصیه صرفاً دسترسی ورودی از طریق شبکه را پوشش میدهد، در حالی که زنجیره حمله DNS Rebinding اساساً نیازی به چنین دسترسیای ندارد؛ چراکه مرورگری که این درخواستها را ارسال میکند، از پیش روی همان دستگاه میزبان در حال اجراست و به آدرس 127.0.0.1 همان دیمن دسترسی دارد.
بخشی از الگویی تکرارشونده در امنیت عاملهای هوش مصنوعی
مسمومسازی قالب گفتوگوی یک مدل بهگونهای که دستورات پنهان در زمان استنتاج اجرا شوند، پیشتر نیز تحت عنوان «قالبهای گفتوگوی مسموم» مستندسازی شده بود. پژوهشگران Oasis Security همین ماه، تکنیک مشابهی را علیه پلتفرم دیگری با نام Paperclip مستندسازی کرده بودند و همچنین در فوریه امسال، از یک مسیر مشابه میان مرورگر و آدرس محلی (Localhost) برای تصاحب عاملهای محلی OpenClaw استفاده کرده بودند.
این الگوی تکرارشونده نشان میدهد پلتفرمهای محلی هوش مصنوعی — که برای راحتی توسعهدهندگان اغلب بهصورت پیشفرض APIهای بدون احراز هویت را روی شبکه در دسترس قرار میدهند — همچنان یکی از نقاط ضعف تکرارشونده در معماری امنیتی ابزارهای هوش مصنوعی محلی بهشمار میروند.
چرا این آسیبپذیری اهمیت دارد؟
آنچه این مورد را از یک نقص فنی ساده متمایز میکند، ماهیت پایدار و نامرئی حمله است. برخلاف بسیاری از تکنیکهای تزریق دستور (Prompt Injection) که تنها یک مکالمه واحد را تحت تأثیر قرار میدهند، دستکاری مستقیم قالب گفتوگو باعث میشود دستورات مخرب در سطح مدل باقی بمانند و حتی با تغییر پیام سیستمی توسط خود عامل هوش مصنوعی نیز از بین نروند. این ویژگی، شناسایی چنین حملهای را برای کاربر یا حتی توسعهدهنده عامل هوش مصنوعی بهشدت دشوار میکند.
همچنین، این حادثه بار دیگر نشان میدهد صرفاً ایزولهسازی محیط اجرای یک عامل هوش مصنوعی (Sandboxing) برای تأمین امنیت کافی نیست؛ اگر مهاجم بتواند از طریق یک صفحه وب ساده، کنترل زیرساخت مدل را در اختیار بگیرد، تمام دسترسیها و ابزارهایی که آن عامل هوش مصنوعی به آنها متصل است نیز عملاً در اختیار مهاجم قرار میگیرد.
توصیههای امنیتی
- کاربران macOS و لینوکس باید فوراً به نسخه v0.0.35 یا بالاتر NemoClaw ارتقا دهند تا از رفع این مشکل مطمئن شوند.
- کاربران مسیر ویندوز و WSL باید توجه داشته باشند که تاکنون وصلهای برای این پلتفرم منتشر نشده و باید احتیاط لازم را در استفاده از این پیکربندی به کار گیرند.
- در صورت امکان، از اتصال سرویس Ollama به آدرس
0.0.0.0خودداری کرده و در عوض آن را صرفاً به آدرس Loopback (127.0.0.1) محدود کنید. - هنگام مرور وب روی دستگاهی که سرویسهای استنتاج محلی هوش مصنوعی روی آن در حال اجراست، از باز کردن صفحات وب ناشناس یا مشکوک خودداری کنید، چراکه حمله DNS Rebinding نیازی به دسترسی مستقیم شبکهای ندارد و صرفاً با بازدید از یک صفحه مخرب ممکن است آغاز شود.
- پیادهسازی اعتبارسنجی دقیق هدرهای Host و Origin را برای هر سرویس محلی که API بدون احراز هویت ارائه میدهد، در اولویت قرار دهید.
- سازمانهایی که از NemoClaw یا ابزارهای مشابه برای اجرای عاملهای هوش مصنوعی محلی استفاده میکنند، باید مکانیزمهای بررسی صحت قالب گفتوگو و پایش مستمر رفتار مدل را در فرایند استقرار خود لحاظ کنند.
جمعبندی
این آسیبپذیری نمونهای تازه از خطرات پنهان در معماری عاملهای هوش مصنوعی محلی است؛ جایی که یک تنظیم شبکه بهظاهر ساده، در ترکیب با یک تکنیک شناختهشده مانند DNS Rebinding، میتواند به مهاجم اجازه دهد بدون هیچ تعامل مستقیمی با قربانی، فراتر از یک نفوذ لحظهای، دستورات مخرب پایداری را در قلب مدل هوش مصنوعی بکارد. با گسترش روزافزون استفاده از عاملهای هوش مصنوعی محلی در محیطهای توسعه و تولید، توجه دقیق به جزئیات پیکربندی شبکهای این سرویسها، دیگر یک نکته فرعی نیست، بلکه بخشی اساسی از زنجیره امنیتی این ابزارهاست.
برچسب ها: NemoClaw, امنیت_اطلاعات, امنیت_سایبری, Credentials, Cyberattack, cybersecurity, news, NVIDIA