David Gstir

توجد مشكلة في التحقق غير السليم من الشهادات في ملف `crypto/swupdate cms verify openssl.c`. يثق النظام في شهادات X.509 غير الموثوقة المضمنة في CMS SignedData أثناء عملية بناء السلسلة. يسمح هذا للمهاجم الذي يمتلك مفتاح توقيع من وسيط شقيق تحت نفس الجذر بتضمين ذلك الوسيط في التوقيع وتثبيت تحديثات ضارة.

يحدث تجاوز سعة عدد صحيح في الدالة ext4fs read symlink في Das U-Boot. ويحدث ذلك عند استخدام نظام ملفات ext4 تم التلاعب به بحيث يكون حجم وحدة inode 0xffffffff، مما يتسبب في تخصيص ذاكرة (malloc) بقيمة صفر وبالتالي الكتابة فوق الذاكرة. تظهر المشكلة عند إضافة واحد إلى متغير LE32 في الدالة zalloc.

يحدث تجاوز سعة عدد صحيح في الدالة `sqfs resolve symlink` في DAS U-Boot عبر نظام ملفات squashfs مزور بحجم inode يبلغ `0xffffffff`، مما يؤدي إلى تخصيص malloc بقيمة صفر وما يترتب على ذلك من الكتابة فوق الذاكرة. يمكن استغلال هذه المشكلة عبر نظام ملفات squashfs تم التلاعب به.

تحدث مشكلة في استهلاك المكدس في الدالة sqfs size في DAS U-Boot من خلال نظام ملفات squashfs تم التلاعب به باستخدام تداخل عميق للروابط الرمزية. تؤثر هذه المشكلة على وظيفة تحليل الروابط الرمزية في SquashFS، مما يؤدي إلى حدوث تجاوز سعة المكدس.

تحدث حالات تجاوز سعة الأعداد الصحيحة في تخصيص الذاكرة لنظام ملفات squashfs مصمم خصيصًا عبر `sbrk`، أو عبر `request2size`، أو بسبب سوء التعامل مع `ptrdiff t` على x86 64. تؤثر هذه المشكلة على تخصيص الذاكرة في DAS U-Boot.

تتعلق المشكلة بخطأ «off-by-one» في الدالة sqfs search dir، مما يؤدي إلى تلف ذاكرة الهيب عند سرد دلائل SquashFS. يحدث هذا الخطأ لأن فاصل المسار لا يؤخذ في الاعتبار عند حساب الحجم.

تم تحديد مشكلة في نواة Linux حيث يمكن أن تتسبب مفاتيح DCP الموثوقة في حدوث تعطل أثناء تشفير وفك تشفير مفتاح تشفير blob عبر برنامج تشغيل crypto الخاص بـ DCP عندما تكون عناوين المكدس vmalloc ممكّنة. ويعود سبب ذلك إلى الاستخدام غير الصحيح لـ `sg init one()` مع مخازن مؤقتة مخصصة عبر vmalloc، وتحديدًا `plain key blob`.

Name of the Vulnerable Software and Affected Versions: tgt versions prior to 1.0.93 Description: The issue is related to the Linux target framework (tgt) attempting to generate random numbers by using `rand` without `srand`, resulting in a predictable PRNG seed. This causes the sequence of challenges to be always identical. An attacker capable of recording network traffic can abuse this by replaying previous responses, potentially leading to a CHAP authentication bypass. Recommendations: For versions prior to 1.0.93, update to version 1.0.93 or later to resolve the issue. As a temporary workaround, consider restricting access to the tgt framework until a patch is applied. Avoid using the tgt framework for authentication until the issue is resolved.

The issue is related to the handling of trusted keys in the Linux kernel. Specifically, when importing a trusted DCP-based key and then exporting it again, the blob encryption key (BEK) is decrypted in-place, causing the trusted key blob field to hold the BEK in plain text. As a result, every subsequent read of that key sends the plain text BEK instead of the encrypted BEK to userspace. This issue is rare and typically occurs when importing a trusted DCP-based key and then exporting it again, which is not a common use case.

The issue is related to the use of `rand()` as a fallback when `CARES RANDOM FILE` is not set, which can allow an attacker to exploit the lack of entropy by not using a Cryptographically Secure Pseudorandom Number Generator (CSPRNG). This can potentially impact the integrity of protected information. The issue is specifically observed when cross-compiling c-ares for aarch64 android using the autotools build system.

The issue arises when /dev/urandom or RtlGenRandom() are unavailable, and c-ares uses `rand()` to generate random numbers for DNS query ids. This approach is not a Cryptographically Secure PseudoRandom Number Generator (CSPRNG) and lacks seeding by `srand()`, resulting in predictable output. The input from the random number generator is then used in a non-compliant RC4 implementation, potentially weakening its strength. Modern OS-provided CSPRNGs, such as `arc4random()`, are not utilized.