Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. When resolving dependencies in versions before 9.3.0, some exceptions were not treated as fatal errors and would not cause a repository to be disabled. If a build encountered one of these exceptions, Gradle would continue to the next repository in the list and potentially resolve dependencies from a different repository. If a Gradle build used an unresolvable host name, Gradle would continue to work as long as all dependencies could be resolved from another repository. An unresolvable host name could be caused by allowing a repository's domain name registration to lapse or typo-ing the real domain name. This behavior could allow an attacker to register a service under the host name used by the build and serve malicious artifacts. The attack requires the repository to be listed before others in the build configuration. Gradle has introduced a change in behavior in Gradle 9.3.0 to stop searching other repositories when encountering these errors.
Gradle versions before 9.3.0 fail to treat certain repository resolution exceptions as fatal errors, allowing attackers to register expired or mistyped domain names and serve malicious artifacts. This supply chain attack vector is particularly dangerous in Saudi development environments where build pipelines may not validate artifact sources. Organizations must immediately upgrade to Gradle 9.3.0 or later to prevent dependency poisoning attacks.
IMMEDIATE ACTIONS:
1. Audit all Gradle build configurations (build.gradle, settings.gradle) to identify repository declarations and ordering
2. Verify all repository URLs for typos and confirm domain registrations are active
3. Implement repository URL validation and DNS resolution checks in build pipelines
PATCHING GUIDANCE:
1. Upgrade Gradle to version 9.3.0 or later immediately across all development environments
2. Update gradle-wrapper.properties in all projects to reference patched version
3. Rebuild all artifacts with patched Gradle version
4. Validate no malicious artifacts were resolved during the vulnerability window
COMPENSATING CONTROLS (if immediate patching not possible):
1. Implement repository URL whitelisting and disable fallback to secondary repositories
2. Configure repository authentication and certificate pinning
3. Use artifact signature verification and checksums for all dependencies
4. Implement network-level DNS filtering to prevent resolution of suspicious domains
5. Deploy artifact scanning tools (OWASP Dependency-Check, Snyk) in CI/CD pipeline
DETECTION RULES:
1. Monitor Gradle build logs for repository resolution failures followed by successful resolution from alternate repositories
2. Alert on DNS resolution failures for configured repository domains
3. Track artifact downloads from unexpected repositories or with mismatched checksums
4. Implement Software Composition Analysis (SCA) to detect suspicious or newly-registered artifact sources
الإجراءات الفورية:
1. تدقيق جميع تكوينات بناء Gradle (build.gradle و settings.gradle) لتحديد تصريحات المستودعات والترتيب
2. التحقق من جميع عناوين URL للمستودعات بحثاً عن الأخطاء الإملائية والتأكد من أن تسجيلات النطاق نشطة
3. تنفيذ التحقق من صحة عنوان URL للمستودع وفحوصات دقة DNS في خطوط الأنابيب
إرشادات التصحيح:
1. ترقية Gradle إلى الإصدار 9.3.0 أو أحدث فوراً عبر جميع بيئات التطوير
2. تحديث gradle-wrapper.properties في جميع المشاريع للإشارة إلى الإصدار المصحح
3. إعادة بناء جميع القطع الأثرية باستخدام إصدار Gradle المصحح
4. التحقق من عدم حل أي قطع أثرية ضارة أثناء نافذة الضعف
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تنفيذ قائمة بيضاء لعناوين URL المستودعات وتعطيل الرجوع إلى المستودعات الثانوية
2. تكوين مصادقة المستودع وتثبيت الشهادات
3. استخدام التحقق من توقيع القطع الأثرية والمجاميع الاختبارية لجميع الاعتماديات
4. تنفيذ تصفية DNS على مستوى الشبكة لمنع دقة النطاقات المريبة
5. نشر أدوات فحص القطع الأثرية (OWASP Dependency-Check و Snyk) في خط أنابيب CI/CD
قواعد الكشف:
1. مراقبة سجلات بناء Gradle بحثاً عن فشل حل المستودع متبوعاً بحل ناجح من مستودعات بديلة
2. التنبيه على فشل دقة DNS لنطاقات المستودع المكونة
3. تتبع تنزيلات القطع الأثرية من مستودعات غير متوقعة أو بمجاميع اختبارية غير متطابقة
4. تنفيذ تحليل تكوين البرنامج (SCA) للكشف عن مصادر قطع أثرية مريبة أو مسجلة حديثاً