شرکت پاسگاه مکانیسم حفاظتی Safe-Linking، که ایجاد اکسپلویت هایی را که تعریف یا تغییر اشاره گرها به بافرهای اختصاص داده شده هنگام اجرای فراخوانی malloc را دستکاری می کنند، دشوار می کند. Safe-Linking امکان بهره برداری از آسیب پذیری ها را به طور کامل مسدود نمی کند، اما با حداقل سربار، ایجاد دسته های خاصی از اکسپلویت ها را به طور قابل توجهی پیچیده می کند، زیرا علاوه بر سرریز بافر قابل بهره برداری، لازم است آسیب پذیری دیگری نیز پیدا شود که باعث نشت اطلاعات در مورد آن می شود. قرار دادن پشته در حافظه
وصله‌هایی که Safe-Linking را پیاده‌سازی می‌کنند برای Glibc (ptmalloc)، uClibc-NG (dlmalloc)، gperftools (tcmalloc) و Google TCMalloc تهیه شده‌اند، و همچنین برای ارتقاء حفاظت در Chromium (در
از سال 2012، Chromium قبلاً در تکنیک حفاظت از MaskPtr با هدف حل همان مشکل ساخته شده است، اما راه حل از Checkpoint عملکرد بالاتری را نشان می دهد.
پچ های پیشنهادی قبلا برای تحویل در نسخه آگوست تایید شده اند و Safe-Linking به طور پیش فرض فعال خواهد شد. uClibc-NG از Safe-Linking پشتیبانی می کند در نسخه 1.0.33 گنجانده شده است و به طور پیش فرض فعال است. تغییرات در gperftools (tcmalloc قدیمی) ، اما به عنوان یک گزینه در نسخه بعدی ارائه خواهد شد.
توسعه دهندگان (tcmalloc جدید) از پذیرش خودداری کرد ، با اشاره به کاهش شدید عملکرد و نیاز به اضافه کردن آزمایشات گسترده برای بررسی منظم اینکه آیا همه چیز طبق انتظار کار می کند. آزمایش توسط مهندسان Checkpoint نشان داد که روش Safe-Linking منجر به مصرف حافظه اضافی نمی شود و عملکرد هنگام انجام عملیات heap به طور متوسط تنها 0.02٪ و در بدترین سناریو 1.5٪ کاهش می یابد (برای مقایسه، سربار در روش استفاده شده در Chromium به عنوان "کمتر از 2٪" تخمین زده می شود). شمول
Safe-Linking منجر به اجرای 2-3 دستورالعمل اسمبلی اضافی در هر بار فراخوانی free() و 3-4 دستورالعمل هر بار malloc() فراخوانی می شود. اجرای مراحل اولیه سازی و تولید مقادیر تصادفی مورد نیاز نیست.
از Safe-Linking نه تنها می توان برای بهبود امنیت پیاده سازی های مختلف heap استفاده کرد، بلکه همچنین برای افزودن کنترل های یکپارچگی به هر ساختار داده ای که از لیست های پیوندی منفرد از اشاره گرها در کنار خود بافرها استفاده می کند، استفاده کرد. پیاده سازی این روش بسیار ساده است و فقط نیاز به افزودن یک ماکرو و اعمال آن به نشانگرهای بلوک بعدی در کد دارد (مثلاً برای Glibc فقط چند خط کد). این روش به تغییرات زیر خلاصه می شود:
+#define PROTECT_PTR(pos, ptr) \
+ ((__نوع (ptr)) (((((اندازه_t) pos) >> 12) ^ ((اندازه_t) ptr)))
+#define REVEAL_PTR(ptr) PROTECT_PTR (&ptr, ptr)
- nextp = p->fd;
+ nextp = REVEAL_PTR (p->fd)؛
...
ماهیت روش استفاده از داده‌های تصادفی از مکانیسم تصادفی‌سازی آدرس ASLR (mmap_base) برای محافظت از لیست‌های پیوندی منفرد مانند Fast-Bins و TCache است. قبل از اعمال مقدار به یک اشاره گر به عنصر بعدی در لیست، تبدیل ماسک را انجام می دهد و تراز صفحه را بررسی می کند. نشانگر با نتیجه عملیات "(L >> PAGE_SHIFT) XOR (P)" جایگزین می شود، که در آن P مقدار اشاره گر و L مکان حافظه است که نشانگر در آن ذخیره می شود.
هنگام استفاده در سیستم (Address Space Layout Randomization) بخشی از بیت های L با آدرس پایه پشته حاوی مقادیر تصادفی است که به عنوان کلید برای رمزگذاری P استفاده می شود (که توسط یک عملیات شیفت 12 بیتی برای صفحات 4096 بایتی استخراج می شود). این دستکاری خطر ربودن اشاره گر در یک اکسپلویت را کاهش می دهد، زیرا اشاره گر به شکل اصلی خود ذخیره نمی شود و جایگزینی آن مستلزم آگاهی از تخصیص پشته است. علاوه بر این، کد وصله حاوی یک بررسی اضافی برای تراز کردن بلوک است که به مهاجم اجازه نمی دهد یک اشاره گر را با یک مقدار غیر تراز جایگزین کند و نیاز به دانش تعداد بیت هایی دارد که تراز شده اند، که در سیستم های 64 بیتی علاوه بر این امکان مسدود کردن را فراهم می کند. 15 از 16 تلاش برای حمله که تراز را در نظر نمی گیرند.
این روش برای محافظت در برابر حملاتی که از بازنویسی جزئی اشاره گر (تغییر بایت های کم)، بازنویسی کامل اشاره گر (تغییر مسیر به کد مهاجم) و تغییر موقعیت لیست در یک آدرس بدون تراز استفاده می کنند، مؤثر است. به عنوان مثال، نشان داده شده است که استفاده از Safe-Linking در malloc اجازه می دهد تا اخیراً بهره برداری را مسدود کند. توسط همین محققان آسیب پذیری در چراغ هوشمند Philips Hue Bridge، ناشی از سرریز بافر است و به شما امکان می دهد کنترل دستگاه را به دست آورید.
منبع: opennet.ru