CVE-Datenbank

Bei Baicells Nova 430H kann ein nicht authentifiziertes Gerät innerhalb der Funkreichweite während des Verbindungsaufbaus eine fehlerhafte Uplink-Nachricht senden, die eine ungültige NAS-Nutzlast enthält. Da der eNodeB diese Nutzlast nicht ordnungsgemäß validiert, leitet er die Nachricht an das Kernnetz weiter, was eine Abschaltung der Signalisierungsassoziation für die Zelle auslösen kann. Dies führt zu einer vorübergehenden Dienstunterbrechung, bis der eNodeB und das Kernnetz die Verbindung wiederherstellen.

Ein Buffer Overflow in ANGLE in Google Chrome auf Android vor Version 154.0.8037.92 ermöglichte einem Remote-Angreifer, über eine präparierte HTML-Seite potenziell beliebigen Code außerhalb der Sandbox auszuführen. (Sicherheitsschweregrad von Chromium: Kritisch)

In der Firmwareversion 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 enthält das Gerät auf der seriellen Konsole einen veralteten Passwort-Hash, der auf einer schwachen DES-basierten Verschlüsselung beruht.

In der Firmwareversion 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 können zwei Endpunkte für Benutzerinformationen unter Bedingungen, die nicht für den normalen Betrieb vorgesehen sind, vertrauliche Geräte- und Kontodetails offenlegen.

In der Firmware-Version 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 kann eine nicht authentifizierte Netzwerkprüffunktion ausgelöst werden, um beliebige Hosts aus dem internen Netzwerk des Geräts zu untersuchen. Dadurch können interne Informationen offengelegt oder Daten über DNS-Abfragen durchsickern.

In der Firmwareversion 3.3.2.4 von Anjvision YSSD-RTMP-H5 setzt ein POST mit leerem Body an /setUserConfig, der über den SOAP-RPC-Handler des Webservers verarbeitet wird, das Administratorpasswort unbemerkt auf den Standardwert zurück und beschädigt den Authentifizierungsstatus im Arbeitsspeicher, bis das Gerät neu geladen wird. Der Handler überprüft die Berechtigungsstufe der Sitzung nicht, sodass jeder authentifizierte Benutzer dies auslösen kann.

In der Firmware-Version 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 kann eine interne Debug-Schnittstelle über einen undokumentierten Weg aktiviert werden, wodurch Funktionen offengelegt werden, die nicht für den normalen Betrieb vorgesehen sind. Bei Aktivierung ermöglicht diese Schnittstelle Aktionen, die unbeabsichtigt erweiterten Systemzugriff gewähren könnten.

In der Firmwareversion 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 sind fest codierte Cloud-API-Zugangsdaten eingebettet, die auf bereitgestellten Geräten gemeinsam genutzt werden. Jeder, der das öffentliche Firmwarepaket erhält, kann diese Werte wiederverwenden, um mit dem Cloud-Dienst auf eine Weise zu interagieren, die nicht für den normalen Betrieb vorgesehen ist.

In der Firmwareversion 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 wenden sowohl die lokalen als auch die cloudbasierten Aktualisierungsmechanismen neue Firmware ohne kryptografische Überprüfung an und verlassen sich lediglich auf einfaches Hashing. Dieses Design ermöglicht es einem Angreifer, der die Aktualisierungsroutine erreichen kann, nicht vertrauenswürdige Firmware-Images einzuschleusen, die das Gerät als gültig akzeptiert.

In der Firmware-Version 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 kann eine versteckte Debug-Schnittstelle über eine authentifizierte Anfrage aktiviert werden, wodurch zusätzliche Befehle an einen Backend-Dienst gesendet werden können. Sobald dieser Pfad aktiv ist, kann er unbeabsichtigt Funktionen auf Systemebene offenlegen, die missbraucht werden könnten, wenn präparierte Eingaben den zugrunde liegenden Befehls-Handler erreichen.

In der Firmwareversion 3.3.2.4 von Anjvision YSSD‑RTMP‑H5 verarbeiten mehrere ONVIF-Service-Endpunkte Verwaltungsanfragen, ohne die erforderliche Authentifizierung durchzusetzen. Dies könnte einem nicht autorisierten Angreifer den Zugriff auf sensible Geräteoperationen ermöglichen.

