CVE-Datenbank

Eine Authentifizierungsumgehung in N-central < 2026.3 HF 3 führt zu einer Authentifizierungsumgehung in nur internen APIs

Tycon Systems TPDIN-Monitor-WEB3 Versionen 2.2.9 und früher sind anfällig für eine Schwachstelle durch fehlende Autorisierung. Dies könnte es einem Angreifer ermöglichen, Systemanmeldedaten, Konfigurationen oder Flash-Inhalte zu extrahieren.

In Ignition 8.1.53 und früher wurde die Gateway-Einstellung "Create Project Role(s)" leer ausgeliefert, was jedem authentifizierten Benutzer das Erstellen von Projekten ermöglichte (wenn er Gateway-Skripte ausführen kann). Ignition 8.1.54 beschränkt die Projekterstellung auf Designer-Sitzungen und stützt sich nicht mehr auf diese Einstellung. Die 8.3-Serie ist nicht betroffen.

Unzureichende Neutralisierung von CRLF-Sequenzen im IXON VPN Client vor Version 1.4.7 ermöglicht es einem Angreifer, Befehle als root oder SYSTEM auszuführen. Vom lokalen Dienst akzeptierte Konfigurationswerte werden in eine Datei geschrieben, die später von einem privilegierten Unterprozess verarbeitet wird, ohne dass Zeilenendesequenzen neutralisiert werden, wodurch zusätzliche Direktiven in diese Datei eingebracht werden können. Die Konfigurationsschnittstelle akzeptiert Änderungen, ohne den Anforderer zu authentifizieren oder die Herkunft der Anfrage zu überprüfen. Die eingeschleuste Konfiguration bleibt über Neustarts des Clients und des Betriebssystems hinweg auf der Festplatte bestehen, und die VPN-Verbindung funktioniert weiterhin normal, sodass für den Benutzer keine Verhaltensänderung sichtbar ist.

Tycon Systems TPDIN-Monitor-WEB3 Versionen 2.2.9 und früher sind anfällig für eine Cross-Site Request Forgery-Schwachstelle. Dies könnte einem Angreifer ermöglichen, zustandsändernde Operationen auf dem Gerät durchzuführen.

Tycon Systems TPDIN-Monitor-WEB3 Versionen 2.2.9 und früher sind anfällig für eine Schwachstelle durch die Verwendung hartcodierter Anmeldedaten. Dies könnte es einem Angreifer ermöglichen, sensible Informationen oder Anmeldedaten abzufangen.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Eingabegerät erst nach dem Setzen der Capabilities registrieren input_register_device() macht das Gerät sofort für den Userspace sichtbar. In joycon_input_create() wurde sie aufgerufen, bevor joycon_config_rumble() die FF_RUMBLE-Capability und das memless Force-Feedback-Device konfiguriert, sodass ein gleichzeitiges EVIOCSFF ein NULL dev->ff dereferenzieren könnte. Eine frühe Registrierung bedeutet außerdem, dass dem initialen udev-Event Tasten- und Achseninformationen fehlen, wodurch Input-Manager das Gerät ignorieren können. input_register_device() an das Ende von joycon_input_create() verschieben, nachdem alle Capabilities, das IMU-Eingabegerät und die Force-Feedback-Callbacks konfiguriert wurden.

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: xfrm: ah6: segments_left im Routing-Header validieren AH6 ordnet die Adressen des Routing-Headers vor der Berechnung oder Überprüfung des ICV neu an. ipv6_rearrange_rthdr() geht davon aus, dass segments_left nicht größer ist als die Anzahl der Adressen, die durch das hdrlen-Feld des Routing-Headers beschrieben wird. Diese Annahme gilt nicht für rohe IPv6-HDRINCL-Pakete. Ein Paket mit hdrlen gleich 2 beschreibt eine Adresse, kann aber einen beliebigen segments_left-Wert enthalten. Bei segments_left gleich 255 verschiebt die Funktion ihren Adresszeiger um 4.064 Bytes rückwärts und übergibt memmove() eine Länge von 4.064 Bytes, was zu einem out-of-bounds access führt. Die Invariante lokal validieren, bevor der Routing-Header geändert oder irgendeine Adresszeigerarithmetik durchgeführt wird, und Fehler aufgrund fehlerhafter Header an die bestehenden AH6-Eingangs- und -Ausgangsfehlerpfade weiterleiten.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: magicmouse: verhindere unbeschränkte Rekursion in magicmouse_raw_event() magicmouse_raw_event() verarbeitet DOUBLE_REPORT_ID (0xf7)-Pakete, die zwei Touch-Reports in einen packen, indem das Paket aufgeteilt und für jede Hälfte die Funktion selbst aufgerufen wird. Die einzige Schutzmaßnahme gegen eine unkontrollierte Rekursion ist eine "size < 1"-Überprüfung, die Aufrufe der Größe Null stoppt, aber die Rekursionstiefe nicht begrenzt. Ein bösartiges HID-Gerät, das zu diesem Treiber passt, kann einen Report senden, der mit DOUBLE_REPORT_ID beginnt und mit der Sequenz [0xf7, 0x00] gefüllt ist. Jede Ebene verbraucht zwei Bytes und ruft mit dem Rest rekursiv auf, sodass ein eingehender Report von bis zu HID_MAX_BUFFER_SIZE (16 KiB) etwa 8000 verschachtelte Aufrufe verursacht. Dies erschöpft leicht den 16 KiB großen Kernel-Stack, was zu einem Stack Overflow führt: einem Panic mit CONFIG_VMAP_STACK oder Speicherkorruption ohne dieses. Ein Doppelbericht umhüllt immer nur zwei normale Reports; er ist nie legitim verschachtelt. Verweigere den erneuten Eintritt in den DOUBLE_REPORT_ID-Fall aus einem rekursiven Aufruf, sodass die Rekursionstiefe auf zwei begrenzt ist, während alle gültigen Pakete weiterhin genau wie zuvor geparst werden.

