AWS-Tough-Library-Multiple-CVEs

التنفيذ الضعيف: في الإصدار 0.19.x والإصدارات السابقة له، بعد تنزيل root.json جديد، كان Tough يتحقق من التوقيعات لكنه لم يفرض استمرارية الإصدار بشكل صارم. وقد سمح لإصدار الجذر الجديد بأن يكون أي قيمة >= الإصدار الموثوق به. على سبيل المثال، إذا كان الجذر الموثوق به حاليًا هو الإصدار N، فسيقبل Tough جذرًا جديدًا يدّعي أنه الإصدار N+2 أو أعلى (طالما كانت التوقيعات صالحة)، متجاوزًا الإصدار N+1. يوضح مقتطف الكود أدناه الفحص قبل الإصلاح:```rust // (Prior to fix) Allow new root version to be >= old version – too permissive ensure!(root.signed.version <= new_root.signed.version, error::OlderMetadataSnafu { role: RoleType::Root, current_version: root.signed.version, new_version: new_root.signed.version });

يضمن هذا التغيير قيام العميل بتنزيل بيانات التعريف الجذرية (root metadata) وتطبيقها بالترتيب (N، N+1، N+2، ...) دون تخطي. إذا تمت مواجهة ملف بيانات تعريف جذرية بإصدار لا يساوي تمامًا old_version+1، فإن Tough يعامله الآن كهجوم محتمل ويُجهض عملية التحديث.

• السبب الجذري: فقدان التحقق من الإصدار التسلسلي (CWE-1288: التحقق غير السليم من قيمة فحص السلامة) كان الكود يتحقق فقط من أن الجذر الجديد ليس أقدم من الجذر الحالي، لكنه لم يكن يتحقق من القفزات غير المتوقعة.
• الإصلاح: قم بالترقية إلى tough = 0.20.0، الذي يتضمن التصحيح. تأكد من أن أي تفرعات أو محدّثات مخصصة مبنية على Tough تطبّق نفس الفحص الصارم. من الحكمة أيضًا مراجعة السجلات بحثًا عن أي قفزات مشبوهة في إصدار الجذر ضمن سجل التحديثات كمؤشر على محاولة استغلال.

CVE-2025-2886: عدم احترام التفويض المُنهي

تعامل Tough بشكل غير صحيح مع أدوار الأهداف المفوضة “المُنهية” كما هو معرّف في TUF. في مستودع TUF، يمكن وضع علامة مُنهٍ على تفويض، بمعنى أنه إذا وصل بحث هدف إلى ذلك التفويض ولم يتم العثور على الهدف هناك، يجب أن يتوقف البحث (ولا يستمر إلى تفويضات أخرى أقل أولوية). (انظر هنا) بسبب خطأ منطقي، فشل Tough في إنهاء البحث في هذه الحالة – حيث كان يستمر في البحث في التفويضات اللاحقة حتى عندما كان ينبغي أن يتوقف. قد يسمح هذا لمهاجم يتحكم في تفويض أقل أولوية بتقديم محتوى لأهداف لا ينبغي له التحكم بها، متجاوزًا حدود الثقة المقصودة.

• الإشعار الأمني: GitHub Security Advisory GHSA-v4wr-j3w6-mxqc (CVE-2025-2886)
• الكود المتأثر: خوارزمية البحث عن الأهداف في tough/src/editor/targets.rs (وكود حل التفويض المرتبط به). لم يعالج الكود الهش بشكل صحيح علامة terminating على التفويضات. عند التكرار عبر التفويضات بحثًا عن هدف، كان Tough ينتقل إلى التفويض التالي حتى لو كان التفويض الحالي مُعلّمًا بأنه مُنهٍ ولم يكن هناك تطابق، بما يخالف مواصفات TUF.

التنفيذ الهش: في Tough <0.20.0، كان منطق find_target() ببساطة يستدعي نفسه بشكل متكرر أو يكرر عبر جميع الأدوار المفوضة الممكنة حتى يتم العثور على هدف أو استنفاد جميع الأدوار. لم يكن يعيّن أي علامة أو يخرج من الحلقة عند مواجهة دور مُنهٍ. الكود الزائف للسلوك القديم:```rust for role in delegation_chain { if role.has_target(target) { return target_metadata; } // Missing: if role is terminating and target not found, should break. // Tough erroneously continues to next delegation. }

بالإضافة إلى ذلك، تحمل استدعاءات find_target العودية الآن علامة terminated لضمان أنه بمجرد الإشارة إلى الإنهاء، لا يتم النظر في أي تفويضات أخرى في الحلقات عالية المستوى. كما تم تحديث RepositoryEditor::delegate_role والهياكل ذات الصلة في Tough لتخزين سمة terminating وتمريرها عبر منطق البحث.

• السبب الجذري: خلل منطقي حيث لم ينفّذ الكود دلالات التفويض المُنهي (CWE-284: التحكم غير السليم في الوصول – يمكن للأدوار ذات الأولوية الأقل تجاوز القيود المقصودة). في الأساس، سمح غياب break عند التفويض المُنهي باعتبار بيانات أهداف غير مصرح بها.
• التأثير: يمكن للعملاء جلب أهداف مملوكة للدور الخاطئ – وتحديدًا، إذا فوّض مشروع مجموعة فرعية من الأهداف إلى طرف آخر (ووضع علامة على هذا التفويض كمُنهٍ للحد من نطاق التجاوز)، فإن ذلك الطرف لا يزال بإمكانه تقديم محتوى عشوائي لأهداف خارج نطاقه. يؤدي هذا إلى كسر التسلسلات الهرمية للثقة في مستودع TUF.
• المعالجة: قم بالتحديث إلى tough 0.20.0+ الذي ينفذ بشكل صحيح معالجة التفويض المُنهي. إذا كنت تحتفظ بفرع (fork) أو عميل مخصص، فتأكد من أن البحث عن الأهداف يتوقف عند التفويضات المُنهية. يجب على مختبرِي الأمان محاولة سيناريوهات إساءة استخدام التفويض على الإصدارات الأقدم فقط؛ سيتجاهل الإصدار المحدث بشكل صحيح الاستجابات الخبيثة ذات الأولوية الأقل.

CVE-2025-2887: اكتشاف غير مكتمل للتراجع عن الأهداف المفوضة

كان منطق Tough لاكتشاف هجمات التراجع في بيانات اللقطة (snapshot metadata) غير مكتمل. وتحديدًا، عند تحديث دور اللقطة (Snapshot)، يجب على Tough التحقق من أن جميع بيانات الأهداف التي شوهدت سابقًا (بما في ذلك الأهداف المفوضة) لا تزال موجودة وغير معاد إصدارها إلى إصدار أقدم في اللقطة الجديدة. (انظر هنا) وقد فرض Tough ذلك على ملف targets.json ذي المستوى الأعلى، لكنه فشل في القيام بذلك بالنسبة لملفات بيانات الأهداف المفوضة. يمكن لهذه الفجوة أن تسمح لمهاجم بحذف أو تراجع ملف هدف مفوض في بيانات اللقطة الخاصة بالمستودع دون اكتشاف، مما يؤدي إلى قبول العميل لملف هدف مفوض قديم (أو مفقود) كما لو كان حديثًا.

• الاستشارة: استشارة أمان GitHub GHSA-q6r9-r9pw-4cf7 (CVE-2025-2887)
• الكود المتأثر: التحقق من تحديث اللقطة في tough/src/lib.rs (الدالة التي تحمّل/تطبّق بيانات اللقطة الجديدة). الكود المعرّض للخطر كان يتحقق فقط من استمرارية دور targets.json الرئيسي في اللقطة، لكنه لم يتكرر عبر الأدوار المفوضة المدرجة في بيانات اللقطة لإجراء فحوصات مماثلة.

التنفيذ المعرّض للخطر: في Tough <0.20.0، بعد استرداد snapshot.json جديد، كان العميل يتأكد من عدم تراجع دورَي الجذر واللقطة، وكان يتأكد تحديدًا من أن targets.json لا يزال موجودًا. كما تحقق من أن إصدار targets.json في اللقطة الجديدة هو >= الإصدار السابق. ومع ذلك، إذا كانت اللقطة تحتوي على أهداف مفوضة (مثل بيانات مفوضة projects.json، user.json)، لم يتحقق العميل منها. على سبيل المثال، كان الكود في الأصل يقوم بشيء مثل:```rust // Pseudo-code of original snapshot rollback check (simplified) if let Some(old_targets_meta) = old_snapshot.meta.get("targets.json") { let new_targets_meta = new_snapshot.meta.get("targets.json").unwrap(); ensure!(new_targets_meta.version >= old_targets_meta.version, ...); } // (No checks for delegated target roles like "projects.json", "user.json", etc.)

من خلال التكرار على جميع الأدوار (يمثل الاسم كل اسم من أسماء ملفات البيانات الوصفية مثل targets.json وdelegated-role.json وما إلى ذلك)، سيكتشف العميل ما إذا كانت أي بيانات وصفية للأهداف المفوضة قد أُزيلت أو تم التراجع عنها. سيتم إطلاق الخطأين SnapshotRoleMissing وSnapshotRoleRollback إذا اختفى أحد الأدوار أو تراجع إصداره إلى الخلف. ومن الجدير بالذكر أن Tough يضمن الآن أيضًا بشكل صريح أن اللقطة تحتوي على إدخال targets.json على الأقل (وإلا فسيُصدر خطأ SnapshotTargetsMetaMissing) كفحص سلامة​.

• السبب الجذري: تحقق غير مكتمل – لم يطبّق Tough فحوصات التراجع بشكل موحد على أدوار الأهداف المفوضة. هذا تنفيذ جزئي لإجراء أمني، مما يترك ثغرة يمكن للمهاجمين استغلالها (CWE-352: خطوة حاسمة مفقودة في التفويض؛ وهي من الناحية المفاهيمية مجموعة فرعية من مشكلات التحقق من التكامل). كان الكود يحمي الأهداف عالية المستوى فقط، بافتراض (بشكل غير صحيح) أن الأدوار المفوضة لن تتراجع.
• الأثر: يمكن للمهاجم القادر على التلاعب بالمستودع إخفاء التحديثات أو إعادة إدخال بيانات أهداف مفوضة قديمة دون أن يكتشفها العميل. على سبيل المثال، يمكنه تقديم ملف أهداف مفوضة أقدم موقّع بمفتاح أصبح مخترقًا الآن، ولأن Tough لم يتحقق من إصدار ذلك الملف، فسيتم قبوله. من الناحية العملية، قد يؤدي هذا إلى جلب العملاء لمحتوى قديم أو تفويت عمليات إبطال حرجة للأهداف المفوضة​. (انظر هنا)
• المعالجة: استخدم tough v0.20.0+، الذي ينفّذ فحصًا كاملًا لتراجع اللقطات​. إذا كنت تدير محدّثًا مخصصًا، فتأكد من أنه بالنسبة إلى كل ملف بيانات وصفية موثوق مدرج في لقطة ما، فإن اللقطة الجديدة تُدرجه أيضًا برقم إصدار >= الإصدار السابق. يُوصى أيضًا بتمكين التسجيل أو التدقيق لأي عمليات إزالة لأهداف مفوضة في تحديثات المستودع، حيث يجب أن تكون نادرة وقد تشير إلى نشاط ضار إذا حدثت بشكل غير متوقع.

CVE-2025-2888: التخزين المؤقت غير السليم للبيانات الوصفية للطابع الزمني عند التراجع

تعاملت Tough بشكل غير صحيح مع تراجع مكتشف في دور الطابع الزمني. يوقّع دور الطابع الزمني في TUF أحدث إصدار من البيانات الوصفية للقطة بشكل دوري لمساعدة العملاء على اكتشاف ما إذا كانوا يرون لقطة أقدم (تراجعًا). قامت Tough بالفعل بفحص التراجع على إصدار اللقطة الموجود في الطابع الزمني، ولكن فقط بعد تخزين البيانات الوصفية للطابع الزمني الجديد مؤقتًا محليًا. إذا تم اكتشاف تراجع، كانت Tough ترفض التحديث لكنها كانت قد خزّنت بالفعل الطابع الزمني غير الصالح باعتباره “الأحدث” في ذاكرتها المؤقتة. وهذا يعني أن طابعًا زمنيًا ضارًا (بإصدار لقطة قديم) يمكن أن يسمم ذاكرة العميل المؤقتة. وبعد ذلك، قد تظهر التحديثات المشروعة اللاحقة لـ Tough على أنها تراجعات (نظرًا لأن الذاكرة المؤقتة كانت تحتفظ بطابع زمني يشير إلى إصدار لقطة أعلى من الجديد)، مما يمنع التحديثات الصالحة.

• الاستشارة الأمنية: الاستشارة الأمنية من GitHub GHSA-76g3-38jv-wxh4 (CVE-2025-2888)
• الكود المتأثر: منطق تحديث الطابع الزمني في tough/src/lib.rs (الدالة التي تحمّل timestamp.json الجديد). كانت المشكلة الأساسية هي خطأ في ترتيب العمليات: قامت Tough بتحديث ذاكرتها المؤقتة/حالتها المحلية بالبيانات الوصفية للطابع الزمني الجديد قبل التحقق الكامل من أن إصدار اللقطة الموجود بداخلها ليس أقدم مما شاهدته سابقًا.

التنفيذ المعرض للخطر: في Tough <0.20.0، عند جلب timestamp.json جديد، كان العميل يحلله ويكتبه في الذاكرة المؤقتة (معتبرًا إياه الطابع الزمني الموثوق الحالي) ثم يقوم بفحص التراجع على إصدار اللقطة. إذا كان إصدار اللقطة في الطابع الزمني الجديد أقل من إصدار اللقطة المسجل سابقًا (مما يشير إلى محاولة تراجع)، كانت Tough تسجل خطأ وترفض دورة التحديث تلك – لكن الذاكرة المؤقتة كانت تحتوي بالفعل على الطابع الزمني “السيئ”. لم تتم إزالة الإدخال المخزن مؤقتًا في مسار الخطأ ذلك. وبالتالي، يمكن أن يصبح الطابع الزمني “الموثوق” المسجل لدى العميل هو هذا الطابع القديم.

على سبيل المثال، افترض أن آخر إصدار لقطة معروف كان 5. يمكن للمهاجم تقديم بيانات وصفية للطابع الزمني (برقم إصدار طابع زمني أعلى) توقّع إصدار اللقطة 4. ستقبل Tough ملف الطابع الزمني (مع تخزينه مؤقتًا)، ثم تلاحظ أن اللقطة 4 < 5 وتخرج من التحديث بخطأ – لكن ذاكرتها المؤقتة الآن تقول “أحدث طابع زمني يشير إلى اللقطة 4”. عندما يأتي طابع زمني صحيح (اللقطة 5 أو 6) بعد ذلك، ترى Tough اللقطة 5 مقابل اللقطة 4 المخزنة مؤقتًا كتراجع آخر (لأنها تثق بشكل خاطئ في إصدار اللقطة 4 المخزن مؤقتًا كخط أساس)، وبالتالي ترفض حتى التحديث الصالح. تصف نشرة AWS هذا التسلسل: “يقوم العميل بتخزين البيانات الوصفية للطابع الزمني مؤقتًا على الرغم من رفضها بشكل صحيح عند اكتشاف تراجع… مما يتسبب لاحقًا في فشل tough في استهلاك التحديثات الصالحة.”​

التنفيذ المُصلَح: يضمن الإصلاح أن فحوصات التراجع تتم قبل التخزين المؤقت للطابع الزمني الجديد، ويضيف تحققًا أكثر صرامةً لمحتويات الطابع الزمني. في Tough 0.20.0، تم تعديل الدالة load_timestamp() لفرض أن تكون البيانات الوصفية للطابع الزمني سليمة البنية وأن إصدار اللقطة الخاص بها لا يقل عن إصدار اللقطة الموثوق به سابقًا قبل إتمام التحديث. على وجه التحديد، يتحقق الكود الآن من: (أ) أن البيانات الوصفية للطابع الزمني تحتوي على إدخال واحد بالضبط (يجب أن يكون فقط لـ snapshot.json)، (ب) أن هذا الإدخال موجود وتم تحليله، و(ج) أن إصدار اللقطة بداخله >= إصدار اللقطة الأقدم. (انظر هنا) فقط بعد اجتياز هذه التحققات يُعتبر الطابع الزمني الجديد موثوقًا. المنطق الحاسم المضاف موضح أدناه:```rust // Ensure the timestamp meta contains exactly one entry (the snapshot) ensure!(timestamp.signed.meta.len() == 1, error::TimestampMetaLengthSnafu { … }); let snapshot_meta = timestamp.signed.meta.get("snapshot.json"); ensure!(snapshot_meta.is_some(), error::MissingSnapshotMetaSnafu { … });

// If we have a previously trusted timestamp (old_timestamp): if let Some(old_timestamp) = old_timestamp_opt { // Check that the snapshot version in the new timestamp >= old snapshot version let old_snapshot_meta = old_timestamp.signed.meta.get("snapshot.json").unwrap(); ensure!( old_snapshot_meta.version <= snapshot_meta.unwrap().version, error::OlderSnapshotInTimestampSnafu { // details: new snapshot vs old snapshot versions snapshot_new: snapshot_meta.unwrap().version, snapshot_old: old_snapshot_meta.version, timestamp_new: timestamp.signed.version, timestamp_old: old_timestamp.signed.version } ); }