Ohxorud-Dev

توجد مشكلة في عملية ربط الكائنات (blob mount) عبر المستودعات، حيث يتم التحقق من الحزمة المستهدفة مقابل قيود `public-only` الخاصة بالرمز (token)، ولكن يتم التحقق من الكائن المصدر فقط مقابل صلاحيات الحساب الكاملة لمالك الرمز. يمكن للمهاجم الذي يستخدم رمزًا بنطاق `public-only` وصلاحية `write:package` ربط كائن من حزمة خاصة في مساحة اسم حزمة عامة، بشرط أن يمتلك مالك الرمز صلاحية القراءة للحزمة الخاصة وصلاحية الكتابة للحزمة العامة. يؤدي ذلك إلى إمكانية تحميل الكائنات الخاصة، مثل طبقات الحاويات، من قبل أي مستخدم عبر الحزمة العامة.

يسمح Gitea لرمز مميز (token) ذي قيود `public-only,write:repository` بتحديث فرع الرأس الخاص لطلب السحب (pull request). يحدث هذا لأن النظام يتحقق من صحة قيد ”للعامة فقط“ للرمز المميز مقابل مسار مستودع القاعدة العام، لكنه يفشل في إعادة تطبيق هذا القيد على مستودع الرأس الخاص أثناء عملية التحديث. ونتيجة لذلك، يمكن للمهاجم الذي يمتلك مثل هذا الرمز المميز أن يجعل Gitea تقوم بدفع الالتزامات من مستودع أساسي عام إلى فرع الرأس الخاص، متجاوزًا بذلك قيود الوصول المقصودة. تشمل التفاصيل الفنية ما يلي: - **نقطة نهاية واجهة برمجة التطبيقات (API):** `POST /api/v1/repos/{public-owner}/{public-repo}/pulls/{index}/update` - **الوظيفة المعرضة للخطر:** `UpdatePullRequest()` إذا تم تمكين Gitea Actions في مستودع الرأس الخاص، فإن هذا الدفع غير المصرح به يمكن أن يؤدي أيضًا إلى تشغيل سير عمل `push` الخاص بالمستودع الخاص.

توجد مشكلة في تصعيد الامتيازات في نقطة نهاية واجهة برمجة التطبيقات (API) `POST /users/{username}/tokens` المستخدمة لإنشاء رموز الوصول الشخصية. نقطة النهاية محمية بواسطة البرمجيات الوسيطة `reqBasicOrRevProxyAuth`، والتي صُممت لتتطلب مصادقة قائمة على كلمة المرور لمنع استخدام رمز تم اختراقه لإنشاء رموز جديدة. ومع ذلك، إذا تم تقديم رمز الوصول بتنسيق `Authorization: Basic <token>:x-oauth-basic`، فإن النظام يقوم بشكل خاطئ بتعيين `AuthedMethod` إلى `basic` و`IsBasicAuth` إلى `true`، مما يؤدي إلى تجاوز الحماية التي توفرها البرمجيات الوسيطة. وبمجرد تجاوز الحماية، تفشل دالة `CreateAccessToken` في فرض حد أقصى للنطاق، مما يعني أنها لا تتحقق مما إذا كانت النطاقات المطلوبة تشكل مجموعة فرعية من النطاقات الحالية للمتصل. ونتيجة لذلك، يمكن للمهاجم الذي يمتلك رمزًا مقيدًا (مثل رمز لا يمتلك سوى أذونات `write:user`) إنشاء رمز جديد بنطاق `all`، مما يمنحه وصولًا إداريًا كاملاً إلى الحساب دون معرفة كلمة مرور المستخدم.

في مسار Git Smart HTTP، يفشل النظام في فرض أذونات رمز الوصول (access-token) الخاصة بنطاق المستودع عندما يتم توفير الرموز عبر مصادقة Bearer. على الرغم من أن الدالة `CheckRepoScopedToken()` مصممة للتحقق من النطاقات، إلا أنها تعود مبكرًا إذا كان الطلب لا يستخدم مصادقة HTTP Basic. ونتيجة لذلك، فإن رمز الوصول الشخصي (PAT) أو رمز OAuth2 المرسل كـ `Authorization: Bearer <token>` يتجاوز فحوصات النطاق تمامًا. وهذا يسمح لرمز الوصول ذي الأذونات المحدودة (على سبيل المثال، `read:notification` فقط) بتنفيذ عمليات مثل استنساخ أو استرداد مستودعات خاصة دون نطاق `read:repository`، أو الدفع إلى مستودعات دون نطاق `write:repository`، شريطة أن يمتلك صاحب رمز الوصول أذونات RBAC اللازمة للمستودع. تؤثر هذه المشكلة على الدالة `CheckRepoScopedToken()` وتؤثر على مسارات Git Smart HTTP.