Linziyuu

تتعرض الدالة `nltk.data.load()` لمشكلة اجتياز المسار عند استخدام مخطط URL `nltk:`. تنشأ هذه المشكلة لأن فحص التعبير النمطي ` UNSAFE NO PROTOCOL RE` يتم تنفيذه على سلسلة المورد الخام قبل أن تقوم الدالة `url2pathname()` بفك تشفير التسلسلات المشفرة بنسبة مئوية. تسمح هذه الثغرة التي تتمثل في «فك الترميز بعد الفحص» للمهاجمين بتجاوز إجراءات الحماية الأمنية باستخدام فواصل المسار المشفرة في عناوين URL (مثل `%2f` بدلاً من `/`) ومقاطع التجاوز (مثل `%2e%2e%2f` بدلاً من `../`)، مما يتيح قراءة ملفات عشوائية من نظام الملفات. تشير التفاصيل الفنية إلى أن الثغرة تتعلق بمكونات `find()` و`normalize resource url()` و` UNSAFE NO PROTOCOL RE` الموجودة في ملف `nltk/data.py`.

يحدث استدعاء مؤشر nil في دالة PCF `HandleCreateSmPolicyRequest` عندما يُرجع استدعاء مستهلك OpenAPI في المرحلة التالية لبحث UDR خطأً `404 Not Found`. يقوم المعالج بتسجيل الخطأ ولكنه يواصل التنفيذ بدلاً من العودة، مما يؤدي لاحقًا إلى استدعاء بنية استجابة nil. وينتج عن ذلك خطأ HTTP 500 Internal Server Error. يمكن إثارة هذه المشكلة عبر طلب POST إلى نقطة النهاية ’/npcf-smpolicycontrol/v1/sm-policies‘، وتحديدًا عند تقديم مدخلات تتسبب في فشل عملية البحث عن UDR، مثل متغير `dnn` غير معروف. في الإصدار 4.2.1، يمكن الوصول إلى نقطة النهاية هذه دون رأس `Authorization`.

يحتوي معالج PCF الخاص بنقطة النهاية ”/npcf-policyauthorization/v1/app-sessions“ على ثغرة تؤدي إلى حدوث حالة ذعر في وقت التشغيل عند معالجة طلب معين تمت مصادقته. يحدث هذا عندما يتم تعيين المتغير `ascReqData.suppFeat` على ”1“ (مما يتيح التفاوض بشأن ميزة توجيه حركة المرور) وتوفر إدخالات `medComponents` معرّف `afAppId` ولكنها تغفل `AfRoutReq`. في هذا السيناريو، يستدعي النظام الدالة `provisioningOfTrafficRoutingInfo()` بمتغير `routeReq` فارغ ويحاول إلغاء مرجعية حقوله، مثل `RouteToLocs`، دون إجراء فحص مسبق للتأكد من عدم وجود قيمة. ينتج عن ذلك عنوان ذاكرة غير صالح أو إزالة مرجعية لمؤشر nil. وفي حين أن آلية الاسترداد في Gin تمنع تعطل عملية PCF بأكملها عن طريق تحويل حالة الذعر إلى خطأ HTTP 500، يمكن للمستخدم المصادق عليه تشغيل هذا المسار بشكل متكرر للتسبب في هجوم رفض الخدمة (DoS) لكل طلب على عملية إنشاء جلسة التطبيق.

تحدث عملية كتابة غير متزامنة على الخريطة العالمية `Subscriptions` داخل معالج BSF الخاص بنقطة النهاية ’/nbsf-management/v1/subscriptions/{subId}‘. بينما يقوم المعالج بقراءة الخريطة باستخدام قفل قراءة عبر دالة `GetSubscription()`، تقوم دالة `ReplaceIndividualSubscription()` بالكتابة إلى نفس الخريطة دون الحصول على قفل متبادل (mutex) في حالة عدم وجود اشتراك. في ظل طلبات PUT المتزامنة والمصادق عليها، يؤدي هذا إلى قراءة وكتابة متزامنتين للخريطة، مما يتسبب في قيام بيئة تشغيل Go بتشغيل خطأ فادح غير قابل للاسترداد يؤدي إلى إنهاء العملية. وينتج عن ذلك هجوم «رفض الخدمة» (DoS) حيث تصبح خدمة BSF بأكملها غير متاحة حتى يتم إعادة تشغيلها. يتطلب الهجوم رمز وصول OAuth2 صالحًا لـ `nbsf-management` ويستهدف المتغير `subId`.

