Skip to content
KitploitKITPLOIT
أدواتالمدونة
إرسال
أدواتالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

··الخلاصات·اتصال·الخصوصية·© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
CVE-2023-41992 — إثبات المفهوم لـ CVE-2023-41992، ثغرة في نواة macOS، يوضح تقنيات الاستغلال ويوفر تحليلًا للتصحيح. | Kitploit
أدوات/GitHubGitHub/whw0x455/cve-2023-41992
أمان iOSتحليل الذاكرة الجنائيتحليل الثغرات الأمنيةالاستغلالاستغلال الملفات الثنائية
GitHubwhw0x455/cve-2023-41992

CVE-2023-41992

إثبات المفهوم لـ CVE-2023-41992، ثغرة في نواة macOS، يوضح تقنيات الاستغلال ويوفر تحليلًا للتصحيح.

عرض المستودع
55125منذ 10 أشهرتمت المراجعة من قبل Kitploit

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

CVE-2023-41992

هذا هو إثبات المفهوم لـ CVE-2023-41992. أولاً وقبل كل شيء، هذا لا علاقة له بـ jailbreak! ولا يزال قيد التطوير.

أشكر كل من ساعدني حتى الآن. لأسباب تتعلق بالخصوصية، قد لا أذكركم هنا. أرسل لي رسالة خاصة إذا أردت!

التصحيح

على حد علمي، التصحيح موجود في ipc_right_destroy. وقد أشار أحدهم إلى ذلك على X (أو Twitter).

root@kitploit:~
diff --git a/osfmk/ipc/ipc_right.c b/osfmk/ipc/ipc_right.c
index a81ac21..32a9a3e 100644
--- a/osfmk/ipc/ipc_right.c
+++ b/osfmk/ipc/ipc_right.c
@@ -912,7 +912,6 @@ ipc_right_destroy(
        mach_port_type_t type;
 
        bits = entry->ie_bits;
-       entry->ie_bits &= ~IE_BITS_TYPE_MASK;
        type = IE_BITS_TYPE(bits);
 
        assert(is_active(space));

تجنب ReportCrash أو SIGKILL

استخدام ipc_right_destroy للحصول على إدخال ipc من نوع none متروك في مساحة ipc سيؤدي إلى استثناء. تحقق من [0] و [1] أدناه.

root@kitploit:~
kern_return_t
ipc_right_destroy(
	ipc_space_t             space,
	mach_port_name_t        name,
	ipc_entry_t             entry,
	boolean_t               check_guard,
	uint64_t                guard)
{
...
		if (type == MACH_PORT_TYPE_SEND) {
			if (ip_is_pinned(port)) {
				assert(ip_active(port));
				is_write_unlock(space);
				mach_port_guard_exception_pinned(space,  // <---- [0]
                                        name, port, MPG_FLAGS_MOD_REFS_PINNED_DESTROY);
				return KERN_INVALID_CAPABILITY;
			}
			ipc_hash_delete(space, ip_to_object(port), name, entry);
		}
...
		if ((type & MACH_PORT_TYPE_RECEIVE) &&
		    (check_guard) && (port->ip_guarded) &&
		    (guard != port->ip_context)) {
			/* Guard Violation */
			uint64_t portguard = port->ip_context;
			ip_mq_unlock(port);
			is_write_unlock(space);
			/* Raise mach port guard exception */
			mach_port_guard_exception(name,  // <---- [1]
                                0, portguard, kGUARD_EXC_DESTROY);
			return KERN_INVALID_RIGHT;
		}

[0] لن يقتل المهمة في وضع الحماية لتطبيق طرف ثالث. لقد اخترت mach_thread_self() سابقًا لأن هذا هو حق الإرسال المثبت الوحيد الذي تمكنت من العثور عليه.

لكن دون تجنب ReportCrash أو SIGKILL، لن يكون هذا الخطأ مفيدًا في وضع الحماية WebContent. لذا بحثت بشكل أعمق قليلاً.

root@kitploit:~
void
mach_port_guard_ast(thread_t t,
    mach_exception_data_type_t code, mach_exception_data_type_t subcode)
{
        ...
        	if (reason <= MAX_FATAL_kGUARD_EXC_CODE) {
		/*
		 * Fatal Mach port guards - always delivered synchronously.
		 * Check if anyone has registered for Synchronous EXC_GUARD, if yes then,
		 * deliver it synchronously and then kill the process, else kill the process
		 * and deliver the exception via EXC_CORPSE_NOTIFY.
		 */
		if (task_exception_notify(EXC_GUARD, code, subcode) == KERN_SUCCESS) {
			task_bsdtask_kill(task);
		} else {
			exit_with_guard_exception(get_bsdtask_info(task), code, subcode);
		}
        ...

تقوم mach_port_guard_ast في kernel بمعالجة استثناءات حماية منفذ mach. بالنسبة لاستثناء قاتل، تبحث أولاً عن منفذ الاستثناء. إذا أعاد إشعار الاستثناء KERN_SUCCESS، فسيتم تنفيذ SIGKILL. يبدو هذا واعدًا، كل مهمة تسببت في استثناء حماية منفذ mach قاتل سيتم قتلها. ولكن...

حراس منفذ Mach القاتلون - يتم تسليمهم دائمًا بشكل متزامن.

يمكنني ببساطة تعيين منفذ استثناء الخيط للخيط الذي يسبب الخطأ، وعدم معالجة إشعار الاستثناء. سينتظر kernel الرد هنا، دون SIGKILL.

مرجع مؤشر فارغ

  1. أنشئ منفذ استقبال ومنفذ ضحية، أدخل بعض الحقوق، قم ببعض حماية المنفذ.
  2. أرسل منفذ الضحية إلى منفذ الاستقبال في واصف منفذ
  3. قم بتشغيل الخطأ في خيط آخر باستخدام منفذ الاستثناء الخاص بنا.
  4. استقبل الرسالة على منفذ الاستقبال، يحدث kernel panic.

ذعر في ipc_right_copyout() مع إدخال NULL.

المراجع

  • blanket، قمت بنسخ بعض الرمز للاختبار.
تنزيل الأداة