امنیت جدی: GnuTLS از OpenSSL پیروی می کند، اشکال حمله زمان بندی را برطرف می کند

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

در کنار آن اشکالات حافظه، یک باگ دوبله نیز گزارش دادیم CVE-2022-4304: زمان بندی اوراکل در رمزگشایی RSA.

در این باگ، یک پیام رمزگذاری شده یکسان را بارها و بارها در یک سرور ارسال می‌کند، اما لایه انتهایی داده‌ها را تغییر می‌دهد تا داده‌ها نامعتبر شود، و در نتیجه نوعی رفتار غیرقابل پیش‌بینی ایجاد می‌شود…

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

همه داده ها به طور یکسان پردازش نمی شوند

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

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

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

از این، شما بسیاری می توانید چیزی در مورد ساختار یا حتی محتوای داده های رمزگذاری نشده اصلی استنباط کنید که قرار است در داخل هر درخواست مکرر مخفی بماند.

حتی اگر بتوانید فقط یک بایت متن ساده استخراج کنید، خب، قرار نیست این اتفاق بیفتد.

باصطلاح حملات زمان بندی از این نوع همیشه دردسرساز هستند، حتی اگر ممکن است لازم باشد میلیون‌ها بسته جعلی ارسال کنید و همه آنها را زمان‌بندی کنید تا شانس بازیابی تنها یک بایت از داده‌های متن ساده را داشته باشید…

چون شبکه‌ها سریع‌تر، قابل پیش‌بینی‌تر هستند و می‌توانند بار بسیار بیشتری را نسبت به چند سال پیش مدیریت کنند.

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

اما «یک میلیون بسته در ساعت بیشتر یا کمتر از حد معمول» به سادگی تغییر خاصی ندارد.

باگ مشابه «اوراکل» در GnuTLS

خب، همان شخصی که اشکال زمان‌بندی آخرین باگ رفع شده در OpenSSL را گزارش کرد، یک اشکال مشابه در GnuTLS تقریباً در همین زمان

این یکی دارای شناسه اشکال است CVE-2023-0361.

اگرچه GnuTLS به اندازه OpenSSL محبوب یا پرکاربرد نیست، شما احتمالاً تعدادی برنامه در بخش فناوری اطلاعات خود یا حتی در رایانه شخصی خود دارید که از آن استفاده می کنند یا شامل آن می شوند، احتمالاً از جمله FFmpeg، GnuPG، Mplayer، QEMU. ، Rdesktop، Samba، Wget و Wireshark.

از قضا، نقص زمان‌بندی در GnuTLS در کدی ظاهر شد که در وهله اول قرار بود خطاهای حمله زمان‌بندی را ثبت کند.

همانطور که از تفاوت کد می بینید (تفاوت) در زیر، برنامه نویس آگاه بود که هر شرطی (if ... then) عملیات مورد استفاده در بررسی و مقابله با یک خطای رمزگشایی ممکن است تغییرات زمان بندی ایجاد کند، زیرا CPU ها معمولاً زمان متفاوتی را بسته به اینکه کد شما پس از دستورالعمل «شاخه» طی می کند، متفاوت است.

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

اما برنامه نویس همچنان می خواست لاگ کند که ممکن است حمله ای در حال وقوع باشد، که اگر این اتفاق می افتد if (ok) تست بالا با شکست مواجه می شود و به آن منشعب می شود else { ... } بخش.

در این مرحله، کد، را فراخوانی می کند _gnutls_debug_log() عملکردی که ممکن است مدت زیادی طول بکشد تا کار خود را انجام دهد.

بنابراین کدگذار یک تماس عمدی را وارد کرد _gnutls_no_log() در then { ... } بخشی از کد، که وانمود می کند یک "حمله" را در زمانی که حمله ای وجود ندارد ثبت می کند، تا سعی کند زمانی را که کد در هر جهتی صرف می کند، افزایش دهد. if (ok) آموزش شاخه می تواند طول بکشد.

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

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

اگر برنامه نویس هستید: رفع اشکال در اینجا ساده بود و از اصل "کمتر بیشتر است" پیروی می کرد.

کد صورتی در بالا، که به نظر می‌رسید به هر حال داده‌های بسیار مفیدی برای تشخیص حمله ارائه نمی‌دهد، به سادگی حذف شد، به این دلیل که کدی که در آنجا وجود ندارد، بدون در نظر گرفتن تنظیمات ساخت شما به اشتباه نمی‌تواند در آن کامپایل شود…

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

اگر کاربر GnuTLS هستید: نسخه اخیرا منتشر شده 3.7.9 و "طعم محصول جدید" 3.8.0 این اصلاح را همراه با موارد دیگر شامل شود.

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

در لینوکس، فایل هایی با نام را جستجو کنید libgnutls*.so برای پیدا کردن کتابخانه های مشترک موجود در اطراف، و جستجو برای gnutls-cli برای یافتن هر گونه کپی از ابزار خط فرمان که اغلب در کتابخانه گنجانده شده است.

شما می توانید اجرا کنید gnutls-cli -vv تا بفهمیم کدام نسخه libgnutls به صورت پویا به:

 $ gnutls-cli -vv gnutls-cli 3.7.9 <-- توزیع لینوکس من جمعه گذشته به روز رسانی شد (2023-02-10)

---

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• پلاتوبلاک چین. Web3 Metaverse Intelligence. دانش تقویت شده دسترسی به اینجا.
• منبع: https://nakedsecurity.sophos.com/2023/02/13/serious-security-gnutls-follows-openssl-fixes-timing-attack-bug/