دلیل عمده‌ی باگ‌های امنیتی در کامپیوترهای شخصی به قابلیت‌های ایمنی حافظه مربوط است

مهندسان و متخصصان امنیت کروم در اظهار نظری ادعا کردند که مشکلات ایمنی حافظه در کامپیوترهای شخصی، علت عمده ی باگ های امنیتی هستند.

مهندسان گوگل (Google) در هفته ی گذشته اظهارنظر قابل توجهی پیرامون باگ های امنیتی مطرح کردند. آنها ادعا می کنند که ۷۰ درصد از باگ های رخ داده در کدهای کروم، مرتبط با مدیریت حافظه و ایمنی کاربر هستند. نیمی از ۷۰ درصد ذکر شده، مرتبط با آسیب پذیری هایی موسوم به use- after- free هستند. این مشکلات امنیتی، از مدیریت اشتباه آدرس های حافظه (memory pointer) نشأت می گیرند و امکان نفوذ به ساختارهای داخلی کروم را برای مجرمان سایبری فراهم می کنند.

آمار جدید مهندسان کروم، پس از تحلیل ۹۱۲ باگ امنیتی صورت گرفت که از سال ۲۰۱۵ در نسخه ی پایدار گوگل کروم کشف شده بود. این باگ ها، رتبه بندی ریسک «بالا» یا «بحرانی» داشتند. آمار جدیدی که توسط مهندسان کروم منتشر شد، با آمار شبیه چند وقت پیش مایکروسافت (Microsoft)، هماهنگی دارد. مهندسان مایکروسافت در کنفرانس امنیتی فوریه ی ۲۰۱۹ اعلام کردند که در ۱۲ سال پیش ، ۷۰ درصد از به روزرسانی های امنیتی برای محصولات مایکروسافت، با هدف رفع آسیب پذیری های ایمنی حافظه منتشر شده است.

مشکل همیشگی مدیریت حافظه

هر دو غول دنیای فن آوری، ظاهرا با مشکل مشابهی دست وپنجه نرم می کنند. کارشناسان امنیتی معتقدند دو زبان C و++ C که توسط این شرکت ها بصورت عمده استفاده میشوند، زبان های «ناامن» هستند. زبان های ذکر شده، عمر بالایی دارند و دهه ها پیش ساخته شدند. در دورانی که C و++ C توسعه می یافتند، نفوذهای امنیتی و حمله های سایبری، تهدید مرسومی نبودند و نخستین توسعه دهنده های نرم‌افزار، نگاهی جدّي به آنها نداشتند.

به خاطر بی اعتنایی جدّي به ساختارهای امنیتی زبان های C و++ C، این دو زبان کنترل کامل چگونگی مدیریت آدرس های حافظه را به برنامه نویس ها می دهند. درنتیجه هنگامی که برنامه نویس درحال مدیریت اصول پایه ای حافظه بوده و دچار خطا شود، پیغام خطای جدّي یا خاصی از سیستم دریافت نمی کند. همین خطاهای اولیه ی کدنویسی، منجر به آسیب پذیری های مدیریت حافظه میشوند که در اپلیکیشن های نهایی به چشم می خورند. از میان آسیب پذیری های حاصل نیز میتوان به مواردی موسوم به use- after- free, buffer overflow, race conditions, double free, wild pointers و بسياري موارد مشابه اشاره کرد.

آسیب پذیری های مدیریت حافظه که در بالا به آنها اشاره کردیم، باگ هایی هستند که مجرمان سایبری بیش از همه برای سوءاستفاده و نفوذ به سیستم های قربانی، از آنها بهره می برند. این باگ ها به مجرمان امکان می‌دهند تا کد را در حافظه ی دستگاه ذخیره کنند و درنهایت اپلیکیشن قربانی، آنها را اجرا خواهد کرد (مرورگر، سرور، سیستم عامل و غیره). شرکت MITRE، سازمان مدیریت دیتابیس آسیب پذیری های امنیتی دولت ایالات متحده ، در رتبه بندی که در ابتدای امسال منتشر کرد، فشار بیش از حد به بافر (buffer overflow) را خطرناک ترین آسیب پذیری امنیتی در سیستم ها نامید. دو آسیب پذیری دیگر مرتبط با مدیریت حافظه هم در میان ۱۰ آسیب پذیری خطرناک قرار داشتند (out- of- bounds و use- after- free در رتبه های پنجم و هفتم بودند).

با توسعه و پیشرفت مهندسی نر م افزار در سال های اخیر، توسعه دهنده ها توانایی برطرف کردن اکثر آسیب پذیری های امنیتی و اضافه کردن حفاظ های امنیتی مناسب را آموخته اند. البته آنها هنوز در مدیریت حافظه با چالش روبرو هستند و حفره های امنیتی از آن سمت، هنوز خطرآفرین محسوب می شوند.