TeamViewer Full Client and Host for Linux vor Version 15.82 enthält eine Schwachstelle durch unzureichende Pfadvalidierung in der Funktion Cloud Session Recording (CSR). Durch Ausnutzen einer Race Condition während der Pfadvalidierung und des anschließenden Dateizugriffs kann ein lokal authentifizierter Angreifer privilegierte Dateivorgänge an nicht vorgesehenen Speicherorten auf dem betroffenen System verursachen.

Eine Schwachstelle bei der Zugriffskontrolle in TeamViewer Full Client, Host und verwandten betroffenen Modulen unter Windows, Linux und macOS ermöglicht es einem authentifizierten Angreifer aus der Ferne, während des Sitzungsaufbaus vom Benutzer konfigurierte Berechtigungseinstellungen zu umgehen. Durch die Änderung von Zugriffskontrollparametern für eingeschränkte Funktionen kann ein Angreifer Aktionen ausführen, die durch die Konfiguration des Opfers ausdrücklich untersagt wurden. Dies kann zu unbefugten Aktionen führen und möglicherweise eine Remotecodeausführung auf dem Zielsystem ermöglichen.

TeamViewer Full Client and Host vor Version 15.82 unter Windows enthalten eine TOCTOU-Race-Condition im Installer-Rollback-Mechanismus. Ein Angreifer mit niedrigen lokalen Berechtigungen kann Rollback-Sicherungsdateien, die in einem benutzerbeschreibbaren temporären Verzeichnis gespeichert sind, ersetzen, bevor sie von einem Installer mit erhöhten Rechten wiederhergestellt werden, was zu einer Privilegienausweitung auf NT AUHORITY/SYSTEM führt. Die Ausnutzung erfordert ein erfolgreiches Timing der Race-Condition und einen Rollback während der Installation oder Aktualisierung.

TeamViewer Full Client und Host für Linux und macOS vor Version 15.82 enthalten eine heap-basierte Buffer-Overflow-Schwachstelle bei der Verarbeitung von .tvs-Sitzungsaufzeichnungsdateien. Eine Größenabweichung während der Dekomprimierung aufgezeichneter Sitzungsdaten kann zu Schreibzugriffen außerhalb des Heap-Bereichs führen. Indem ein Angreifer einen Benutzer dazu bringt, über die Funktion „Play or convert recorded session…“ eine speziell gestaltete Sitzungsaufzeichnung zu öffnen, kann er beliebigen Code mit den Berechtigungen des aktuellen Benutzers ausführen.

