در نوامبر 2022 آژانس امنیت ملی آمریکا بولتنی در مورد مدیریت امن RAM صادر کرد. اگر به سایر بولتن‌های NSA در باب همین موضوع نگاهی بیاندازید متوجه خواهید شد که آن‌ها بیشتر یا روی رمزگذاری داده متمرکزند یا محافظت از لوپ تولید و سایر مسائل سازمانی. مستقیم پرداختن به توسعه‌دهندگان نرم‌افزاری برای این آژانس حرکتی تماماً غیرمعمول است. اما از آنجایی که این اتفاق افتاده می‌شود واضحاً فهمید مسئله مهمی در کار بوده است. در اصل NSA از توسعه‌دهندگان نرم‌افزاری خواسته تا به زبان‌های برنامه‌نویسی سوئیچ کنند که معماری‌شان به امنیت افزوده موقع کار با مموری اشاره دارد. و در واقع این اتفاق جلوی استفاده از C و C++ را نیز می‌گیرد. در غیر این صورت، توصیه می‌شود مجموعه اقداماتی برای تست نرم‌افزارها انجام شود که طی آن‌ها آسیب‌پذیری‌ها شناسایی شده و جلوی اکسپلویتشان گرفته شود. برای برنامه‌نویس‌ها اینها شاید بدیهیات باشد و این فراخوان NSA هم شاید مستقیم آن‌ها را مورد خطاب قرار نداده است بلکه بیشتر از نمایندگان تجاری یا مدیریتی این درخواست را کرده است.

امنیت مموری

ابتدا سری بزنیم به جدیدریت گزارش از سیر تکاملی تهدید در سه‌ماهه‌ی سوم 2022 و آسیب‌پذیری‌هایی که در حملات سایبری بیشترین استفاده ازشان شد. در صف اول هنوز آسیب‌پذیری CVE-2018-0802 در جزء Equation Editor بسته مایکروسافت آفیس ایستاده است که سال 2018 کشف شد. دلیل وجود آن نیز پردازش غلط داده در رم بود که نتیجه‌اش شد باز شدن داکیومنت ورد خرب که خود لانچ کد دلخواه را به همراه داشت. آسیب‌پذیری دیگر که محبوب دل مهاجمین است CVE-2022-2294 در جزء WebRTC مرورگر گوگل کروم است که با خود اجرای کد دلخواه را داشت. همین باعث شد خطای سرریز بافر بوجود بیاید. آسیب‌پذیری دیگر - CVE-2022-2624- ابزار مشاهده‌گر پی‌دی‌اف کروم را داشت که این نیز به سرریز بافر ختم شد. البته همه آسیب‌پذیری‌های نرم‌افزاری هم دلیلشان مدیریت نادرست رم نیست بلکه منظورمان تعداد خیلی بالایی از آن‌هاست. بولتن NSA به آمار کشف 70 درصدی آسیب‌پذیری‌ها ناشی از مدیریت نادرست مموری اشاره دارد.

چرا چنین اتفاقی می‌افتد؟ اگر مشکل نشتی‌های مموری انقدر جدی است چرا همت نمی‌کنیم و جلوی نوشته شدن کد آسیب‌پذیر را نمی‌گیریم؟ ریشه این مشکل استفاده از زبان‌های برنامه‌نویسی C و C++ است. معماری ان‌ها به توسعه‌دهندگان آزادی زیادی در کار با RAM می‌دهد. اما در کنار آزادی مسئولیت هم هست؛ برنامه‌نویسان C/C++ باید مکانیزم‌هایی را برای نوشتار امن داده و خواندن آن‌ها پیاده‌سازی کنند. در عین حال زبان‌های برنامه‌نویسی سطح بالا مانند C#، Rust, Go و غیره هم می‌توانند این مسئولیت را بر عهده گیرند. نکته این است که موقع کامپایل‌ کردن کد منبع برنامه ابزارهای مدیریت امن مموری خودکار معرفی می‌شود و توسعه‌دهندگان نیازی ندارند روی آن وقت بگذارند. Rust از ابزارهای بیشتری برای بهبود ایمنی استفاده می‌کند تا بدین‌ترتیب جلوی کد احتمالاً خطرناک از کامپایل شدت تا حدی گرفته شود؛ در عین حال خطا به برنامه‌نویس نیز نشان داده می‌شود. البته صرف استفاده از C/C++ وقتی این زبان‌ها برای کارکردهای خاص ضروری باشند -مانند وقتی که برای MCUها یا سایر دستگاه‌ها با محدودیت‌های جدی نیروی رایانش و سایز مموری کد نیاز است- امکان‌پذیر نیست. در صورت مساوی بودن سایر موارد، زبان‌های برنامه نویسی سطح بالا ممکن است منجر به ایجاد برنامه هایی با منابع فشرده تر شوند. اما آمار رایج تهدیدات به ما نشان می‌دهد که حملات اغلب نرم‌افزارهای کاربر رایج (مانند مرورگرها و ویرایشگرهای متن) را هدف قرار می‌دهند که روی رایانه‌های بسیار قدرتمند اجرا می‌شوند (البته در مقایسه با MCUها).

