Chrome zero-day: "این اکسپلویت در طبیعت است"، بنابراین اکنون نسخه خود را بررسی کنید

Chrome zero-day: "این اکسپلویت در طبیعت است"، بنابراین اکنون نسخه خود را بررسی کنید

تمبر زمان: 6 ژوئن 2023، 12:28 بعد از ظهر
گره منبع: 2704382
by

آخرین آپدیت کروم گوگل منتشر شد و این بار این شرکت کلماتش را خرد نکرده است در مورد یکی از دو وصله امنیتی که شامل:

گوگل آگاه است که یک سوء استفاده برای CVE-2023-3079 در طبیعت وجود دارد

همانطور که قبلاً اغلب از گوگل دیده‌ایم، هیچ حرف دو درجه‌ای جدایی وجود ندارد که بگوییم این شرکت از گزارش‌های یک سوء استفاده آگاه است.

این بار، "ما خودمان از همه چیز آگاه هستیم" است، که حتی به صراحت تر به "می دانیم که کلاهبرداران در حین صحبت ما از این موضوع سوء استفاده می کنند" ترجمه می شود، با توجه به اینکه گزارش باگ مستقیماً از گروه تحقیقاتی تهدیدات خود گوگل آمده است.

طبق معمول، این نشان می‌دهد که Google در حال بررسی یک حمله فعال (چه علیه خود گوگل، چه علیه برخی سازمان‌های خارجی، ما نمی‌دانیم) بوده است که در آن Chrome توسط یک حفره امنیتی ناشناخته قبلاً تحت کنترل قرار گرفته است.

اشکال به سادگی به شرح زیر است: Confusion را در V8 تایپ کنید. (قابل درک است که گوگل در این مرحله بیشتر از این حرف نمی‌زند.)

همانطور که قبلا توضیح دادیم، الف گیجی نوع اشکال زمانی اتفاق می افتد که شما به یک برنامه داده ای را ارائه می دهید که قرار است به یک روش تجزیه، اعتبارسنجی، پردازش و عمل کند…

... اما بعداً موفق می شوید برنامه را فریب دهید تا داده ها را به روشی متفاوت، غیرمجاز، نامعتبر و بالقوه خطرناک تفسیر کند.

خطرات سردرگمی نوع توضیح داده شده است

تصور کنید که در حال نوشتن یک برنامه به زبان C هستید.

در C، شما معمولاً متغیرها را به صورت جداگانه اعلام می‌کنید، بنابراین نه تنها حافظه را در جایی که می‌توان ذخیره کرد، ذخیره می‌کنید، بلکه به برنامه نشان می‌دهد که چگونه آن متغیرها قرار است استفاده شوند.

مثلا:

 طولانی int JulianDayNumber; کاراکتر امضا شده* نام مشتری;

اولین اعلان متغیر 64 بیت را برای ذخیره یک عدد صحیح قدیمی ساده که نشان دهنده عدد روز نجومی است، ذخیره می کند. (در صورت تعجب، امروز بعدازظهر JDN 23157 است - روزهای جولیان در ظهر شروع می شود، نه نیمه شب، زیرا ستاره شناسان اغلب در شب کار می کنند و نیمه شب وسط روز کاری آنها است.)

دومی 64 بیت را برای ذخیره آدرس حافظه ذخیره می کند که در آن رشته متن نام مشتری را می توان یافت.

همانطور که می‌توانید تصور کنید، بهتر است این دو مقدار را با هم قاطی نکنید، زیرا استفاده از عددی که منطقی است و بی‌خطر است، مانند 23157، استفاده از آن به‌عنوان آدرس حافظه تقریباً مطمئن نیست.

همانطور که از این حافظه خالی یک برنامه ویندوز در حال اجرا می بینید، کمترین آدرس حافظه ای که برای استفاده تخصیص داده شده است از 0x00370000، که در اعشار 3,604,480 است، بسیار بزرگتر از هر عدد روز معقولی.

آدرس‌های حافظه واقعی که توسط ویندوز استفاده می‌شود به‌طور تصادفی در طول زمان تغییر می‌کنند، تا حدس زدن چیدمان حافظه‌تان برای کلاهبرداران سخت‌تر شود، بنابراین اگر بخواهید همان برنامه را اجرا کنید، مقادیری دریافت می‌کنید، اما با این وجود مشابه هستند:

و (اگرچه پایین تصویر بالا است) آدرس‌های حافظه بخش داده‌های کاربر زمان اجرا زمانی که این برنامه از 0x01130000 به 0x01134FFF، نشان دهنده محدوده تاریخ نامحتمل 22 جولای 44631 تا 16 اوت 44687 است.

در واقع، اگر سعی کنید آن دو متغیر را با هم ترکیب کنید، کامپایلر باید سعی کند به شما هشدار دهد، به عنوان مثال مانند این:

 JulianDayNumber = نام مشتری; CustomerName = JulianDayNumber; اخطار: انتساب از نشانگر بدون cast عدد صحیح می سازد هشدار: انتساب نشانگر را از عدد صحیح بدون ریخته می سازد