گوگل به دنبال حل باگ های حافظه در کروم

گوگل می گوید از مارس ۲۰۱۹، ۱۲۵ مورد از ۱۳۰ آسیب پذیری امنیتی کروم با رتبه بندی شدت «بحرانی»، مرتبط با اشکال در مدیریت حافظه بوده اند. این آمار نشان می دهد که باوجود پیشرفت در مدیریت دیگر انواع آسیب پذیری، مهندسان هنوز در پیدا کردن راهی برای مدیریت بهینه ی حافظه، با چالش روبرو هستند. درنهایت مشکل مدیریت باگ های مرتبط با حافظه به حدی در گوگل بزرگ شده است که مهندسان کروم اکنون باید از رویکردی به اسم«قانون دو (The Rule of 2)» پیروی کنند. طبق قانون ذکر شده، هرگاه مهندسان قابلیت جدیدی برای کروم توسعه می‌دهند، کد آنها نباید بیش از دو شرط زیر را زیر پا بگذارد:

کد جدید، ورودی های غیر قابل اطمینان را دریافت می کند

کد جدید بدون سندباکس اجرا میشود 

کد جدید در یک زبان برنامه نویسی ناامن نوشته شده است (C یا++ C)

شرکت های نرم‌افزاری قبلا تلاش های زيادي انجام داده اند تا مشکل مدیریت حافظه را در C و++ C برطرف کنند. موزیلا از شرکت های پیش گام بود که این فعالیت ها را با پشتیبانی، تبلیغ و پیاده سازی گسترده ی زبان برنامه نویسی Rust انجام داد. امروزه زبان Rust یکی از امن ترین زبان های برنامه نویسی به حساب می آید و بخاطر تلاش های بیشمار ابتدایی موزیلا، جایگزینی عالی برای زبان های C و++ C است. البته موزیلا تنها شرکتی نبود که ناچار به مدیریت و حل چالش های C و++ C شد.

مایکروسافت (Microsoft) از شرکت هاي دیگری است که بصورت جدّي به دنبال جایگزینی برای C و++ C می گردد. آنها از پروژه ی ابتدایی Checked C به صورت جدّي در این مسیر حرکت کردند و امروز هم درحال بررسی امکان استفاده از Rust هستند. بعلاوه، ردموندی ها تلاش می کنند تا نسخه ی اختصاصی خود از زبان امن Rust را توسعه دهند که احتمالا به صورت بخشی داخلی در پروژه ی محرمانه ی Project Verona اجرا خواهد شد.

مایکروسافت در کنفرانس مجازی بیلد در هفته ی گذشته، از موفقیت تلاش های ابتدایی برای جایگزین کردن زبان های C و++ C صحبت کرد. آنها همچنین اعلام کردند که با جدیت، وظیفه ی خود مبنی بر استفاده از یک زبان برنامه نویسی امن را پیگیری می کنند. گوگل نیز در هفته ی گذشته از برنامه های مشابهی خبر داد. اهالی مانتین ویو اعلام کردند که به دنبال برنامه هایی جدی برای حل مشکلات امنیتی حافظه در کروم هستند. به هرحال مرورگر آنها امروز با دراختیار داشتن بیش از ۷۰ درصد از سهم بازار، محبوب ترین مرورگر است و باید هرچه بیشتر روی امنیت آن سرمایه گذاری شود.

مهندسان گوگل همیشه از پشتیبان های جدّي سیستم سندباکس در توسعه ی کروم بودند. آنها ده ها فرایند را در سندباکس خود حفظ می کردد و اخیرا ساختاری به نام Site Isolation هم توسعه داده اند. این قابلیت، منابع هر وب سایت را در سندباکس اختصاصی فرایندها در همان وب سایت، نگه داری می کند. امروز مهندسان گوگل می گویند که به حداکثر قابلیت استفاده از سندباکس رسیده اند. درواقع اگر بیش از این از قابلیت سندباکس استفاده شود، بهره وری و سرعت استفاده از کروم، آسیب می بیند. درنتیجه آنها باید به دنبال راهکارهای جایگزین باشند.

گوگل می گوید برای ارائه ی راهکار جایگزین به جای سیستم سندباکس، به دنبال توسعه ی کتاب خانه های اختصاصی++ C برای کدهای کروم است. کتابخانه هایی که در مقابل باگ های مرتبط با حافظه، امن تر هستند. آنها همچنین پروژه ای به نام MiraclePtr را نیز در دست بررسی دارند که بطور خلاصه برای مدیریت بهتر باگ های use- after- free توسعه یافت. گوگل در پایان نیز اعلام کرد که به دنبال زبان های برنامه نویسی امن تر برای جایگزینی نمونه های موجود هم می رود. از نامزدهای احتمالی آنها میتوان به Rust, Swift, JavaScript, Kotlin و Java اشاره کرد.