CVE-2023-42829؛ 'قد يتمكن تطبيق ما من الوصول إلى عبارات مرور SSH'

توثّق هذه الوثيقة تحليلًا لثغرة منطقية تم تحديدها في ملف ssh التنفيذي على macOS (أول ثغرة برمجية أكتشفها!)، بالإضافة إلى تحليل للتصحيح يُظهر كيفية إصلاح Apple لهذه الثغرة. أبلغت Apple بالمشكلة عبر برنامج Apple Security Bounty في أواخر عام 2022، وتم إصلاحها لاحقًا في macOS Ventura 13.5 وأسفرت عن CVE-2023-42829 (🎉). تؤدي المشكلة إلى تعرّض عبارات مرور SSH المحفوظة في سلسلة مفاتيح 'تسجيل الدخول' المحلية الخاصة بالمستخدم على macOS (ضمن مجموعة الوصول com.apple.ssh.passphrases) للمهاجم المحلي كنص صريح.

إخلاء مسؤولية:
يُقدَّم هذا التقرير لأغراض تعليمية فقط، مع الالتزام بعمليات الإفصاح المسؤول. يُقدَّم التحليل كما هو، ويجب أن يلتزم أي نشر أو استخدام إضافي لهذه المعلومات بإرشادات الإفصاح المسؤول.

المخطط العام بعد التصحيح

المخطط العام قبل التصحيح

جدول المحتويات

1. الأجهزة والبرامج المختبرة
2. مثال/إثبات المفهوم
3. تحليل الثغرة
4. استحقاق com.apple.private.security.clear-library-validation
5. تحليل التصحيح
6. المراجع

الأجهزة والبرامج المختبرة

مثال/إثبات المفهوم

يُوضح إثبات المفهوم التالي سهولة استغلال الثغرة بشكلٍ كبير، عبر تمرير مكتبة ديناميكية إلى علامة -I في ملف ssh التنفيذي:

jamesd@local build % ssh -I /Users/jamesd/rome.dylib [email protected]
SSH Private Key Passphrase -> 'SuperSecret!!@@$'

لنتحدث عن كيفية اكتشاف هذا الأمر ولماذا حدث!

التحليل

في يوم من الأيام، كنت أستخدم ملف ssh التنفيذي لغرض بسيط، وأخطأت في كتابة العلامة -i (المستخدمة لتمرير ملف هوية SSH) إلى العلامة -I، فإذا بي أستقبل الإخراج التالي على stdout:

jamesd@local build % ssh -I /Users/jamesd/.ssh/id_rsa something@somewhere
dlopen /Users/jamesd/.ssh/id_rsa failed: dlopen(/Users/jamesd/.ssh/id_rsa, 0x0002): tried: '/Users/jamesd/.ssh/id_rsa' (not a mach-o file), ...
...

بعد فحص استحقاقات ملف ssh التنفيذي...

jamesd@local build % ldid -e /usr/bin/ssh # dump the entitlements of the /usr/bin/ssh binary

<key>com.apple.private.security.clear-library-validation</key>
    <true/>
    <key>keychain-access-groups</key>
    <array>
        <string>com.apple.ssh.passphrases</string>
</array>

...ازداد فضولي — فالملف التنفيذي يمتلك استحقاقات لقراءة مجموعة وصول محمية في سلسلة المفاتيح (com.apple.ssh.passphrases)، ويحمل استحقاق com.apple.private.security.clear-library-validation، كما أن ssh يحاول تنفيذ dlopen() على مفتاحي الخاص؟

كما اتضح، يدعم ssh المصادقة على نظام بعيد عبر ما يُسمى pkcs11، وهو معيار للعمليات التشفيرية على وحدات أمان العتاد (HSMs) (https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library.html).

لا نحتاج إلى القلق بشأن تفاصيل pkcs11 لأغراض هذا التقرير، سوى حقيقة أن العميل يمرر مكتبة pkcs11 (مكتبة ديناميكية) إلى ssh -I.

استحقاق com.apple.private.security.clear-library-validation

على الرغم من التكافؤ المفاهيمي، يختلف com.apple.private.security.clear-library-validation عن الاستحقاق المكافئ السابق (com.apple.security.cs.disable-library-validation) إذ يتطلب com.apple.private.security.clear-library-validation إجراء استدعاء النظام csops() مع تمرير CS_OPS_CLEAR_LV للتحكم في تفعيل/تعطيل التحقق من المكتبات، للحفاظ على تحكم أكبر في سلامة العملية أثناء التشغيل (بالمقارنة مع com.apple.private.security.clear-library-validation الذي يُفترض أنه يسمح بتحميل أي مكتبة دون تحكم أثناء التشغيل). (https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c) (https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/)

بما أن csops(CS_OPS_CLEAR_LV) يُستدعى قبل تنفيذ dlopen() على مكتبتنا، فإن مكتبتنا تُحمَّل ببساطة ويتم تنفيذ المُنشئ (constructor)، مما يسمح لنا بتقديم مكتبة ديناميكية خبيثة تتنكر كمكتبة pkcs11 وتنفيذ كود من داخل سياق /usr/bin/ssh والاستفادة من استحقاق keychain-access-groups.