Im Linux-Kernel wurde die folgende Sicherheitslücke behoben: HID: pidff: OOB-Schreibzugriff, wenn hid->inputs leer ist hid_pidff_init_with_quirks() leitet sein input_dev aus list_entry(hid->inputs.next, struct hid_input, list) ab, ohne zuvor zu prüfen, ob hid->inputs nicht leer ist. Das Listenelement von struct hid_input befindet sich an Offset 0, daher liefert list_entry() bei einer leeren Liste &hid->inputs selbst, und der folgende Ladevorgang von hidinput->input liest ein unabhängiges Member von struct hid_device. dev ist dann ein typverfälschter Pointer, und die Force-Feedback-Initialisierung schreibt über ihn: Jedes set_bit(FF_*, dev->ffbit) speichert 8 Bytes bei dev + 192, hinter dem Ende des Objekts, auf das dev tatsächlich verweist, und input_ff_create() fügt weitere Schreibvorgänge eines Heap-Pointers und zweier Funktions-Pointer hinzu. Bis zu hid-universal-pidff war der einzige Aufrufer hid_pidff_init() aus usbhid, das unter HID_CLAIMED_INPUT ausgeführt wird und daher immer mindestens ein hid_input besitzt. universal_pidff_probe() startet das Gerät mit HID_CONNECT_DEFAULT & ~HID_CONNECT_FF und ruft anschließend hid_pidff_init_with_quirks() direkt auf, sobald der Deskriptor eine PID-Usage Page enthält, wodurch diese Prüfung umgangen wird. Ein Report-Deskriptor, dessen einzige Application Collection sich auf HID_UP_PID befindet, lässt hid->inputs leer, während hid_connect() über den hidraw-Claim weiterhin erfolgreich ist, sodass die Ausführung den nicht abgesicherten list_entry() erreicht. Der Schreibvorgang findet im USB-Probe-Pfad auf der Hotplug-Workqueue statt, sodass das Anschließen eines bösartigen Geräts ausreicht, um ihn auszulösen; weder Angreifer-Software noch ein angemeldeter Benutzer sind erforderlich. KASAN meldet einen 8-Byte-Out-of-Bounds-Schreibzugriff in hid_pidff_init_with_quirks(), der von universal_pidff_probe() aus erreicht wird. Vor dem Ableiten von dev auf eine leere Liste prüfen und -ENODEV zurückgeben, wie es die anderen HID-Force-Feedback-Treiber bereits tun. universal_pidff_probe() gibt den Fehler weiter und wickelt die Ausführung zurück ab. Entdeckt von XBOW, analysiert von Baul Lee <[email protected]>

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Out-of-Bounds-Read in joycon_ctlr_read_handler() behoben joycon_ctlr_read_handler() castet einen eingehenden HID-Eingabebericht auf struct joycon_input_report und parst ihn, wobei der Cast nur durch eine 12-Byte-Längenprüfung abgesichert ist: if (size >= 12) /* make sure it contains the input report */ joycon_parse_report(ctlr, (struct joycon_input_report *)data); struct joycon_input_report ist 49 Bytes groß: ein 13-Byte-Header gefolgt von einer Union, deren IMU-Arm 36 Bytes groß ist. Für einen IMU-Bericht durchläuft joycon_parse_report() -> joycon_parse_imu_report() diese Union (Struktur-Offsets 13..48), sodass ein Bericht von genau 12 Bytes mit data[0] == JC_INPUT_IMU_DATA die Prüfung besteht, aber bis zu 37 Bytes über seine deklarierte Länge hinaus gelesen wird. Die überlesenen Bytes werden in Beschleunigungs-/Gyroskopwerte dekodiert und über das Eingabegerät „(IMU)“ an den Userspace weitergegeben, wodurch treiberinterner Speicher offengelegt wird. data[0] und size werden vollständig von einem bösartigen oder gefälschten Joy-Con/Pro Controller kontrolliert. Empfangspuffer werden auf die maximale Berichtslänge dimensioniert, daher handelt es sich um ein Überlesen innerhalb der Zuweisung und nicht um ein Slab-OOB, aber die dekodierten Bytes erreichen weiterhin den Userspace. Der verwandte Subcmd-Pfad in joycon_ctlr_handle_event() begrenzt denselben Cast bereits korrekt: if (size < sizeof(struct joycon_input_report) || data[0] != JC_INPUT_SUBCMD_REPLY) break; Verwende hier dieselbe Begrenzung mit sizeof(struct joycon_input_report).

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: nintendo: Geräte-IO vor hid_hw_stop bei Probefehler stoppen nintendo_hid_probe() ruft hid_device_io_start() vor joycon_init() und joycon_leds_create() auf. Wenn eine der beiden fehlschlägt, springt der Fehlerpfad zu err_close, das hid_hw_close()/hid_hw_stop() aufruft, ohne zuerst hid_device_io_stop() aufzurufen. hid_hw_stop() stoppt die Geräte-IO nicht, sodass hid_input_report() weiterhin laufen und auf Treiberdaten zugreifen kann, die gerade abgebaut werden, was zu einem use-after-free führt. Füge ein err_io_stop-Label hinzu, das hid_device_io_stop() vor hid_hw_close() aufruft, und verweise die beiden Fehlerpfade nach io_start darauf.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: ft260: Behebung eines stack-use-after-return-Schreibzugriffs in I2C-Lese-Race ft260_i2c_read() lässt dev->read_buf auf einen vom Aufrufer übergebenen Puffer zeigen (oft eine Variable auf dem Stack), aktiviert eine Completion und wartet bis zu fünf Sekunden darauf, dass das Gerät die Daten zurückgibt. Der HID-Eingabe-Callback ft260_raw_event() läuft im Input-/IRQ-Pfad, unabhängig vom durch den Lesepfad gehaltenen dev->lock-Mutex, und kopiert die vom Gerät gelieferte Payload nach einer einfachen NULL-Prüfung nach dev->read_buf. Diese beiden Pfade teilen sich read_buf, read_idx und read_len ohne Serialisierung. Verzögert das Gerät seine Antwort, bis die Leseoperation in einen Timeout läuft, setzt ft260_i2c_read() den Controller zurück, löscht read_buf und kehrt zurück, wobei der Stack-Frame, in dem sich der Puffer befand, abgebaut wird. Eine Antwort, die in diesem Moment eintrifft, lässt ft260_raw_event() die NULL-Prüfung bestehen und dann mittels memcpy() die vom Gerät kontrollierte Payload in die nun freigegebene Stack-Stelle schreiben, ein begrenzter, aber vom Angreifer beeinflusster stack-use-after-return-Schreibzugriff, auslösbar durch bösartige oder fehlerhafte Hardware. Füge einen dedizierten Spinlock hinzu, der jeden Zugriff auf read_buf, read_idx und read_len serialisiert. ft260_raw_event() hält ihn nun über die NULL-Prüfung, das memcpy und die Indexaktualisierung hinweg, während der Lesepfad ihn beim Aktivieren und beim Löschen des Puffers nimmt, sodass die Bereinigung nicht mehr zwischen Prüfung und Kopie fallen kann.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: sensor: custom: Use-after-free in enable_sensor behoben enable_sensor_store() kann set_power_report_state() aufrufen, das sensor_inst->power_state und sensor_inst->report_state dereferenziert. Diese Zeiger verweisen auf Einträge in sensor_inst->fields. Die Feldattribute werden erstellt, bevor das enable_sensor-sysfs-Attribut bereitgestellt wird, sodass auf enable_sensor nicht zugegriffen werden kann, bevor der Zustand, von dem es abhängt, initialisiert wurde. Beim Entfernen wird enable_sensor gelöscht, bevor die Feldattribute freigegeben werden, sodass ein gleichzeitiges sysfs-Schreiben keinen freigegebenen Speicher über power_state oder report_state dereferenzieren kann.