تقوم وظيفة التعرض للشبكة (NEF) في free5GC بإنهاء العملية بأكملها عندما يتعذر الوصول إلى `notifyUri` الخاص باشتراك PFD المخزن. يحدث هذا داخل الدالة `PfdChangeNotifier.FlushNotifications()`، حيث يستدعي المُعلم الدالة `NnefPFDmanagementNotify()`. في حالة حدوث خطأ في التسليم، يستدعي النظام `logger.PFDManageLog.Fatal(err)`، وهو ما يعادل `os.Exit(1)` في لغة Go، مما يؤدي إلى إنهاء العملية بحالة 1 وإسقاط واجهة الخدمة (SBI) بالكامل حتى تتم إعادة التشغيل. يمكن للمهاجم استغلال هذه الثغرة عن طريق إنشاء اشتراك PFD باستخدام `notifyUri` غير قابل للوصول تم اختياره، ثم تشغيل تغيير PFD. تتم محاولة التسليم بشكل غير متزامن، مما يعني أن طلب التشغيل قد يُرجع رمز نجاح قبل انتهاء عملية NEF. ويؤدي ذلك إلى فقدان تام لتوافر خدمة NEF.

تقوم وظيفة التعرض الشبكي (NEF) في free5GC بتحميل مجموعة التوجيه «nnef-callback» دون إجراء مصادقة OAuth2 أو مصادقة رمز حامل (bearer-token) للطلبات الواردة. وهذا يسمح للمهاجم بالوصول إلى معالج SMF-callback باستخدام رمز حامل مزور أو عشوائي، حيث يتم تحليل نص الطلب وإرساله إلى منطق الأعمال بدلاً من رفضه عند حدود المصادقة. تفشل وظيفة NEF في مصادقة هوية وظيفة الشبكة (NF) المنتجة قبل معالجة محتوى الاستدعاء. إذا حصل المهاجم على `NotifId` صالح أو خمّنه، فيمكنه إرسال استدعاءات مزورة للتأثير على حالات الاشتراك الحقيقية، مما قد يؤدي إلى إفساد طرق عرض تأثير حركة المرور أو إدارة PFD والتأثير على قرارات السياسة في المراحل اللاحقة. يمكن الوصول إلى هذه المشكلة عبر نقطة النهاية ’/nnef-callback/v1/notification/smf‘ وتظل متاحة حتى إذا لم تعلن `ServiceList` عن مجموعة التوجيه. تتعلق الثغرة الأمنية بالمتغير `NotifId` ودالة `SmfNotification`.

تقوم وظيفة إدارة الجلسات (SMF) في free5GC بتركيب مجموعة مسارات الإدارة `UPI` بدون برمجيات وسيطة OAuth2 واردة، مما يسمح بالوصول غير المصادق عليه. تقبل نقطة النهاية `POST` ’/upi/v1/upNodesLinks‘ ملف JSON الذي يتحكم فيه المهاجم وتمرره إلى الدالة `UpNodesFromConfiguration()`. تستدعي هذه الدالة `logger.InitLog. Fatalf()` عند حدوث عدة حالات فشل في التحقق من الصحة، مثل فشل فحص تداخل مجموعة عناوين IP لجهاز المستخدم النهائي (UE-IP-pool)، أو فشل مجموعة غير صالحة (invalid-pool)، أو فشل استبعاد المجموعة الثابتة (static-pool-exclusion). ونظرًا لأن `Fatalf` تعادل `os.Exit(1)`، فإنها تنهي عملية SMF بأكملها بدلاً من إنهاء goroutine الطلب فقط، مما يؤدي إلى فقدان كامل لخدمة SMF، بما في ذلك إنشاء جلسة PDU والبحث عن سياسات جهاز المستخدم النهائي (UE)، حتى يتم إعادة تشغيل العملية.

