Viktor Dukhovni

Processing a certificate containing numerous `nameRelativeToCRLIssuer` CRL distribution points can cause disproportionate heap growth when X.509 extensions are cached. A malicious peer can send a crafted certificate that, while remaining under the accepted size limit of approximately 100 KiB, triggers the allocation of several hundred MiB of resident memory during a standard TLS handshake. This excessive memory allocation can lead to significant memory pressure and a potential Denial of Service, potentially crashing the client or server if multiple concurrent connections occur.

SM2 signature generation uses non-constant-time arithmetic on secret values, creating a timing side-channel. The process computes the signature value using variable-time BIGNUM operations on the private key and the secret nonce, meaning the time required to produce a signature depends on these secret values. An attacker capable of measuring signing times may obtain information about the per-signature secret nonce, which could lead to the recovery of the private key through a lattice or Hidden Number Problem attack.

قد يحدث استدعاء مؤشر NULL في تكوينات الخادم أو العميل التي يتم فيها تمكين مفاتيح RFC7250 العامة الخام (RPKs)، ويتم تكوين مفتاح خاص محليًّا فقط دون شهادة مرتبطة به. يحدث هذا عندما يطلب نظير بعيد مفاتيح عامة خام ويتضمن ملحق TLS `signature algorithms cert`. قد تؤدي هذه المشكلة إلى حدوث هجوم رفض الخدمة (DoS) بسبب توقف التطبيق. إزالة مرجعية مؤشر NULL هي خطأ برمجي حيث يحاول البرنامج القراءة أو الكتابة إلى عنوان ذاكرة قيمته NULL، مما يؤدي عادةً إلى تعطل التطبيق.

عند استخدام خوارزمية التشفير AES-OCB مع واجهة `EVP Cipher()` التي تُستخدم لمرة واحدة، يتم تجاهل متجه التهيئة (IV) المقدم من التطبيق دون إشعار. يؤدي هذا إلى استخدام كل رسالة مشفرة بنفس المفتاح لنفس الرقم العشوائي الفعّال (nonce)، مما يؤدي إلى إعادة استخدام (المفتاح، الرقم العشوائي) وفقدان السرية. إذا تم استخدام نفس المسار لحساب علامة المصادقة، فإن العلامة تعتمد فقط على الزوج (المفتاح، متجه التهيئة) بدلاً من النص العادي أو النص المشفر، مما يسمح بالتزوير الشامل لأي نص مشفر من رسالة واحدة تم التقاطها. يحدث هذا لأن معالج الاستخدام لمرة واحدة يفشل في تفريغ متجه التهيئة (IV) في سياق OCB، على عكس معالج التدفق. إذا تم استخدام `EVP EncryptFinal ex()` لاحقًا للحصول على علامة المصادقة، فإن إعداد متجه التهيئة (IV) المؤجل يمسح المجموع الاختباري الجاري الذي كان ينبغي تجميعه على النص العادي.

عند استدعاء الدالة `EVP PKEY derive set peer()` باستخدام مفتاح نظير DHX (X9.42)، يفشل البرنامج في التحقق بشكل صحيح من عضوية المجموعة الفرعية. وعلى وجه التحديد، يتم إجراء الفحص `Y^q ≡ 1 (mod p)` باستخدام المعلمة `q` التي يوفرها النظير بدلاً من معلمة `q` الخاصة بالمفتاح المحلي. وفي حين تتم مطابقة معلمات المجال الأخرى مع المفتاح الخاص، لا تتم مقارنة قيمة `q`. وهذا يسمح لنظير خبيث بتقديم مفتاح X9.42 يحتوي على معلمتي `p` و`g` الخاصتين بالضحية، وقيمة `q` مزورة تساوي `r` (أحد العوامل الأولية الصغيرة للمعامل المساعد `(p−1)/q local`)، وقيمة عامة `Y` من الرتبة `r`. يؤدي هذا إلى تجاوز عمليات الفحص وينتج عنه سر مشترك يحتوي على `r` قيمة مميزة فقط، مما يؤدي إلى تسريب المفتاح الخاص وفقًا لمعيار `r`. من خلال تكرار هذه العملية لكل عامل أولي صغير من العامل المساعد ودمج النتائج باستخدام نظرية الباقي الصينية (CRT)، يمكن للمهاجم استعادة المفتاح الخاص بالكامل. يُعرف هذا باسم هجوم Lim–Lee أو هجوم حصر المجموعات الفرعية الصغيرة.