Problemzusammenfassung: Ein böswilliger Remote-Peer kann den lokalen QUIC-Stack mit NEW_CONNECTION_ID-Frames überfluten, indem er eine Prüfung der Anzahl der Connection IDs umgeht, die der Remote-QUIC-Stack verwenden kann. Auswirkungszusammenfassung: Der lokale QUIC-Stack sendet für jeden NEW_CONNECTION_ID-Frame, den er empfängt, einen RETIRE_CONN_ID-Frame. Der RETIRE_CONN_ID-Frame wird über die Control Frame Queue (CFQ) weitergeleitet. Wenn der Remote-Peer außerdem ACKs zurückhält, kann er den lokalen Stack dazu zwingen, ~400 MB zuzuweisen (abhängig von der ACK-Verzögerung). CWE: CWE-770: Zuweisung von Ressourcen ohne Begrenzung oder Drosselung Beschreibung: Die Abschnitte 5.1.1 und 5.1.2 von RFC 9000 [1] beschreiben den Mechanismus, über den ein Remote-Peer den lokalen QUIC-Stack darüber informieren kann, die Ziel-Connection-ID (auch CID genannt) zu ändern, die der lokale Stack verwendet, um die Verbindung beim Remote-Peer zu identifizieren. Jede CID ist einer Sequenznummer zugeordnet. Die Sequenznummer wird in NEW_CONNECTION_ID- und RETIRE_CONNECTION_ID-Frames übertragen, um die CID zu identifizieren, die einer Verbindung zugeordnet oder ausgemustert wird. Der Remote-Peer sendet einen NEW_CONNECTION_ID-Frame, um den lokalen Stack darüber zu informieren, dass einer bestehenden Verbindung eine neue CID zugeordnet wird. Der NEW_CONNECTION_ID-Frame enthält die neue CID, ihre Sequenznummer und die Nummer retire-prior-to. retire-prior-to identifiziert bestehende CIDs, die ausgemustert werden sollen. Der lokale QUIC-Stack muss für jede Ziel-CID, deren Sequenznummer kleiner als retire-prior-to ist, einen RETIRE_CONNECTION_ID-Frame senden. Die CID wird ausgemustert, nachdem der lokale Stack eine ACK für seinen RETIRE_CONNECTION_ID-Frame empfangen hat. Obwohl der OpenSSL-QUIC-Stack höchstens eine Ziel-CID pro Verbindung unterstützt, kann er dazu gebracht werden, mehr als einen RETIRE_CONNECTION_ID-Frame pro Verbindung zu verarbeiten. Der OpenSSL-QUIC-Stack mustert die Ziel-CID derzeit aus, sobald er den NEW_CONNECTION_ID-Frame empfängt, obwohl die Ziel-CID erst ausgemustert werden darf, nachdem eine ACK für den RETIRE_CONNECTION_ID-Frame empfangen wurde. Die Korrektur der fehlerhaften Logik behebt auch das Anwachsen des Rückstaus. [1] https://datatracker.ietf.org/doc/html/rfc9000#name-issuing-connection-ids FIPS-Auswirkung: nein Das FIPS-Modul ist nicht betroffen, da die QUIC-Implementierung außerhalb der Grenze des OpenSSL-FIPS-Moduls liegt.

Zusammenfassung des Problems: Die erste gleichzeitige Verwendung desselben X.509-Zertifikats durch mehrere Threads kann dazu führen, dass dessen zwischengespeicherte Erweiterungsdaten freigegeben werden, während ein anderer Thread sie noch verwendet. Zusammenfassung der Auswirkungen: Ein entfernter, nicht authentifizierter Peer könnte einen Multithreaded- TLS-Client oder einen Multithreaded-TLS-Server zum Absturz bringen, der Client- Zertifikate anfordert, wenn die ersten Zertifikatsketten, die bis zum selben vertrauenswürdigen CA- Zertifikat aufgebaut werden, von mehreren Verbindungen gleichzeitig aufgebaut werden. Dies ist ein Use-after-free-Lesezugriff, der wahrscheinlich zum Absturz des Prozesses führt und damit einen Denial of Service verursacht. CWE: CWE-416: Use After Free Beschreibung: OpenSSL speichert die dekodierten Werte der X.509v3-Erweiterungen eines Zertifikats beim ersten Bedarf innerhalb des X509-Objekts zwischen. In OpenSSL 4.0 wird dieser Cache in zwei Phasen erstellt: Die Erweiterungswerte werden berechnet, während eine Lesesperre auf dem Zertifikat gehalten wird, und die Ergebnisse werden anschließend unter einer Schreibsperre im Zertifikat gespeichert. Da eine Lesesperre andere Leser nicht ausschließt, können mehrere Threads den Cache für dasselbe Zertifikat gleichzeitig berechnen. Jeder Thread, der anschließend die Schreibsperre erhält, speichert seine eigenen Ergebnisse und gibt die Werte frei, die vom vorherigen Thread gespeichert wurden, obwohl dieser frühere Thread den Cache bereits als vollständig markiert hat und möglicherweise Zeiger darauf an seinen Aufrufer zurückgegeben hat. Ein Aufrufer, der diese Zeiger noch verwendet, liest dann freigegebenen Speicher. Jedes zwischen Threads gemeinsam genutzte Zertifikat ist betroffen, wenn seine Erweiterungen zum ersten Mal dekodiert werden. Bei TLS sind die gefährdeten Zertifikate die vertrauenswürdigen CA- Zertifikate, die zur Überprüfung der Kette bereitgestellt werden, unabhängig davon, auf welche Weise, da diese von jeder Verbindung gemeinsam genutzt werden und ihre Erweiterungen beim ersten Aufbau einer Kette zu ihnen dekodiert und zwischengespeichert werden. Vom Peer gesendete Zertifikate werden für jede Verbindung separat dekodiert und nicht gemeinsam genutzt, sodass sie nicht betroffen sind. Bei einem TLS-Client, der Serverzertifikate überprüft, oder einem TLS-Server, der Client-Zertifikate anfordert und überprüft, kann der Use-after-free nur auftreten, wenn die ersten Ketten, die bis zur selben vertrauenswürdigen CA aufgebaut werden, von mehreren Verbindungen gleichzeitig aufgebaut werden. FIPS-Auswirkung: nein Das FIPS-Modul ist nicht betroffen, da die Verarbeitung von X.509-Zertifikaten außerhalb der Grenzen des OpenSSL-FIPS-Moduls liegt. OpenSSL 4.0 ist von diesem Problem betroffen. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 und 1.0.2 sind von diesem Problem nicht betroffen. Benutzer von OpenSSL 4.0 sollten auf OpenSSL 4.0.3 aktualisieren. Dieses Problem wurde am 27. August 2026 von Tim Becker (Xint.io) und unabhängig davon in einem öffentlichen Bericht am 31. August 2026 von aydinmercan gemeldet. Die Behebung wurde von Bob Beck entwickelt. -- Schnitt (nicht zur Veröffentlichung bestimmte Metadaten zur internen Verwendung) -- Gemeldet von: Tim Becker (Xint.io), aydinmercan Behoben von: Bob Beck