تحليل التصحيح

ربما تضمّن التصحيح إجراء فحوصات على الملف التنفيذي قبل استدعاء csops() للتحقق من هويات توقيع موثوقة محددة؟

لا!

بعد إصدار التصحيح (22G74)، قارنت التنفيذ غير الآمن لدالة pkcs11_add_provider() (الطريقة التي يتم فيها استدعاء dlopen()) وبدا مطابقًا لإصدار التصحيح — لكن هناك استحقاق مفقود في /usr/bin/ssh؟

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>keychain-access-groups</key>
    <array>
        <string>com.apple.ssh.passphrases</string>
    </array>
</dict>
</plist>

لكن من المؤكد أن Apple لم تزل دعم pkcs11 من SSH؟ حاولت إعادة استغلال الثغرة باستخدام إثبات المفهوم الخاص بي واكتشفت أنه على الرغم من تحميل مكتبتي، لم يعد بإمكانها القراءة من مجموعة الوصول في سلسلة المفاتيح، وبدا أنها تُنفَّذ في سياق /usr/libexec/ssh-apple-pkcs11 (ملف تنفيذي لم أره من قبل) ويحمل الاستحقاقات التالية:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.private.security.clear-library-validation</key>
    <true/>
</dict>
</plist>

يذكر تعليق في استدعاء النظام csops() الخاص بـ CS_OPS_CLEAR_LV (https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c) إعادة التنفيذ (re-exec) إلى ملف تنفيذي دون التحقق من المكتبات كبديل لـ CS_OPS_CLEAR_LV، بدلاً من استخدامهما معًا. إذن، لماذا ما زال الروتين المعيب منطقيًا موجودًا في pkcs11_add_provider() داخل /usr/bin/ssh إذا كان هناك الآن ملف تنفيذي مساعد إضافي؟ ولماذا يبدو التنفيذ دون تغيير في التصحيح؟

حسنًا، كما اتضح، لم يكن التصحيح يضيف ملفًا تنفيذيًا مساعدًا، بل توزيع ملفين تنفيذيين لـ ssh في macOS: /usr/bin/ssh و /usr/libexec/ssh-apple-pkcs11 — وكلاهما متطابقان باستثناء استحقاقاتهما (استخدمت Diaphora للتحقق من ذلك):

بعد إجراء بعض التحليلات الديناميكية على ملف ssh التنفيذي المُصَحَّح، تبيّن أنه تمت إضافة فحص إضافي في الروتين (الكبير إلى حد ما) start() الخاص بـ ssh، والذي يُستخدم عند استخدام ميزات pkcs11 لتحديد ما إذا كان الملف التنفيذي يعمل ضمن سياق /usr/bin/ssh أم /usr/libexec/ssh-apple-pkcs11:

في الكتلة الخضراء، يمكننا ملاحظة استدعاء لـ SecTaskCopyValueForEntitlement() (القيمة المُمرَّرة هي "com.apple.private.security.clear-library-validation") والتي يتم تقييمها بعد ذلك (في الكتلة البرتقالية) وتؤدي إلى استدعاء شرطي لروتين إعادة التنفيذ إذا كان استحقاق "com.apple.private.security.clear-library-validation" غير موجود للمهمة/العملية الحالية (الكتلة الحمراء).

يؤدي هذا إلى استخدام الملف التنفيذي ssh-apple-pkcs11 الأقل استحقاقًا عند تحميل مكتبة pkcs11 التي يقدمها المستخدم (ما يعطل فعليًا الميزات المتعلقة بسلسلة المفاتيح في ssh)، واستخدام ssh في الحالات التي لا يجب فيها تحميل مكتبات غير موثوقة (ما يتيح الميزات المتعلقة بسلسلة المفاتيح في ssh).

يمكننا أيضًا التحقق من صحة هذا الأمر من خلال تصحيح أخطاء النسخة المُصَحَّحة

إذا قمنا بتصحيح أخطاء ملف ssh التنفيذي المُصَحَّح (الموزَّع في macOS 22G74) وضبطنا نقاط توقف على execv()، يمكننا بالفعل رصد استدعاء لـ execv() عند تمرير العلامة -I، وهو ما لا يحدث عند تشغيل ssh دون استخدام ميزات pkcs11:

الخلاصة / المعالجة

أبلغت Apple بالمشكلة عبر برنامج Apple Security Bounty في أواخر عام 2022، وتم إصلاحها لاحقًا في macOS Ventura 13.5 وأسفرت عن CVE-2023-42829 (🎉).

هذا التقرير منشور مستقل ولم تتم الموافقة عليه أو رعايته أو اعتماده من قِبل Apple Inc. تُعد macOS وiOS وiWork علامات تجارية لشركة Apple Inc.

المراجع

• https://github.com/apple-oss-distributions/xnu/blob/main/bsd/kern/kern_proc.c
• https://theevilbit.github.io/posts/com.apple.private.security.clear-library-validation/