Im Linux-Kernel wurde die folgende Schwachstelle behoben: HID: uclogic: Use-after-free von inrange_timer beim Entfernen beheben uclogic_remove() bricht den Pen-In-Range-Timer ab und stoppt dann das Gerät: timer_delete_sync(&drvdata->inrange_timer); hid_hw_stop(hdev); timer_delete_sync() garantiert nur, dass der Timer in diesem Moment inaktiv ist. uclogic_raw_event_pen() liefert weiterhin Pen-Reports, bis hid_hw_stop() den Transport einige Zeilen später stoppt, und jeder Report mit pen->inrange == UCLOGIC_PARAMS_PEN_INRANGE_NONE startet den Timer neu: mod_timer(&drvdata->inrange_timer, jiffies + msecs_to_jiffies(100)); Ein Report, der zwischen dem timer_delete_sync()-Aufruf und dem Transport-Teardown in hid_hw_stop() ankommt, startet den inrange_timer neu, nachdem er abgebrochen wurde. uclogic_remove() kehrt dann zurück und die devm drvdata wird freigegeben, während hid_hw_stop() das Eingabegerät, auf das drvdata->pen_input zeigt, bereits freigegeben hat. Wenn der Timer also ~100 ms später feuert, dereferenziert uclogic_inrange_timeout() freigegebenen Speicher -- ein Use-after-free im Timer-Softirq-Kontext. Das Vertauschen der beiden Aufrufe ist keine Lösung: Das vorherige Stoppen des Geräts gibt drvdata->pen_input über hidinput_disconnect() frei, während der Timer noch ausstehen könnte. Ein vor dem Entfernen bereits aktivierter Timer feuert also auf dem freigegebenen Eingabegerät in dem Zeitfenster, bevor timer_delete_sync() ausgeführt wird. Verwenden Sie stattdessen timer_shutdown_sync() vor hid_hw_stop(). Es bricht den Timer ab, wartet auf einen laufenden Callback, während pen_input noch gültig ist, und verhindert ein erneutes Aktivieren -- ein späteres mod_timer() aus einem in-flight Report wird stillschweigend ignoriert --, sodass der Timer nachweislich tot ist, bevor hid_hw_stop() die Eingaben freigibt. Dies ist die Reihenfolge, die der Timer-Core für diesen Teardown-Fall „Timer von einem anderen Pfad aus neu aktiviert“ dokumentiert.