Zusammenfassung des Problems: Die DTLS-Wiederholungslogik behandelt einen Schreibvorgang einer Handshake-Nachricht, der mitten im Vorgang angehalten wird, nicht korrekt. Die erneut übertragene Nachricht kann über das Ende des Nachrichtenpuffers hinaus gelesen werden, und die Wiederholung überschreibt den internen Zustand, den der angehaltene Schreibvorgang benötigt, um korrekt fortgesetzt zu werden. Zusammenfassung der Auswirkungen: Die erneut übertragene Nachricht kann dem Peer einen Heap-Speicherbereich als Klartext-Handshake-Daten offenlegen oder einen Absturz und einen Denial of Service verursachen, wenn der Lesevorgang einen nicht zugeordneten Speicherbereich erreicht. CWE: CWE-125: Out-of-bounds Read Beschreibung: DTLS-Handshake-Nachrichten können in mehreren Fragmenten geschrieben werden, und ein Schreibvorgang kann mitten in der Nachricht angehalten werden (mit Rückgabe von WANT_WRITE), wenn der zugrunde liegende Transport vorübergehend keine weiteren Daten annehmen kann. Während ein solcher Schreibvorgang angehalten ist, kann der DTLS-Wiederholungszeitgeber unabhängig davon auslösen und die Wiederholungslogik auffordern, eine frühere Nachricht aus ihrer Wiederholungswarteschlange erneut zu senden, deren Übertragung bereits bestätigt wurde. Die Wiederholungslogik verwendete denselben internen Puffer und dieselbe Positionsverfolgung wie die Nachricht, die noch geschrieben wurde, ohne die Position auf den Anfang der erneut zu übertragenden Nachricht zurückzusetzen. Dadurch begann das Lesen für die Wiederholung an der Stelle, an der der angehaltene Schreibvorgang aufgehört hatte. So entstand eine falsch gekennzeichnete Nachricht, deren Inhalt aus verbleibenden Bytes der anderen, größeren, noch in Übertragung befindlichen Nachricht bestand – Inhalt, der zu diesem Zeitpunkt nie gesendet werden sollte und über das Ende des zugewiesenen Puffers hinausgehen konnte. Unabhängig davon überschreibt eine bis zum Abschluss ausgeführte Wiederholung, selbst wenn sie an der korrekten Position beginnt, dieselben gemeinsam genutzten Verwaltungsdaten, auf die der angehaltene Schreibvorgang zum Fortsetzen angewiesen ist. Wenn die Anwendung den angehaltenen Schreibvorgang später fortsetzt (über einen nachfolgenden Aufruf von SSL_read(), SSL_write(), SSL_accept() oder SSL_connect()), stellt sie fest, dass sich diese Verwaltungsdaten in einem mit der Nachricht inkonsistenten Zustand befinden, und bricht den Prozess in einem Debug-Build ab. Die Korrektur setzt die Leseposition der Wiederholung vor dem erneuten Senden auf den Anfang der Nachricht zurück und überspringt Wiederholungen vollständig, solange ein Handshake-Schreibvorgang angehalten ist; sie werden stattdessen bis zum nächsten Aufruf zurückgestellt, der diesen fortsetzt. FIPS-Auswirkung: nein Der betroffene Code liegt außerhalb der FIPS-Modulgrenze.