تحتوي وظيفة التعرض الشبكي (NEF) في free5GC على مشكلة إزالة مرجع مؤشر nil داخل الدالة `PatchIndividualApplicationPFDManagement()`. يحدث هذا عند إرسال طلب PATCH إلى نقطة النهاية ”/3gpp-pfd-management/v1/{afId}/transactions/{transId}/applications/{appId}“ في الوقت الذي يفشل فيه استدعاء مستودع البيانات الموحد (UDR) في الاتجاه الصاعد، ويقوم غلاف المستهلك بإرجاع خطأ مع كائن `*ProblemDetails` فارغ. في فرع الخطأ هذا تحديدًا، يحاول المعالج قراءة `problemDetails.Cause` على الرغم من أن `problemDetails` يساوي nil، مما يؤدي إلى حدوث حالة ذعر في وقت التشغيل. تقوم آلية الاسترداد Gin بتحويل حالة الذعر هذه إلى خطأ HTTP 500 Internal Server Error. يمكن أن تحدث هذه المشكلة بدون وجود رأس Authorization (التفويض) نظرًا لأن مجموعة المسارات (route group) يتم تثبيتها بدون برمجيات وسيطة للمصادقة الواردة.

يحتوي معالج UDR `nudr-dr` الخاص بنقطة النهاية ”DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions“ على عملية إزالة مرجعية لمؤشر nil. يحدث هذا عند إرسال طلب يحتوي على `subsId` غير موجود بعد إنشاء اشتراك EE تم توثيقه مسبقًا لتخصيص حالة UE. يكتشف المعالج الإدخال المفقود ويقوم بتعيين خطأ 404 لكنه يفشل في العودة، ثم يحاول بعد ذلك الوصول إلى `UESubsData.EeSubscriptionCollection[subsId].AmfSubscriptionInfos`. ينتج عن ذلك حالة ذعر في وقت التشغيل يتم تحويلها إلى خطأ HTTP 500 بواسطة آلية الاسترداد في Gin. يمكن لمهاجم تمت مصادقته ولديه رمز وصول OAuth2 صالح لـ `nudr-dr` أن يثير حالة الذعر هذه بشكل متكرر، مما يؤدي إلى رفض الخدمة (DoS) من خلال تدهور الموارد.

يحتوي معالج UDR `nudr-dr` في free5GC على مشكلة حيث يمكن لطلب واحد تمت مصادقته أن يتسبب في حدوث حالة ذعر. يحدث هذا عند إرسال طلب إلى نقطة النهاية ”DELETE /subscription-data/{ueId}/{servingPlmnId}/ee-subscriptions/{subsId}/amf-subscriptions“ وعدم وجود `ueId` المقدم في `UESubsCollection`. يقوم النظام بتحديد المستخدم المفقود ويحدد خطأ 404 USER NOT FOUND، لكنه يفشل في إيقاف التنفيذ. وبعد ذلك، يحاول إجراء تأكيد نوع Go على واجهة nil باستخدام الدالة `RemoveAmfSubscriptionsInfoProcedure()`، مما يؤدي إلى حدوث حالة ذعر لتحويل الواجهة. وعلى الرغم من أن آلية الاسترداد في Gin تحول حالة الذعر هذه إلى خطأ HTTP 500، تظل نقطة النهاية عرضة لحالات ذعر متكررة، والتي يمكن استخدامها لإحداث هجوم رفض الخدمة (DoS) لكل طلب عن طريق زيادة الحمل الزائد على وحدة المعالجة المركزية (CPU) وكتابة السجلات.