حالا، اگر تا به حال در C برنامه نویسی کرده باشید، می دانید که برای راحتی، می توانید متغیرها را با چندین تفسیر مختلف با استفاده از union کلمه کلیدی، مانند این:

 union { long long int JulianDayNumer; کاراکتر امضا شده* نام مشتری; } داده ها؛

اکنون می توانید دقیقاً به همان متغیر در حافظه به دو روش مختلف ارجاع دهید.

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

کاری که شما کم و بیش انجام می دهید این است که به کامپایلر اعتراف می کنید که گاهی با داده هایی که به دست آورده اید به عنوان یک تاریخ و در مواقع دیگر به عنوان یک آدرس حافظه برخورد می کنید. شما مسئولیت به خاطر سپردن تفسیر در چه لحظه ای را بر عهده می گیرید در کد

ممکن است تصمیم بگیرید که یک متغیر دوم به نام a داشته باشید tag (معمولا یک عدد صحیح) برای همراهی با شما union برای پیگیری نوع داده هایی که در حال حاضر با آنها کار می کنید، به عنوان مثال:

 struct { int tag; union { long long int JulianDayNumer; کاراکتر امضا شده* نام مشتری; } داده ها؛ } ارزش؛

ممکن است تصمیم بگیرید که چه زمانی value.tag تنظیم شده است 0، داده ها هنوز برای استفاده راه اندازی نشده اند، 1 یعنی شما در حال ذخیره یک تاریخ هستید، 2 یعنی آدرس حافظه است و هر چیز دیگری نشان دهنده خطا است.

خوب، بهتر است اجازه ندهید کسی دیگر با آن کار کند value.tag یا برنامه شما ممکن است به طرز چشمگیری بد رفتار کند.

مثال نگران کننده تر ممکن است چیزی شبیه به این باشد:

 struct { int tag; // 1 = hash, 2 = function pointers union { unsigned char hash[16]; // یا یک ساختار هش تصادفی { void* openfunc; // یا دو void* closefunc که با دقت تایید شده اند. // نشانگرهای کد برای اجرای بعدی } اعتبارسنجی; } } ارزش؛

اکنون، ما همان بلوک حافظه را بیش از حد بارگذاری می کنیم، بنابراین می توانیم گاهی از آن برای ذخیره یک هش 16 بایتی و گاهی برای ذخیره دو اشاره گر 8 بایتی به توابعی استفاده کنیم که برنامه ما بعداً آنها را فراخوانی خواهد کرد.

واضح است، چه زمانی value.tag == 1، خوشحال می شویم که نرم افزار ما هر رشته 16 بایتی را در حافظه اختصاص داده شده برای اتحاد ذخیره کند، زیرا هش ها شبه تصادفی هستند، بنابراین هر مجموعه ای از بایت ها به همان اندازه محتمل است.

اما کی value.tag == 2، کد ما باید بسیار مراقب باشد تا به کاربر اجازه ندهد تا آدرس های تابع نامعتبر، نامعتبر و ناشناخته را برای اجرا در آینده ارائه دهد.

حال تصور کنید که می توانید مقداری را برای این کد ارسال کنید در حالی که برچسب روی 1 تنظیم شده است، بنابراین بررسی و اعتبارسنجی نمی شود…

اما بعداً، درست قبل از اینکه برنامه واقعاً از مقدار ذخیره شده استفاده کند، می‌توانید کد را فریب دهید تا تگ را به 2 تغییر دهید.

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

و این همان چیزی است که در یک اشکال سردرگمی نوع اتفاق می افتد، البته با استفاده از یک مثال ساختگی و ساده شده،

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

چه کاری انجام دهید؟

مطمئن شوید که آخرین نسخه Chrome یا Chromium را دارید.

کروم را می خواهید 114.0.5735.106 یا بعداً در مک و لینوکس و 114.0.5735.110 یا بعد از آن در ویندوز.

مایکروسافت اج که مبتنی بر کرومیوم است نیز تحت تأثیر این باگ قرار گرفته است.

مایکروسافت تاکنون [2023-06-06T16:25:00Z] اشاره کرد که

مایکروسافت از سوء استفاده های اخیر موجود در طبیعت آگاه است. ما فعالانه در حال کار بر روی انتشار یک وصله امنیتی هستیم.

Edge در حال حاضر در نسخه 114.0.1823.37 است، بنابراین هر چیزی شماره گذاری شده است دیرتر از آن باید شامل وصله های CVE-2023-3079 مایکروسافت باشد.

برای بررسی نسخه خود و به اجبار به روز رسانی اگر نسخه ای وجود دارد که هنوز دریافت نکرده اید:

  • گوگل کروم منوی سه نقطه (⋮) > کمک > درباره کروم
  • مایکروسافت لبه. تنظیمات و موارد دیگر (…) > راهنما و بازخورد > درباره مایکروسافت اج

خواهش میکنم.

تمبر زمان:

بیشتر از امنیت برهنه