قد يؤدي تكوين غير شائع للعملاء الذين يقومون بمصادقة الخادم باستخدام DANE TLSA، عند اقترانه بسجلات DANE TLSA غير شائعة على الخادم، إلى حدوث ثغرة «الاستخدام بعد التحرير» و/أو «التحرير المزدوج» على جانب العميل. يمكن أن يؤدي الاستخدام بعد التحرير إلى تلف البيانات أو تعطل النظام أو تنفيذ تعليمات برمجية عشوائية. تؤثر هذه المشكلة على العملاء الذين يستخدمون سجلات TLSA مع استخدامات شهادات PKIX-TA(0/PKIX-EE(1)) و DANE-TA(2) على حد سواء. لا يتأثر العملاء الذين يعاملون سجلات PKIX TLSA على أنها غير قابلة للاستخدام أو الذين يدعمون استخدامات PKIX فقط. يجب أيضًا أن يتواصل العميل مع خادم ينشر مجموعة سجلات TLSA (TLSA RRset) تحتوي على كلا النوعين من سجلات TLSA.

يحدث تجاوز سعة عدد صحيح موقّع عند تحديد حجم المخزن المؤقت الوجهة لإخراج Unicode في الدالة `ASN1 mbstring ncopy()`، مما قد يؤدي إلى تجاوز سعة المخزن المؤقت للكومة. يحدث هذا في الدالتين `ASN1 mbstring copy()` و`ASN1 mbstring ncopy()` لأن حجم الوجهة لإخراج Unicode يُحسب كعدد صحيح موقّع. وعلى وجه التحديد، يحدث تجاوز السعة في الحساب عندما يصل الإدخال إلى حوالي 2^30 حرفًا من خلال إزاحة عدد أحرف الإدخال إلى اليسار بالنسبة لـ BMPSTRING (UTF-16) و UNIVERSALSTRING (UTF-32)، أو عن طريق جمع عدد البايتات لكل حرف بالنسبة لـ UTF8STRING. في أسوأ السيناريوهات التي تتضمن UNIVERSALSTRING عند 2^30 حرفًا، يعود الحجم إلى الصفر، مما يؤدي إلى تخصيص مساحة صغيرة يتم استبدالها لاحقًا بعدة غيغابايت من البيانات. وقد يؤدي ذلك إلى تعطل النظام، أو سلوك غير محدد، أو تنفيذ تعليمات برمجية يتحكم فيها المهاجم. يتطلب إحداث هذه المشكلة أن يقوم التطبيق باستدعاء `ASN1 mbstring copy()` أو `ASN1 mbstring ncopy()` مباشرةً، أو تسجيل نوع سلسلة مخصص عبر `ASN1 STRING TABLE add()` باستخدام مدخلات يتحكم فيها المهاجم تبلغ نصف جيجابايت أو أكثر.

يحدث اقتطاع للعدد الصحيح في وحدة فك الترميز ASN.1 عند تحليل بنية ASN.1 مُشفَّرة بتنسيق DER ومُصمَّمة خصيصًا، تحتوي على عنصر أساسي يتجاوز طوله 2 غيغابايت. تؤثر هذه المشكلة بشكل خاص على أنظمة تشغيل Unix وأنظمة مشابهة لها ذات 64 بت. قد يُعامل الطول المقطوع على أنه طلب لفحص المحتوى الثنائي بحثًا عن بايت صفري نهائي، مما يؤدي إلى قراءة زائدة لمخزن الذاكرة المؤقت (heap buffer). وقد يؤدي ذلك إلى حدوث هجوم «رفض الخدمة» (Denial of Service) عن طريق تعطيل التطبيق أو تحميل ذاكرة تتجاوز مخزن الإدخال المؤقت إلى كائن ASN.1 الذي تم فك تشفيره. تتأثر التطبيقات التي تمرر البيانات التي يزودها المهاجم إلى وظائف فك التشفير مثل ”d2i X509()“ أو ”d2i PKCS7()“ أو أي وظائف أخرى من نوع ”d2i *“.