تحتوي نقطة نهاية SBI الجذرية لـ NRF ”POST /oauth2/token“ على خطأ في الخلط بين الأنواع على مستوى المحلل. يستخدم المعالج الموجود في `NFs/nrf/internal/sbi/api accesstoken.go` الانعكاس على `models.NrfAccessTokenAccessTokenReq`، لكنه يقتصر على الحالات الخاصة للحقول العادية `string` و`NrfNfManagementNfType`، ويعامل جميع الحقول الأخرى على أنها `models.PlmnId`. عندما يقدم المهاجم اسم حقل في نص النموذج غير متوافق مع نوع `models.PlmnId` (مثل شريحة أو بنية مختلفة)، فإن الدالة `reflect.Value.Set()` تُحدث حالة ذعر. وعلى الرغم من أن آلية الاسترداد في Gin تحول حالات الذعر هذه إلى أخطاء HTTP 500، فإن نقطة النهاية تظل عرضة لإحداث حالة ذعر عن بُعد عبر طلبات مشفرة في نموذج غير مصدقة. يمكن إحداث ذلك باستخدام عدة معلمات، بما في ذلك `requesterPlmnList` و`requesterSnssaiList` و`requesterSnpnList` و`targetSnpn` و`targetSnssaiList` و`targetNsiList`.

تقوم وظيفة التعرض الشبكي (NEF) بتثبيت واجهة برمجة التطبيقات (API) «3gpp-traffic-influence» دون اشتراط ترخيص OAuth2 الوارد أو ترخيص رمز الحامل (bearer-token). يمكن لمهاجم الشبكة الذي لديه وصول إلى NEF على واجهة الخدمة (SBI) تنفيذ عمليات الإنشاء والقراءة والتصحيح والحذف على اشتراكات التأثير على حركة المرور. ويمكن تحقيق ذلك عن طريق حذف رأس `Authorization` بالكامل أو باستخدام رمز حامل مزور. وهذا يسمح بإنشاء اشتراكات `AnyUeInd=true` للتأثير على توجيه حركة مرور المجموعة أو أي جهاز مستخدم (UE). بالإضافة إلى ذلك، تظل مجموعة المسارات قابلة للوصول حتى لو لم تعلنها قائمة `ServiceList` في التكوين الجاري، مما يعني أن المشغلين لا يمكنهم تعطيل الخدمة عبر التكوين للتخفيف من المخاطر.

تقوم وظيفة التعرض الشبكي (NEF) بتركيب مجموعة المسارات ”nnef-oam“ دون الحاجة إلى ترخيص OAuth2 الوارد أو ترخيص رمز الحامل. يمكن لمهاجم شبكي لديه وصول إلى NEF على الواجهة القائمة على الخدمة (SBI) الوصول إلى مسار OAM دون رأس ”Authorization“، مما يؤدي إلى استجابة 200 OK. ورغم أن معالج OAM الحالي عبارة عن كود بديل (stub) يُرجع القيمة `null`، فإن نطاق الخلل يشمل مجموعة المسارات بأكملها. وبالتالي، فإن أي عمليات تشغيل وإدارة وصيانة (OAM) تُضاف مستقبلاً إلى هذه المجموعة ستفتقر إلى حدود المصادقة افتراضيًا، مما يسمح بالاستكشاف المجهول والتنفيذ غير المصرح به المحتمل للوظائف الإدارية المستقبلية.

يقوم SMF بتركيب مجموعة مسارات الإدارة `UPI` بدون برمجيات وسيطة OAuth2 واردة، مما يسمح بالوصول غير المصادق عليه. يؤدي عيب في دالة `DeleteUpNodeLink` إلى إزالة مرجع مؤشر nil عند معالجة الطلبات الخاصة بالعقد من نوع شبكة الوصول (AN)، حيث يتم إنشاء هذه العقد بدون كائن `UPF`. وعلى وجه التحديد، يقوم المعالج باستدعاء `upNode.UPF.CancelAssociation()` دون شروط، مما يؤدي إلى حدوث حالة ذعر. علاوة على ذلك، يتم تنفيذ الدالة `UpNodeDelete(upNodeRef)` قبل حدوث حالة الذعر، مما يؤدي إلى تغيير طوبولوجيا مستوى المستخدم الموجودة في الذاكرة. يمكن لمهاجم شبكي خارج المسار استغلال هذه الثغرة عن طريق إرسال طلب `DELETE` إلى نقطة النهاية ”/upi/v1/upNodesLinks/{upNodeRef}“ باستخدام المتغير `upNodeRef`، مما قد يؤدي إلى حذف إدخالات مسماة عشوائية ومنع SMF من استخدام تلك العقد للجلسات المشروعة.