نمی‌شود به این سادگی‌ها زبان برنامه‌نویسی را عوض کرد

NSA به این موضوع واقف است که پایگاه عظیم داده نرم‌افزاری به زبان‌های برنامه‌نویسی ناامنی نوشته شده است که نمی‌شود یک‌شبه به زبان دیگری تغییرش داد. حتی اگر داریم از نوشتن محصول نرم‌افزاری از نقطه‌ی اول صحبت می‌کنیم هم شاید در خصوص یک زبان برنامه‌نویسی خاص نیاز به متودهای توسعه، زیرساخت و تیمی منسجم باشد. بگذارید یک مثال بزنیم: تصور کنید از شما خواسته‌اند چون خانه‌تان قدیمی‌ساخت است آن را عوض کنید. شما می‌دانید سازه قدیمی است و اگر زلزله بیاید پیامدهای منفی خواهد داشت با این حال به زندگی در آن خانه عادت کرده‌اید. تیم توسعه‌دهنده گوگل کروم پستی دارد که در آن صراحتاً اعلام کرده نمی‌تواند در حال حاضر به زبان برنامه‌نویسی دیگری –که در آن امنیت در سازه لحاظ شده است- سوئیچ کند (در این مورد، منظور RUST است). شاید این در آینده ممکن باشد اما در حال حاضر آن‌ها به راهکارهای دیگری نیاز دارند. در همان پست توسعه‌دهندگان گوگل کروم همچنین گفته شده است چرا نمی‌شود اساسی امنیت کد C/C++ را تغییر داد. این زبان‌های برنامه‌نویسی برای حل کردن همه مشکلات کامپایل به طور یکجا طراحی نشده‌اند. برای همین است که بولتن NSA دو مجموعه اقدامات را به عنوان جایگزین در نظر دارند:

تست کد برای آسیب‌پذیری‌های احتمالی با تحلیل دینامیک و استاتیک.
استفاده از قابلیت‌هایی که جلوی اکسپلویت خطای کد را حتی اگر از قبل آنجاست بگیرد.

چالش‌های تغییر

متخصصین فنی با نظر NSA موافقند. متخصصین شاید در مورد اینکه چطور دقیق می‌شود در مواردی که نیاز باشد (الزامات امنیتی برای مثال) به زبان‌های برنامه‌نویسی سطح بالا سوئیچ کرد نظرات مختلف داشته باشند. ابتدا اینکه درک اینکه اگر چنین تغییری رخ دهد شاید سال‌ها زمان ببرد مهم است. دوم اینکه چنین تکاملی بها دارد- هر کسب و کاری آماده پرداخت این بها نیست! مشکل مدیریت ناامن مموری در زبان‌های برنامه‌نویسی با سطح پایین انتزاع، مشکل سیستمی است. فراخوان برای راهکاری مهم لازم است اما توقع هم نمی‌شود داشت هر کسی فردا به توسعه C#، Go، Java، Rust یا Swift روی بیاورد. درست همانطور که نمی‌شود به این سادگی یک شهر یا کشور را عوض کرد! در آخر مشکل مدیریت ناامن مموری شاید بزرگ باشد اما تنها معضل امنیت نرم‌افزاری هم نیست. در چندین دهه وجود صنعت آی‌تی هرگز ایجاد یک سیستم تماماً امن و جهانی برای همه تسک‌ها (به جز راهکارهای به شدت تخصصی) ممکن نبوده. از نقطه‌نظر تجاری، سرمایه‌گذاری در فناوری‌های جدید (با توسعه‌ی مهارت‌های مکاتباتی و استخدام متخصصین باتجربه) با ماکسیمم محافظت از فناوری‌های موجود، عقلانی است. از دریچه توسعه نرم‌افزاری اما این شاید به شکل زبان‌های برنامه‌نویسی جدید و فناوری‌های برای تست کد موجود پدیدار شود. برای سایر کسب و کارها هم می‌شود گفت راهکار خود را به شکل سرمایه‌گذاری روی فناوری‌های جدید برای محافظت در برابر حملات سایبری و نیز تست مداوم قدرت زیرساخت‌های فعلی نشان دهد. به بیانی دیگر رویکرد جامع به ایمنی، بهینه است و تا مد‌ت‌ها هم قرار است همینطور باقی بماند.

منبع: کسپرسکی آنلاین (ایدکو)