توجد مشكلة في خوادم OpenSSL TLS 1.3 حيث قد يفشل الخادم في التفاوض على مجموعة تبادل المفاتيح المفضلة المتوقعة عندما تتضمن تهيئة مجموعة تبادل المفاتيح الخاصة به الإعداد الافتراضي باستخدام الكلمة الرئيسية «DEFAULT». وقد يؤدي ذلك إلى استخدام مجموعة تبادل مفاتيح أقل تفضيلاً، حتى في حالة دعم كل من العميل والخادم لمجموعة أكثر أمانًا، إذا لم تكن المجموعة المفضلة مدرجة في توقعات مشاركة المفاتيح الأولية للعميل. ويكتسب هذا الأمر أهمية خاصة مع المجموعات الهجينة الجديدة ما بعد الكمومية، حيث قد يؤجل العميل استخدامها حتى يطلبها الخادم بشكل صريح. والسبب الجذري هو عيب في التنفيذ يؤدي إلى فقدان قائمة «DEFAULT» لهيكلها «التوبولي»، مما يؤدي إلى معاملة جميع المجموعات التي يدعمها الخادم على أنها توبول واحد آمن بما فيه الكفاية، ويمنع الخادم من إرسال طلب إعادة محاولة الترحيب (Hello Retry Request - HRR) عندما تكون هناك مجموعة مفضلة أكثر مدعومة من كلا الطرفين. لا تؤثر هذه المشكلة على وحدات OpenSSL FIPS.

يحتوي OpenSSL على ثغرات أمنية ناتجة عن مشكلات في القراءة والكتابة خارج النطاق المسموح به. وعلى وجه التحديد، قد تحدث القراءة والكتابة خارج النطاق المسموح به عند فك تشفير رسائل CMS المشفرة باستخدام تشفير قائم على كلمة المرور، مما قد يؤدي إلى حدوث عطل أو تلف في الذاكرة. بالإضافة إلى ذلك، قد تحدث عملية قراءة خارج الحدود في وظائف واجهة برمجة تطبيقات (API) عميل HTTP عندما تكون متغير البيئة ’no proxy‘ محددة ويكون جزء المضيف من مكون السلطة في عنوان URL HTTP عبارة عن عنوان IPv6. لا تتأثر وحدات FIPS في إصدارات OpenSSL 3.5 و3.4 و3.3 و3.2 و3.1 و3.0.

قد يفشل العملاء الذين يستخدمون مفاتيح RFC7250 Raw Public Keys (RPKs) لمصادقة الخادم في اكتشاف أن الخادم لم يتم مصادقته. يحدث هذا لأن عمليات المصافحة TLS و DTLS لا تتوقف كما هو متوقع عند تعيين وضع التحقق `SSL VERIFY PEER`. يمكن أن تؤدي هذه المشكلة إلى هجمات الوسيط (man-in-the-middle) إذا اعتمد العميل على فشل عملية المصافحة لتحديد عدم تطابق المصادقة. يتم تعطيل مفاتيح RPK افتراضيًا؛ ولا تظهر المشكلة إلا عندما يقوم العملاء بتمكين استخدام RPK صراحةً ويرسل الخادم مفتاح RPK بدلاً من سلسلة شهادات X.509. لا تتأثر العملاء الذين يتحققون من النتيجة عن طريق استدعاء الدالة `SSL get verify result()` ويتخذون الإجراء المناسب. لا تتأثر وحدات FIPS في الإصدارات من 3.0 إلى 3.4.

تقوم أداة سطر الأوامر «openssl dgst» باقتطاع البيانات المدخلة بصمت إلى 16 ميغابايت عند استخدام خوارزميات التوقيع «one-shot»، وتُبلغ عن نجاح العملية بدلاً من الإبلاغ عن خطأ. قد يؤدي ذلك إلى اعتقاد المستخدم بأن الملف بأكمله قد تم توثيقه، في حين أن البيانات النهائية التي تتجاوز 16 ميغابايت تظل غير موثقة. تؤثر هذه المشكلة فقط على سلوك أداة سطر الأوامر ولا تؤثر على أدوات التحقق التي تعالج الرسالة الكاملة باستخدام واجهات برمجة التطبيقات (APIs) الخاصة بالمكتبة. كما لا تتأثر خوارزميات التلخيص المتدفقة (digest) الخاصة بـ «openssl dgst» ومستخدمي المكتبة. تحدث المشكلة عند استخدام خوارزميات التوقيع لمرة واحدة، مثل Ed25519 أو Ed448 أو ML-DSA. تقوم الأداة باقتطاع المدخلات إلى أول 16 ميغابايت وتستمر دون الإشارة إلى وجود خطأ، مما يخلق ثغرة في السلامة حيث يمكن تعديل البايتات النهائية دون أن يتم اكتشاف ذلك، إذا تم إجراء كل من التوقيع والتحقق باستخدام نفس مسار الكود المتأثر.