تقوم وظيفة إدارة الجلسات (SMF) بتركيب مجموعة مسارات الإدارة `UPI` دون استخدام OAuth2 أو برمجيات وسيطة لتفويض الرمز المميز للحامل (bearer-token). وهذا يسمح لمهاجم الشبكة الذي لديه وصول إلى الواجهة القائمة على الخدمة (SBI) بتنفيذ عمليات غير مصرح بها عن طريق إرسال طلبات بدون رأس `Authorization`. هذه المشكلة تقتصر على مجموعة مسارات `UPI`، حيث إن المجموعات الأخرى مثل `nsmf-oam` محمية بشكل صحيح. تشمل التفاصيل الفنية القدرة على تنفيذ العمليات التالية: - عمليات القراءة عبر نقطة النهاية ’/upi/v1/upNodesLinks‘. - عمليات الكتابة عبر نقطة النهاية ’/upi/v1/upNodesLinks‘ باستخدام طلب `POST` لإدخال عقد UPF وحمولات الارتباط التي يتحكم فيها المهاجم. - عمليات الحذف عبر نقطة النهاية ’/upi/v1/upNodesLinks/{nodeID}‘. يتيح هذا النقص في المصادقة للمهاجم قراءة طوبولوجيا المستوى العلوي (UP-plane)، أو تشويه رؤية SMF لعقد UPF لتوجيه اختيار جلسات PDU، أو تعطيل مشاركة UPF المشروعة من خلال عمليات الحذف.

تقوم وظيفة التعرض الشبكي (NEF) بتحميل مجموعة المسارات `nnef-pfdmanagement` دون الحاجة إلى مصادقة OAuth2 الواردة أو مصادقة رمز الحامل (bearer-token). وهذا يسمح لمهاجم الشبكة الذي لديه وصول إلى الواجهة القائمة على الخدمة (SBI) باستخدام رموز حامل مزورة أو عشوائية لتنفيذ إجراءات غير مصرح بها. وعلى وجه التحديد، يمكن للمهاجمين قراءة بيانات تطبيق PFD عبر نقاط النهاية ”/applications“ و ”/applications/{appID}“، وإنشاء أو حذف اشتراكات إخطارات التغيير في PFD باستخدام ”/subscriptions“ و ”/subscriptions/{subID}“. يحدث هذا لأن مجموعة المسارات يتم تثبيتها دون البرامج الوسيطة اللازمة للمصادقة الواردة، على الرغم من إعلانها في `ServiceList` الخاصة بوقت التشغيل حيث يتوقع المشغلون الحماية عبر OAuth2 الصادر عن NRF.