Fehlende Authentifizierung für kritische Funktionen, Server-Side Request Forgery (SSRF) und die Verwendung fest codierter Anmeldedaten in ASUS Control Center ermöglichen es einem nicht autorisierten Benutzer, den Verschlüsselungsschlüssel über eine HTTP-Anfrage zu erlangen, wodurch ein lokaler Dienst SSH auf Port 2222 aktiviert. Der Angreifer kann sich dann mit den fest codierten Anmeldedaten anmelden, um eine Root-Shell zu erlangen, die das direkte Lesen, Schreiben und Löschen von Daten in ASUS Control Center sowie die Fernsteuerung aller Server, PCs und Workstations innerhalb des Unternehmens ermöglicht. Weitere Informationen finden Sie im Abschnitt „Security Update for ASUS Control Center“ im ASUS Security Advisory.

Im Webmodul von TP-Link Archer AX55 v4 besteht eine Schwachstelle durch einen fest codierten kryptografischen Schlüssel. Ein LAN-Angreifer, der eine HTTP-Anmeldesitzung abfängt, kann den bekannten gemeinsam genutzten privaten RSA-Schlüssel verwenden, um das Administratorpasswort zu entschlüsseln; der geschwächte AES-Sitzungsschlüssel verringert zusätzlich den Aufwand, der zur Kompromittierung der Vertraulichkeit der Sitzung erforderlich ist. Eine erfolgreiche Ausnutzung kann das aus einer HTTP-Anmeldesitzung abgefangene Administratorpasswort offenlegen und die Vertraulichkeit der Sitzung kompromittieren.

Unsachgemäße Überprüfung der kryptografischen Signatur in Copilot Studio ermöglicht es einem nicht autorisierten Angreifer, Berechtigungen über ein Netzwerk zu erhöhen.

Fehlende Authentifizierung für kritische Funktion in Azure AI Language ermöglicht es einem nicht autorisierten Angreifer, über ein Netzwerk Berechtigungen zu erweitern.

Autorisierungsumgehung durch benutzergesteuerten Schlüssel in Azure Cosmos DB ermöglicht es einem autorisierten Angreifer, Spoofing über ein Netzwerk durchzuführen.