Problemzusammenfassung: Die SM2-Signaturerstellung verwendet nicht konstante Laufzeitarithmetik auf geheimen Werten und bildet dadurch einen Timing-Side-Channel. Auswirkungszusammenfassung: Ein Angreifer, der SM2-Signaturzeiten messen kann, könnte Informationen über die geheime Nonce pro Signatur erfahren, was über viele Signaturen mittels eines Gitter-/Hidden-Number-Problem-Angriffs zur Wiederherstellung des privaten Schlüssels führen kann. CWE: CWE-208: Beobachtbare Timing-Abweichung Beschreibung: Die SM2-Signaturerstellung berechnet den Signaturwert mithilfe von BIGNUM-Operationen mit variabler Laufzeit auf der geheimen Nonce und dem privaten Schlüssel, sodass die zur Erstellung einer SM2-Signatur benötigte Zeit von diesen geheimen Werten abhängt und dadurch einen Timing-Side-Channel bildet. Anwendungen, die SM2-Signaturerstellung durchführen, sind auf allen Plattformen betroffen. FIPS-Auswirkung: nein SM2 ist kein FIPS-Algorithmus.

Problemzusammenfassung: Eine etablierte DTLS-1.2-Assoziation mit einer AEAD-Verschlüsselungssuite kann durch ein einzelnes nicht authentifiziertes Datagramm beendet werden, dessen verschlüsseltes Fragment kürzer ist als der obligatorische Overhead aus explizitem IV und Authentifizierungstag. Zusammenfassung der Auswirkungen: Ein Angreifer, der ein Datagramm senden kann, das an eine bestehende DTLS-1.2-Assoziation weitergeleitet wird, kann diese Assoziation beenden, ohne Schlüsselmaterial zu kennen. Dies ist ein Denial of Service, der auf die angegriffene Assoziation beschränkt ist. Es gibt keine Auswirkungen auf die Speichersicherheit oder Vertraulichkeit. CWE: CWE-1284: Improper Validation of Specified Quantity in Input Beschreibung: In TLS 1.2 und DTLS 1.2 enthält jeder durch eine AEAD-Verschlüsselungssuite geschützte Record einen expliziten IV, gefolgt vom Ciphertext und einem Authentifizierungstag. Beim Entschlüsseln eines solchen Records übergab die Record-Schicht die Record-Länge an die Cipher-Implementierung, bevor sie prüfte, ob der Record lang genug war, um den expliziten IV und den Tag zu enthalten. Bei einem Record, der kürzer als dieser Overhead war, lehnte die Cipher-Implementierung die unmögliche Länge ab, und die Record-Schicht behandelte dies als internen Fehler und löste einen fatalen internal_error-Alert aus, anstatt den Record als einen zu behandeln, dessen Authentifizierung fehlgeschlagen war. In TLS 1.2 verursacht derselbe Record einen fatalen internal_error-Alert anstelle des erwarteten bad_record_mac-Alerts. Da jeder nicht entschlüsselbare Record eine TLS-Verbindung ohnehin beendet, handelt es sich bei TLS um ein Problem der Protokollkonformität und nicht um ein Sicherheitsproblem. Die Korrektur validiert die Record-Länge anhand der Länge des expliziten IV und des Tags, bevor AEAD-Verarbeitung stattfindet, sodass TLS bad_record_mac meldet und DTLS den Record stillschweigend verwirft. FIPS-Auswirkungen: nein Der betroffene Code liegt außerhalb der Grenzen des FIPS-Moduls.