Einführung
Redis ist ein Open-Source-In-Memory-Datenspeicher, der häufig als Cache, Message Broker und leistungsstarke NoSQL-Datenbank eingesetzt wird. Er bietet vielfältige Datenstrukturen wie Strings, Hashes, Listen, Mengen, sortierte Mengen, Bitmaps, HyperLogLogs und Streams, unterstützt durch atomare Operationen und sehr geringe Latenz. Persistenz wird durch RDB-Snapshots und AOF gewährleistet, Hochverfügbarkeit durch Replikation, Sentinel und Cluster. Redis unterstützt zudem serverseitiges Scripting mit Lua zur atomaren Ausführung komplexer Operationen. Seine Geschwindigkeit, Flexibilität und sein ausgereiftes Ökosystem haben ihn zu einem zentralen Baustein moderner, latenzkritischer Systeme gemacht.
Im Oktober 2025 veröffentlichte Redis Version 8.2.2 , ein Sicherheitsupdate, das vier Schwachstellen in der eingebetteten Lua-Engine behebt. Die kritischste Schwachstelle ist ein Use-After-Free-Fehler in Lua, der es Angreifern ermöglicht, die Skript-Sandbox zu verlassen und Code auf dem Host auszuführen, wenn nicht vertrauenswürdige Benutzer beliebigen Lua-Code ausführen können. Das Update behebt außerdem einen Integer-Überlauf in der Unpack-Funktion, eine Schwachstelle bei der benutzerübergreifenden Skriptausführung sowie einen Lesefehler außerhalb des zulässigen Speicherbereichs im Lua-Lexer. In diesem Beitrag erläutern wir jede einzelne CVEs, gehen auf die Patches ein und beschreiben praktische Schritte zur Absicherung Ihrer Redis-Bereitstellungen.
Übersicht der Schwachstellen
Bevor wir uns mit dem Code befassen, hier eine kurze Übersicht darüber, welche Fehler in Version 8.2.2 der Lua-Engine behoben wurden.
CVE-2025-46817: Integer-Überlauf beim Entpacken (CVSS 9.8, Kritisch)
Extreme Argumente für `unpack(tbl, i, j)` können den internen Zähler für die zurückzugebenden Werte überschreiten. Dieser fehlerhafte Zähler kann Stack-Prüfungen umgehen und zu Abstürzen oder Speicherbeschädigung führen, wodurch er ein nützliches Angriffsziel darstellt.
CVE-2025-46818: Benutzerübergreifende Skriptausführung über gemeinsam genutzten Laufzeitstatus (CVSS 7.3, Hoch)
Unzureichende Kontrollen bezüglich Metatabellen und umgebungsbezogener APIs ermöglichten es einem Skript, die Ausführung anderer Skripte zu beeinflussen. In manchen Konfigurationen bedeutete dies, dass ein Benutzer mit geringeren Berechtigungen die Ausführung im Kontext eines anderen Benutzers beeinträchtigen und somit die Isolation schwächen konnte.
CVE-2025-46819: Lua-Einlesefehler außerhalb des zulässigen Bereichs beim Parsen langer Zeichenketten (CVSS 7.1, Hoch)
Die fehlerhafte Verarbeitung von Trennzeichen für lange Zeichenketten/lange Kommentare ([=[ … ]=] usw.) im Lua-Lexer kann dazu führen, dass dieser das Ende seines Puffers überschreitet. Dies kann zu einem Redis-Absturz führen und in seltenen Fällen benachbarten Speicher offenlegen.
CVE-2025-49844: Lua-Use-After-Free-Schwachstelle im Parser (CVSS 10.0, Kritisch)
Ein speziell präpariertes Lua-Skript kann die Speicherbereinigung und das Parsen so manipulieren, dass ein Use-After-Free-Fehler in der eingebetteten Lua-Engine auftritt.
Als Nächstes werden wir uns jeden dieser Punkte genauer ansehen, einschließlich der entsprechenden Patch-Ausschnitte.
Einblick in die Fehlerbehebungen: Detaillierte Analyse der Sicherheitslücken
CVE-2025-46817: Integer-Überlauf beim Entpacken
Dieses Problem betrifft die Funktion `unpack(tbl, i, j)` in Lua 5.1, die in Redis eingebettet ist. Bei extremen Werten für `i` und `j` kann die Berechnung der Anzahl der zurückzugebenden Ergebnisse einen Überlauf verursachen, ein falsches Ergebnis liefern und die Stack-Prüfung umgehen. Dies kann zu einem Absturz oder Speicherbeschädigung führen und in gefährlichen Umgebungen als Baustein für Remote Code Execution (RCE) genutzt werden.
Der Patch für diese CVE kann hier eingesehen werden: fc9abc7
Patch-Analyse
Die Korrektur macht die Bereichsbehandlung von unpack explizit und sicher.
- Die Zählberechnung wurde auf sichere, vorzeichenlose Mathematik umgestellt.
Vor dem Patch :
static int luaB_unpack (lua_State *L) {
int i, e, n;
luaL_checktype(L, 1, LUA_TTABLE);
i = luaL_optint(L, 2, 1);
e = luaL_opt(L, luaL_checkint, 3, luaL_getn(L, 1));
if (i > e) return 0; /* leerer Bereich */
n = e – i + 1; /* kann zu einem Überlauf führen (vorzeichenbehaftet) */
if (n <= 0 || !lua_checkstack(L, n))
return luaL_error(L, “zu viele Ergebnisse zum Entpacken”);
/* push n Ergebnisse… */
}
Hier wird e – i + 1 als vorzeichenbehaftete Ganzzahl berechnet. Bei Extremwerten (z. B. 0 und 2147483647) kann es zu einem Überlauf kommen, und n <= 0 ist keine zuverlässige Schutzfunktion.
Nach dem Patch :
static int luaB_unpack (lua_State *L) {
int i, e;
unsigned int n;
luaL_checktype(L, 1, LUA_TTABLE);
i = luaL_optint(L, 2, 1);
e = luaL_opt(L, luaL_checkint, 3, luaL_getn(L, 1));
if (i > e) return 0; /* leerer Bereich */
n = (unsigned int)e – (unsigned int)i; /* Elemente minus 1 */
if (n >= INT_MAX || !lua_checkstack(L, ++n))
return luaL_error(L, “zu viele Ergebnisse zum Entpacken”);
lua_rawgeti(L, 1, i); /* push arg[i] */
while (i++ < e) {
lua_rawgeti(L, 1, i);
}
gib n zurück;
}
Kernpunkte:
- Verwendet unsigned int für den Span, um negative/überlaufende Werte zu vermeiden.
- Behandelt n als „Anzahl – 1“ und erhöht es einmal vor der Stapelprüfung.
- Erzwingt eine harte Obergrenze (n >= INT_MAX → Fehler).
- Stellt sicher, dass der Stapel Platz für alle Ergebnisse bietet. bevor Irgendwas zu schieben.
- Explizite Array-Indizierung
Verwandte Verschärfungen im Tabellencode:
Nach dem Patch
if (1 <= key && key <= t->sizearray)
return &t->array[key-1];
Anstatt auf einen Trick mit der Typumwandlung von vorzeichenlosen Datentypen zurückzugreifen, wird eine Überprüfung der Grenzen durchgeführt, wodurch unerwartetes Verhalten bei sehr großen oder negativen Indizes vermieden wird.
Zusammengenommen bewirken diese Änderungen, dass extreme Entpackungsbereiche nicht mehr zu überschriebenen Zählern oder unsicheren Push-Operationen führen. Überdimensionierte Aufrufe schlagen nun mit einer eindeutigen Fehlermeldung „Zu viele Ergebnisse zum Entpacken“ fehl, anstatt einen Absturz oder Speicherbeschädigung zu riskieren.
CVE-2025-46819: Lua liest außerhalb des zulässigen Bereichs beim Parsen langer Zeichenketten
Das Problem liegt im Lua-Lexer, genauer gesagt in der Art und Weise, wie er lange Zeichenketten und lange Kommentare wie [=[ … ]= parst. In anfälligen Versionen können bestimmte fehlerhafte oder extreme Trennzeichenmuster dazu führen, dass der Lexer das Ende seines Eingabepuffers überschreitet. Dies kann zu einem Absturz von Redis (DoS) führen und in einigen Grenzfällen Bytes aus dem benachbarten Speicher offenlegen.
Der Patch für diese CVE-Schwachstelle kann hier eingesehen werden: 3a1624d
Patch-Analyse
Die Korrektur macht die Verarbeitung langer Saiten strenger und weniger fehleranfällig.
Die Trennzeichenanalyse wird eindeutig gestaltet.
Die Hilfsfunktion zum Parsen von Sequenzen wie [===[ und ]===] wurde aktualisiert, um einen sichereren Datentyp zu verwenden und klare, konsistente Werte zurückzugeben:
Nach dem Patch
static size_t skip_sep(LexState *ls) {
size_t count = 0;
int s = ls->current; /* '[' oder ']' */
lua_assert(s == '[' || s == ']');
save_and_next(ls); /* verarbeiten */
while (ls->current == '=') { /* count '=' */
save_and_next(ls);
count ++;
}
if (ls->current == s) /* zweites '[' oder ']' gefunden */
return count + 2; /* gültiges langes Trennzeichen */
sonst falls (Anzahl == 0)
return 1; /* keine lange Zeichenkette/kein Kommentar */
sonst
return 0; /* fehlerhaft */
}
- Gültige Trennzeichen für lange Zeichenketten geben nun eine wohldefinierte Länge (>= 2) zurück.
- Einfach [ fällt sauber zurück (1).
- Fehlerhafte [==… Muster geben 0 zurück und werden als Fehler behandelt.
Dadurch wird die Lücke geschlossen, durch die ungewöhnliche oder unvollständige Muster den Lexer verwirren und ihn dazu veranlassen könnten, über den Puffer hinaus zu lesen.
Die Offsets für das Zerteilen des Körpers werden korrigiert.
Beim Extrahieren des eigentlichen Stringinhalts gleicht der Patch die Slice-Berechnung mit dem Ergebnis von skip_sep ab:
Nach dem Patch:
if (seminfo) {
seminfo->ts = luaX_newstring(
Ich,
luaZ_buffer(ls->buff) + sep,
luaZ_bufflen(ls->buff) – 2 * sep
);
}
Bisher entsprachen die Offsets nicht korrekt der Semantik der Trennzeichen, was zu subtilen Off-by-N-Fehlern führen konnte. Jetzt werden Startwert und Länge direkt von `sep` abgeleitet, sodass der Lexer innerhalb der Grenzen bleibt.
Die Typen entsprechen dem, was der Code tatsächlich tut.
Die in dieser Logik verwendeten Zähler und Indizes nutzen nun geeignete vorzeichenlose/Größentypen anstelle von überladenen vorzeichenbehafteten Ganzzahlen, wodurch das Risiko negativer Werte oder eines Überlaufs bei der Zeigerarithmetik verringert wird.
Das bedeutet, dass Lua selbst riesige oder absichtlich fehlerhafte [=…=[ … ]=…=]-Sequenzen nun entweder korrekt analysiert oder mit einer normalen Fehlermeldung zurückweist. Es gibt keine Möglichkeit mehr, den Lexer durch ein bösartiges Skript dazu zu bringen, über das Ende des Puffers hinaus zu analysieren.
CVE-2025-46818: Lua-Skript kann im Kontext eines anderen Benutzers ausgeführt werden
Bei diesem Problem geht es darum, Lua-Skripte auf den jeweiligen Benutzer und die zugehörige Umgebung zu beschränken . In anfälligen Versionen waren gemeinsam genutzte Laufzeitelemente – wie Metatabellen für Kerntypen und ältere Umgebungs-APIs – so ungenau definiert, dass ein Skript die Ausführung anderer Skripte beeinflussen konnte. In manchen Umgebungen konnte dies die Isolation zwischen Benutzern aufheben.
Der Patch für diese CVE kann hier eingesehen werden: 45eac02
Patch-Analyse
Die Korrektur bewirkt im Wesentlichen zwei Dinge: Sie schützt die zentralen Metatabellen und verhindert den Zugriff auf riskante Legacy-APIs.
- Die Metatabellen der Kerntypen sind geschützt.
Bisher gab es für die in Skripten verfügbaren Lua-Datentypen (Zeichenketten, Zahlen, Boolesche Werte usw.) keine strikte Barriere, die Änderungen an den Metatabellen durch Benutzerskripte verhinderte. Das bedeutete, dass eine Änderung an einer gemeinsam genutzten Metatabelle anderen Code beeinträchtigen konnte, der in derselben Engine ausgeführt wurde.
Der gepatchte Code härtet diese Metatabellen explizit während der Einrichtung der Lua-Umgebung ab. Vereinfacht ausgedrückt:
Gepatchter Code: Primitive Metatabellen als geschützt markieren
static void luaProtectPrimitiveMetatables(lua_State *L) {
const inttypes[] = {LUA_TSTRING, LUA_TNUMBER, LUA_TBOOLEAN, LUA_TNIL};
for (size_t i = 0; i < sizeof(types)/sizeof(types[0]); i++) {
luaL_getmetatable(L, lua_typename(L, types[i]));
if (!lua_isnil(L, -1)) {
lua_pushliteral(L, “protected”);
lua_setfield(L, -2, “__metatable”); /* Metatabelle sperren */
}
lua_pop(L, 1);
}
}
Dieser __metatable-Schutz bedeutet, dass Benutzerskripte diese Typen zwar weiterhin sehen können , ihre Metatabellen aber nicht global ersetzen oder überschreiben können. Jeder entsprechende Versuch schlägt sauber fehl, anstatt das Verhalten für alle anderen stillschweigend zu ändern.
- Legacy-Umgebungs-APIs sind explizit optional.
Ältere Lua-APIs, die Umgebungen manipulieren können, sind jetzt standardmäßig deaktiviert und werden nur noch dann freigegeben, wenn ein Operator sie explizit aktiviert.
Konzeptionell sieht die Veränderung folgendermaßen aus:
Vor dem Patch: Veraltete APIs waren immer in der Skriptumgebung verfügbar.
static const luaL_Reg redis_compat_funcs[] = {
{“getfenv“, luaB_getfenv},
{“setfenv”, luaB_setfenv},
{“newproxy”, luaB_newproxy},
{NULL, NULL}
};
scriptCreateEnv(…) {
luaL_register(L, “_G”, redis_compat_funcs);
}
Nach dem Patch: Nur registrieren, wenn lua-enable-deprecated-api gesetzt ist.
scriptCreateEnv(…) {
if (server.lua_enable_deprecated_api) {
luaL_register(L, “_G”, redis_compat_funcs);
}
}
Wenn lua-enable-deprecated-api nicht aktiviert ist, sind diese Funktionen in der Skriptumgebung einfach nicht vorhanden, wodurch eine Reihe leistungsstarker Möglichkeiten zur kontextübergreifenden Manipulation wegfällt.
Zusammengenommen gewährleisten diese Änderungen Folgendes:
- Skripte können das grundlegende Verhalten aller anderen Skripte nicht stillschweigend ändern, indem sie die Kernmetatabellen überschreiben.
- Primitive zur Umweltmanipulation sind einzige verfügbar, wenn ein Bediener sie absichtlich aktiviert.
Das macht die Lua-Laufzeitumgebung berechenbarer und sorgt dafür, dass jedes Skript viel näher an seinen beabsichtigten Berechtigungen und Kontext herankommt – wichtig für jede gemeinsam genutzte oder mandantenfähige Redis-Bereitstellung.
CVE-2025-49844: Lua-Use-After-Free-Fehler im Parser
Dieser Fehler liegt in der Art und Weise, wie Redis den Lua-Parser integriert. Unter bestimmten Bedingungen kann ein speziell präpariertes Lua-Skript die Speicherbereinigung genau zum falschen Zeitpunkt auslösen und Redis dazu veranlassen, einen Zeiger auf bereits freigegebenen Speicher zu lesen.
Der Patch für diese CVE kann hier eingesehen werden: d5728cb5795
Patch-Analyse
Die wichtigste Änderung besteht darin, dass Redis während des Parsens eine korrekte Referenz auf die vom Parser verwendeten Lua-Objekte (wie den Chunk-Namen) auf dem Lua-Stack speichert, sodass der Garbage Collector sie als aktiv erkennt und sie nicht vorzeitig freigeben oder verschieben kann.
Bisher wurde der Chunk-Name direkt im Code erstellt und an den Lexer übergeben:
luaX_setinput(L, &lexstate, z, luaS_new(L, name));
Da dieser Wert nicht eindeutig verankert war (zum Beispiel auf dem Lua-Stack), konnte eine unglückliche Verschachtelung von GC oder Defragmentierung in Verbindung mit aggressivem Scripting theoretisch dazu führen, dass der Parser einen Zeiger auf etwas hielt, das verschoben oder freigegeben worden war.
Der gepatchte Code macht diese Besitzverhältnisse explizit:
TString *tname = luaS_new(L, name);
setsvalue2s(L, L->top, tname); /* Den Namen auf dem Stack behalten */
incr_top(L);
luaX_setinput(L, &lexstate, z, tname); /* Sicher zum Lexing/Parsing verwenden */
/* … den Chunk analysieren … */
–L->top; /* Referenz nach Gebrauch entfernen */
Da dieser Zustand während des gesamten Analysevorgangs referenziert wird, behandeln Garbage Collection und Defragmentierung ihn nun als aktiv und können ihn nicht währenddessen wiederherstellen oder verschieben. Dadurch wird das enge Zeitfenster, das die Verwendung nach dem Freigeben von Speicher ermöglichte, effektiv entfernt.
Gefährdete Einsatzszenarien
Diese Problematik ist insbesondere in Umgebungen relevant, in denen:
- Anwendungen nutzen Lua-Skripte in Redis.
- Derselbe Redis-Cluster wird von mehreren Teams oder Mandanten gemeinsam genutzt.
- Redis kann direkt oder über Ihre Anwendung erreicht werden – sowohl von nicht vertrauenswürdigen als auch von benutzergesteuerten Eingaben.
Empfohlenes Vorgehen
1. Zuerst patchen
- Aktualisieren Sie auf die gepatchte Redis-Version 8.2.2.
- Dies sollte überall dort als hohe Priorität behandelt werden, wo nicht vertrauenswürdiger oder nur teilweise vertrauenswürdiger Code Lua ausführen kann (zum Beispiel über EVAL / SCRIPT LOAD) oder wo Redis-Cluster von mehreren Teams/Mandanten gemeinsam genutzt werden.
2. Lua-Skripte absichern
- Verwenden Sie ACLs, um die Ausführung von Lua-Skripten auf vertrauenswürdige Dienste zu beschränken.
- Redis sollte in privaten Netzwerken betrieben werden, ohne direkten Internetkontakt.
- Lassen Sie lua-enable-deprecated-api deaktiviert, es sei denn, Sie haben einen klaren, nachweisbaren Grund dafür.
3. Segmentsensitive Workloads
- Führen Sie nicht vertrauenswürdige oder kundengesteuerte Lua-Skripte auf separaten Redis-Instanzen aus.
- Mischen Sie keine mandantengesteuerten Skripte mit Clustern, die kritische oder sensible Daten enthalten.
4. Nutzen Sie Sicherheitskontrollen, um die Transparenz zu erhöhen (nicht als Ersatz für das Patchen).
- Konfigurieren Sie IPS/IDS/WAF, um direkten Redis-Zugriff und verdächtige Redis-Protokollnutzung zu erkennen und zu blockieren.
- Nutzen Sie EDR/AV/Laufzeitschutz auf Redis-Hosts, um potenziell ausnutzbares Verhalten zu erkennen.
Referenzen: (Die Referenzliste bleibt in der wissenschaftlichen Zitierweise erhalten)
Autoren:
Vinay Kumar
Adrip Mukherjee
Nandini Seth
Suvarnjeet Jagtap