The issue is related to a denial of service in X.509 name checks. Applications performing certificate name checks, such as TLS clients checking server certificates, may attempt to read an invalid memory address when comparing the expected name with an `otherName` subject alternative name of an X.509 certificate. This may result in an exception that terminates the application program. Basic certificate chain validation is not affected, and the denial of service can occur only when the application also specifies an expected DNS name, Email address, or IP address. TLS servers are generally not affected, and the severity of the issue is Moderate.

Name of the Vulnerable Software and Affected Versions: OpenSSL versions prior to 3.3.3 Description: The issue arises from the use of low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial, leading to out-of-bounds memory reads or writes. This can cause an application crash or potentially allow for remote code execution. However, the likelihood of a vulnerable application is low, as most protocols involving Elliptic Curve Cryptography either support only "named curves" or specify an X9.62 encoding of binary (GF(2^m)) curves that cannot represent problematic input values. The affected APIs include `EC GROUP new curve GF2m()`, `EC GROUP new from params()`, and various supporting `BN GF2m *()` functions. Recommendations: For versions prior to 3.3.3, update to version 3.3.3 or later to resolve the issue. As a temporary workaround, consider restricting the use of the vulnerable `EC GROUP new curve GF2m()` and `EC GROUP new from params()` functions, as well as the supporting `BN GF2m *()` functions, until a patch is available. Avoid using "exotic" explicit binary (GF(2^m)) curve parameters that can represent invalid field polynomials with a zero constant term.

A read buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. This occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. The read buffer overrun might result in a crash, which could lead to a denial of service attack. In theory, it could also result in the disclosure of private memory contents, such as private keys or sensitive plaintext, although no working exploit leading to memory contents disclosure is known at the time of release of this advisory. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

The public API function BIO new NDEF is a helper function used for streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the SMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by end user applications. The function receives a BIO from the caller, prepends a new BIO f asn1 filter BIO onto the front of it to form a BIO chain, and then returns the new head of the BIO chain to the caller. Under certain conditions, for example if a CMS recipient public key is invalid, the new filter BIO is freed and the function returns a NULL result indicating a failure. However, in this case, the BIO chain is not properly cleaned up and the BIO passed by the caller still retains internal pointers to the previously freed filter BIO. If the caller then goes on to call BIO pop() on the BIO then a use-after-free will occur. This will most likely result in a crash. This scenario occurs directly in the internal function B64 write ASN1() which may cause BIO new NDEF() to be called and will subsequently call BIO pop() on the BIO. Other public API functions that may be impacted by this include i2d ASN1 bio stream, BIO new CMS, BIO new PKCS7, i2d CMS bio stream and i2d PKCS7 bio stream.

A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. This occurs after certificate chain signature verification and requires either a CA to have signed a malicious certificate or for an application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address in a certificate to overflow an arbitrary number of bytes containing the `.` character (decimal 46) on the stack. This buffer overflow could result in a crash (causing a denial of service). In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects.

The issue is related to the ` krb5 extract ticket()` function, which obtains service-principal names in a way that violates the Kerberos 5 protocol specification. This allows remote attackers to impersonate services with Orpheus' Lyre attacks. The problem arises because the function uses the unencrypted version of the service name stored in `ticket` instead of the encrypted version stored in `enc part`. This provides an opportunity for successful server impersonation and other attacks.

A security-feature bypass issue allows attackers to affect the system. This issue is related to Kerberos failing to prevent tampering with the SNAME field during ticket exchange.

The issue is related to the lack of protection for internal data in the Tcl component of the operating system. It can be exploited by a remote attacker to obtain sensitive information by leveraging SSLv2 support.