مهندسان کروم می‌گویند اکثر باگ‌های امنیتی با قابلیت‌های ایمنی حافظه مرتبط هستند

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

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

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

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

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

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

• کد جدید،‌ ورودی‌های غیر قابل اعتماد را دریافت می‌کند
• کد جدید بدون سندباکس اجرا می‌شود
• کد جدید در یک زبان برنامه‌نویسی ناامن نوشته شده است (C یا ++C)

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

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

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

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