تقوم وظيفة التعرض الشبكي (NEF) في free5GC بتحميل واجهة برمجة التطبيقات (API) «3gpp-pfd-management» دون ترخيص OAuth2 وارد أو ترخيص رمز حامل (bearer-token). يمكن لمهاجم الشبكة الذي يتمتع بإمكانية الوصول إلى الواجهة القائمة على الخدمة (SBI) استخدام رموز حامل مزورة أو عشوائية لإنشاء حالات معاملات إدارة PFD وقراءتها وحذفها. وهذا يسمح بتسميم حالة السياسة التي تستخدمها وظيفة إدارة الجلسة (SMF) ووظيفة مستوى المستخدم (UPF) لتصنيف حركة المرور، وتسريب بيانات سياسة وظيفة التطبيق، وحجب الخدمة عن قواعد الكشف عن التطبيقات المشروعة. تشمل التفاصيل الفنية ما يلي: - نقاط نهاية واجهة برمجة التطبيقات (API): ’/3gpp-pfd-management/v1/{scsAsID}/transactions‘ و ’/3gpp-pfd-management/v1/{scsAsID}/transactions/{transID}‘ - المعلمات المعرضة للخطر: رأس `Authorization` - الوظائف المعرضة للخطر: `PostPFDManagementTransactions()`، و`GetIndividualPFDManagementTransaction()`، و`DeleteIndividualPFDManagementTransaction()` بالإضافة إلى ذلك، تظل مجموعة المسارات قابلة للوصول حتى إذا لم تعلنها قائمة `ServiceList` في التكوين قيد التشغيل، مما يعني أنه لا يمكن تعطيل الخدمة عبر إعداد التكوين هذا.

تفشل وظيفة إدارة الوصول والتنقل (AMF) في free5GC في فرض قواعد الإجراءات الأمنية المتزامنة. وعلى وجه التحديد، لا تتحقق وظيفة AMF مما إذا كان إجراء تسليم N2 جارياً قبل بدء أمر وضع أمان NAS، وبالمقابل، لا تتحقق من وجود أمر وضع أمان NAS جارٍ قبل بدء إجراءات N2. وقد يؤدي هذا النقص في التزامن إلى عدم تطابق بين سياقات الأمان في طبقة عدم الوصول (NAS) وطبقة الوصول (AS) في الشبكة ومعدات المستخدم (UE). يتضمن الاستغلال التقني الدالة `SecurityMode()` في الملف `internal/gmm/sm.go` والدالة `handleHandoverRequiredMain()` في الملف `internal/ngap/handler.go`، حيث تفتقد الفحوصات المطلوبة عبر الإجراءات.

يوجد في free5GC CHF مشكلة تتعلق بالوصول إلى شريحة خارج نطاقها ضمن خدمة `nchf-convergedcharging`. يمكن أن يتسبب طلب صالح ومصادق عليه موجه إلى **نقطة نهاية واجهة برمجة التطبيقات (API)** `/nchf-convergedcharging/v3/recharging/:ueId?ratingGroup=...` في حدوث حالة ذعر من جانب الخادم في الدالة `github.com/free5gc/chf/internal/sbi.(*Server).RechargePut(...)` بسبب الوصول إلى شريحة خارج النطاق. على الرغم من أن آلية الاسترداد في Gin قد تحول حالة الذعر إلى خطأ HTTP 500، إلا أن مسار إعادة الشحن يظل عرضة لتكرار حدوث حالات الذعر، مما قد يؤدي إلى تدهور وظائف إعادة الشحن وإغراق السجلات. قد تواجه عمليات النشر التي تفتقر إلى آليات استرداد مماثلة اضطرابات أكثر خطورة في الخدمة. تتعلق المشكلة بالوصول إلى شريحة خارج الحدود المحددة لها، مما يؤدي إلى سلوك غير متوقع للبرنامج.

يوفر free5GC SMF وظيفة إدارة الجلسات لـ free5GC، وهو مشروع مفتوح المصدر لشبكات النواة الخلوية من الجيل الخامس (5G). يتعرض البرنامج لحالة ذعر (panic) ويتم إغلاقه عند معالجة طلب PFCP SessionReportRequest غير صحيح في واجهة PFCP (UDP/8805). تحدث المشكلة عند تلقي رسالة غير صحيحة عبر واجهة PFCP، وتحديدًا طلب `SessionReportRequest`. لا يتوفر حاليًا أي تصحيح من المصدر. تشمل استراتيجيات التخفيف تقييد الوصول إلى واجهة PFCP على عناوين IP الموثوقة الخاصة بـ UPF فقط، أو تجاهل أو فحص رسائل PFCP SessionReportRequest غير الصحيحة على حافة الشبكة، أو إضافة دالة recover() حول عملية إرسال معالج PFCP لمنع الإنهاء الكامل للعملية.