باگی به مدت ۱۲ سال در لینوکس ، دسترسی روت را به مهاجمان میدهد ؟!

[M!lad]

البته از راه دور در دسترس هست. فرضا یک سرور که تعداد زیادی کاربر داره و بهش SSH میزنند و یک دسترسی تعریف شده دارند رو در نظر بگیرید. این حفره این اجازه رو به هر یک از کاربران می‌داد که یک حمله privilege escalation به سرور بزنند. متدها و روش‌های زیادی برای این نوع حمله وجود داره و عموما از misconfiguration نشات می‌گیرند. اما گاهی اوقات این نوع باگ‌ها کار رو آسون می‌کنند. و بهتره بدونید که عموم حملات از داخل و توسط کاربران با سطوح دسترسی پایین صورت می‌گیره.

حالا هم که دیگه وصله شده.

[Dragon-]

فکر کنم حدود ۱ هفته باشه که وصله امنیتی اون منتشر شده باشه.
مشکل  همونطور که احتمالا می‌دونید، از polkit هست. polkit یه برنامه برای بالا بردن دسترسی برنامه هست. اینجوری لازم نیست برای هر برنامه که قراره با دسترسی خاصی اجرا بشه، بیتِ setuid یا setgid رو فعال کرد و همینطور برای هر برنامه، قابلیت‌های احراز هویت رو اضافه کرد.

با توجه به سالی که آسیب‌پذیری از اون موقع تا حالا بوده، احتمالا قسمتی از کد که این آسیب‌پذیری رو داشته، جز اولین قسمت‌هایی بوده که نوشته شده.
polkit توی سال 2009 با اسم policykit توسط redhat منتشر شد. توی 2012، اسمش به polkit تغییر کرد.

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

مشکل اینجاست که اگه argc که توسط برنامه مخرب به pkexec داده میشه، برابر صفر باشه، طی یه سری اتفاقات، pkexec سعی می‌کنه از طریق متغییر‌های محیطی بفهمه که چی باید اجرا بشه. تغییر متغییر‌های محیطی هم کاری نداره و خیلی راحت برنامه مخرب، چیزی کهدمی‌خواهد رو با دسترسی کامل روت اجرا می‌کنه.
این آسیب‌پذیری هر جایی که polkit استفاده میشه، قابل بهره برداری هست؛ به غیر از openbsd. کرنل openbsd برنامه‌هایی که argc اونها 0 هست رو اجرا نمی‌کنه.

توی دبیان (و احتمالا توزیع‌های مبتنی بر اون) می‌تونید changelog مربوط به بسته policykit رو بررسی کنید. اون یه فایل فشرده gzip توی مسیر زیر هست.

کد: [انتخاب]

/usr/share/doc/policykit-1/changelog.Debian.gzاگه توی این فایل، عبارت CVE-2021-4034 رو دیدید، یعنی شما نسخه‌ای از polkit رو دارید که نسبت به آسیب‌پذیری ایمن هست. CVE-2021-4034، شناسه‌ی این آسیب‌پذیری توی cve هست.

یه راه راحت برای بررسی فایل بالا، استفاده از zgrep هست. اینجوری

کد: [انتخاب]

zgrep 'CVE-2021-4034' /usr/share/doc/policykit-1/changelog.Debian.gz
اگه zgrep نبود (معمولا هست)، از zcat استفاده کنید و خروجی رو بدید به grep

کد: [انتخاب]

zcat /usr/share/doc/policykit-1/changelog.Debian.gz | grep 'CVE-2021-4034'
اگه zcat هم نبود، مستقیم از gunzip استفاده کنید.

کد: [انتخاب]

gunzip -c /usr/share/doc/policykit-1/changelog.Debian.gz | grep 'CVE-2021-4034'

[Dragon-]

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

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

*آسیب پذیری

این مسیری که میفرماید کلا دسترسی نداره که بخواد به ۷۵۵ تغییر بده تغریبا همه فایل ها مال کاربر روت است
میتونید برید به ایم مسیر و ببینید

اصولا اون دایرکتوری و همه محتویات داخلش تحت مالکیت کاربر روت هستند تا هر کاربری نتونه اونها رو تغییر بده. اون دستوری که اونجا داده هم باید با دسترسی روت اجرا بشه تا کار کنه.
اون دستور، همه بیت‌های setuid، setgid و sticky bit رو غیرفعال می‌کنه. setuid فایل pkexec  فعال هست تا بتونه برنامه‌ها رو با دسترسی روت یا هر دسترسی دیگه‌ای که لازمه، اجرا کنه. اون دستور باعث میشه بیت setuid غیرفعال بشه و در نتیجه pkexec نتونه برنامه‌ها رو با دسترسی دیگه‌ای اجرا کنه. احتمالا بعد از اینکار با هر بار استفاده از polkit، کاربر یه خطا مشاهده می‌کنه.

در ضمن دستور chmod 755 روی اون بیت‌هایی که بالا گفتم، تاثیر نداره. حتما باید اون 0 اولش هم باشه تا اون بیت‌ها رو غیرفعال کنه.
عدد مربوط به sticky bit برابر 1 هست، setgid برابر 2 و setuid برابر 4.
با این فرض‌ها، دسترسی پیش‌فرض فایل pkexec باید برابر 4755 باشه.

البته به نظرم استفاده از نماد‌ها برای برداشتن، setuid، راه بهتری هست. چون اینجوری احتمال خطا کمتر میشه چون لازم نیست عددی وارد بشه. اینجوری

کد: [انتخاب]

chmod u-s /usr/bin/pkexec
بیت setuid برای این هست که یه برنامه، با دسترسی مالکش اجرا بشه. توی مورد pkexec، مالک روت هست و در نتیجه pkexec با دسترسی روت اجرا میشه. چون pkexec با دسترسی روت اجرا میشده، می‌تونسته بعدا برنامه مورد نظر رو با یه دسترسی پایین‌تر اجرا کنه؛ اگه لازم میشده.

*تقریبا

همین بوده درسته؟

کد: [انتخاب]

Start-Date: 2022-01-30  19:56:06
Commandline: apt upgrade
Requested-By: aminavy (1000)
Install: linux-image-5.10.0-11-amd64:amd64 (5.10.92-1, automatic)
Upgrade: libpolkit-gobject-elogind-1-0:amd64 (0.105-31+devuan1, 0.105-31+devuan2), libpolkit-agent-1-0:amd64 (0.105-31+devuan1, 0.105-31+devuan2), gir1.2-javascriptcoregtk-4.0:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1), gir1.2-webkit2-4.0:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1), linux-image-amd64:amd64 (5.10.84-1, 5.10.92-1), libnss3:amd64 (2:3.61-1+deb11u1, 2:3.61-1+deb11u2), libpolkit-gobject-1-0:amd64 (0.105-31+devuan1, 0.105-31+devuan2), gir1.2-polkit-1.0:amd64 (0.105-31+devuan1, 0.105-31+devuan2), libjavascriptcoregtk-4.0-18:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1), python3-pil:amd64 (8.1.2+dfsg-0.3, 8.1.2+dfsg-0.3+deb11u1), libwebkit2gtk-4.0-37:amd64 (2.34.3-1~deb11u1, 2.34.4-1~deb11u1), policykit-1:amd64 (0.105-31+devuan1, 0.105-31+devuan2), linux-libc-dev:amd64 (5.10.84-1, 5.10.92-1)
End-Date: 2022-01-30  19:57:34

آره فکر کنم خودشه. البته همراه اون، چیز‌های دیگه‌ای هم ارتقا پیدا کردند که ربط خاصی به polkit ندارند. مثل کرنل.