Redis 8.2.2: 4가지 심각한 취약점에 대한 Lua 엔진 강화

개요

Redis는 캐시, 메시지 브로커, 고성능 NoSQL 데이터베이스로 널리 사용되는 오픈소스 인메모리 데이터 저장소입니다. 문자열, 해시, 리스트, 세트, ​​정렬된 세트, 비트맵, HyperLogLogs, 스트림과 같은 풍부한 데이터 구조를 제공하며, 원자적 연산과 매우 낮은 지연 시간을 지원합니다. RDB 스냅샷과 AOF를 통해 지속성을 제공하고, 복제, Sentinel, 클러스터를 통해 고가용성을 제공합니다. 또한 Redis는 Lua를 사용한 서버 측 스크립팅을 지원하여 복잡한 연산을 원자적으로 실행합니다. Redis의 빠른 속도, 유연성, 그리고 성숙한 생태계는 지연 시간에 민감한 최신 시스템의 핵심 구성 요소로 자리매김했습니다.

2025년 10월, Redis는 버전을 출시했습니다. 8.2.2내장 Lua 엔진의 네 가지 취약점을 수정하는 보안 릴리스입니다. 가장 심각한 취약점은 Lua 사용 후 해제(use-after-free)로, 신뢰할 수 없는 사용자가 임의의 Lua를 실행할 수 있을 때 공격자가 스크립팅 샌드박스를 벗어나 호스트에서 코드를 실행할 수 있도록 합니다. 이 릴리스는 또한 unpack의 정수 오버플로, 사용자 간 스크립트 실행 취약점, 그리고 Lua 렉서의 범위를 벗어난 읽기(out-of-bounds read) 취약점을 해결합니다. 이 게시물에서는 각 CVE를 분석합니다. 패치를 살펴보다Redis 배포를 강화하기 위한 실질적인 단계를 간략하게 설명합니다.

취약점 개요

코드로 들어가기 전에, Lua 엔진에서 8.2.2가 수정한 내용을 간략하게 살펴보겠습니다.

CVE-2025-46817: unpack에서 정수 오버플로 발생(CVSS 9.8, 심각)
unpack(tbl, i, j) 함수의 극단적인 인수는 반환할 값의 내부 개수를 오버플로우할 수 있습니다. 이렇게 잘못된 개수는 스택 검사를 우회하여 충돌이나 메모리 손상을 유발할 수 있으므로, 악용에 유용한 기본 요소로 작용합니다.

CVE-2025-46818: 공유 런타임 상태를 통한 교차 사용자 스크립트 실행(CVSS 7.3, 높음)
메타테이블과 환경 관련 API에 대한 느슨한 제어로 인해 한 스크립트가 다른 스크립트의 실행 방식에 영향을 미칠 수 있었습니다. 일부 설정에서는 권한이 낮은 사용자가 다른 사용자의 컨텍스트에서 실행에 영향을 미칠 수 있어 격리가 약화되었습니다.

CVE-2025-46819: 긴 문자열 구문 분석 시 Lua 범위를 벗어난 읽기(CVSS 7.1, 높음)
Lua 렉서에서 긴 문자열/긴 주석 구분 기호([=[ … ]=] 등)를 제대로 처리하지 못하면 버퍼의 한계를 초과하여 Redis가 다운될 수 있으며, 극단적인 경우에는 주변 메모리가 노출될 수 있습니다.

CVE-2025-49844: 파서의 Lua 사용 후 해제(CVSS 10.0, 중요)
정교하게 만들어진 Lua 스크립트는 가비지 수집과 구문 분석을 조작하여 내장된 Lua 엔진에서 사용 후 해제를 구현할 수 있습니다.

다음으로 관련 패치 스니펫을 사용하여 각각을 더 자세히 살펴보겠습니다.

수정 사항 내부: 취약점 심층 분석

CVE-2025-46817: 압축 해제 시 정수 오버플로 발생

이 문제는 Redis에 내장된 Lua 5.1의 unpack(tbl, i, j) 함수에 영향을 미칩니다. i/j 값이 너무 크면 "반환할 결과 개수" 계산 시 오버플로가 발생하여 잘못된 개수가 생성되고 스택 검사를 통과하지 못할 수 있습니다. 이는 충돌이나 메모리 손상을 초래할 수 있으며, 적대적인 상황에서 RCE(Real-Enhanced Compilation)를 위한 기본 요소로 사용될 수 있습니다.

이 CVE에 대한 패치는 여기에서 참조할 수 있습니다. fc9abc7

패치 분석

이 수정을 통해 unpack의 범위 처리가 명확하고 안전해졌습니다.

1. 카운트 계산이 안전한 부호 없는 수학으로 전환되었습니다.

패치 전:

정적 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; /* 빈 범위 */

n = e – i + 1; /* 오버플로우 가능(부호 있음) */

만약 (n <= 0 || !lua_checkstack(L, n))

luaL_error(L, "압축을 해제할 결과가 너무 많습니다");를 반환합니다.

/* n개의 결과를 푸시합니다… */

}

여기서 e – i + 1은 부호 있는 int로 처리됩니다. 극단적인 값(예: 0과 2147483647)이 발생하면 오버플로가 발생할 수 있으며, n <= 0은 신뢰할 수 있는 가드가 아닙니다.

패치 후:

정적 int luaB_unpack(lua_State *L) {

int i, e;

부호 없는 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; /* 빈 범위 */

n = (unsigned int)e – (unsigned int)i; /* 요소에서 1을 뺀 값 */

만약 (n >= INT_MAX || !lua_checkstack(L, ++n))

luaL_error(L, "압축을 해제할 결과가 너무 많습니다");를 반환합니다.

lua_rawgeti(L, 1, i); /* 인수[i]를 푸시합니다. */

while (i++ < e) {

lua_rawgeti(L, 1, i);

}

n을 반환합니다.

}

키 포인트:

• 음수/오버플로우 값을 방지하기 위해 범위에 unsigned int를 사용합니다.
• n을 "count - 1"로 취급하고 스택 검사 전에 한 번 증가합니다.
• 시행합니다 하드 상한 (n >= INT_MAX → 오류).
• 모든 결과를 위한 공간이 스택에 있는지 확인합니다. 전에 무엇이든 밀어붙이는 것.

1. 배열 인덱싱이 명시적으로 지정됨

테이블 코드의 관련 강화:

패치 후

if (1 <= 키 && 키 <= t->sizearray)

&t->array[key-1]을 반환합니다.

부호 없는 캐스트 트릭에 의존하는 대신 명확한 경계 검사를 사용하여 거대하거나 음수 인덱스에 대한 이상한 동작을 방지합니다.

이러한 변경 사항들을 종합해 보면, 극단적인 unpack 범위가 더 이상 래핑된 카운트나 안전하지 않은 푸시를 유발하지 않습니다. 이제 너무 큰 호출은 충돌이나 메모리 손상의 위험 대신 "결과가 너무 많아 unpack할 수 없습니다"라는 명확한 오류와 함께 실패합니다.

CVE-2025-46819: 긴 문자열 구문 분석 시 Lua 범위를 벗어난 읽기 오류 발생

이 문제는 Lua의 렉서, 특히 [=[ … ]=]와 같은 긴 문자열과 긴 주석을 구문 분석하는 방식에 존재합니다. 취약한 버전에서는 특정 잘못 구성되거나 극단적인 구분 기호 패턴으로 인해 렉서가 입력 버퍼의 끝을 초과할 수 있습니다. 이로 인해 Redis가 다운될 수 있으며(DoS), 경우에 따라 주변 메모리의 바이트가 노출될 수 있습니다.

이 CVE에 대한 패치는 여기에서 참조할 수 있습니다. 3a1624d

패치 분석

이 수정으로 긴 문자열 처리가 더 엄격해지고 덜 취약해졌습니다.

구분 기호 구문 분석이 명확해졌습니다.

[===[ 및 ]===]와 같은 시퀀스를 구문 분석하는 도우미는 더 안전한 유형을 사용하고 명확하고 일관된 값을 반환하도록 업데이트되었습니다.

패치 후

정적 크기_t skip_sep(LexState *ls) {

크기_t 개수 = 0;

int s = ls->current; /* '[' 또는 ']' */

lua_assert(s == '[' || s == ']');

save_and_next(ls); /* 소비 */

while (ls->current == '=') { /* count '=' */

저장하고 다음에(ls);

카운트++;

}

if (ls->current == s) /* 두 번째 '[' 또는 ']'와 일치 */

return count + 2; /* 유효한 긴 구분 기호 */

그렇지 않으면 (count == 0)

return 1; /* 긴 문자열/주석이 아닙니다 */

그렇지 않으면

return 0; /* 잘못된 형식 */

}

• 유효한 긴 문자열 구분 기호는 이제 명확하게 정의된 길이(>= 2)를 반환합니다.
• Plain [ 깨끗하게 뒤로 떨어집니다(1).
• 잘못된 [==… 패턴은 0을 반환하고 오류로 처리됩니다.

이를 통해 이상하거나 불완전한 패턴으로 인해 어휘 분석기가 버퍼를 넘어 읽게 되는 격차가 해소됩니다.

본체를 슬라이싱하기 위한 오프셋이 수정되었습니다.

실제 문자열 내용을 추출할 때 패치는 슬라이스 수식을 skip_sep 결과에 맞춥니다.

패치 후:

if (반정보) {

세미정보->ts = luaX_newstring(

이,

luaZ_buffer(ls->buff) + sep,

luaZ_bufflen(ls->buff) – 2 * sep

);

}

이전에는 오프셋이 구분 기호 의미 체계와 제대로 일치하지 않아 미묘한 N 차이(off-by-N)가 발생할 수 있었습니다. 이제 시작과 길이가 sep에서 직접 파생되므로 렉서가 경계 내에 머무릅니다.

유형은 코드가 실제로 수행하는 작업과 일치합니다.

이 논리에 관련된 카운터와 인덱스는 이제 오버로드된 부호 있는 int 대신 적절한 부호 없는/크기 유형을 사용하여 포인터 산술에 음수 값이나 래퍼라운드가 침투하는 위험을 줄였습니다.

이 모든 것은 [=…=[ … ]=…=] 시퀀스가 ​​크거나 의도적으로 깨진 경우에도 Lua가 이를 올바르게 구문 분석하거나 일반적인 오류와 함께 거부한다는 것을 의미합니다. 이제 악의적인 스크립트가 렉서를 버퍼의 끝을 넘어 살펴보도록 유도할 수 있는 경로가 더 이상 없습니다.

CVE-2025-46818: Lua 스크립트가 다른 사용자 컨텍스트에서 실행될 수 있습니다.

이 문제는 다음과 같습니다. Lua 스크립트의 범위를 해당 사용자와 환경에 맞게 유지합니다.취약한 버전에서는 코어 유형 및 레거시 환경 API의 메타테이블과 같은 공유 런타임 요소가 너무 느슨해서 한 스크립트가 다른 스크립트의 실행 방식에 영향을 미칠 수 있었습니다. 일부 배포 환경에서는 이로 인해 사용자 간 격리가 모호해질 수 있었습니다.

이 CVE에 대한 패치는 여기에서 참조할 수 있습니다. 45ea02

패치 분석

이 수정은 두 가지 주요 작업을 수행합니다. 핵심 메타테이블을 보호합니다 및 게이츠 위험한 레거시 API.

1. 코어 유형 메타테이블은 보호됩니다.

이전에는 스크립트에 노출된 핵심 Lua 유형(문자열, 숫자, 불리언 등)에 사용자 스크립트에서 메타테이블을 변경하는 것을 막는 엄격한 장벽이 없었습니다. 즉, 공유 메타테이블을 수정하면 동일한 엔진에서 실행되는 다른 코드에 영향을 미칠 수 있었습니다.

패치된 코드는 Lua 환경 설정 과정에서 해당 메타테이블을 명시적으로 강화합니다. 간략하게 표현하면 다음과 같습니다.

패치된 코드: 기본 메타테이블을 보호됨으로 표시

정적 void luaProtectPrimitiveMetatables(lua_State *L) {

const int 유형[] = {LUA_TSTRING, LUA_TNUMBER, LUA_TBOOLEAN, LUA_TNIL};

(size_t i = 0; i < sizeof(types)/sizeof(types[0]); i++) {

luaL_getmetatable(L, lua_typename(L, 유형[i]));

만약 (!lua_isnil(L, -1)) {

lua_pushliteral(L, "보호됨");

lua_setfield(L, -2, "__metatable"); /* 메타테이블 잠금 */

}

lua_pop(L, 1);

}

}

이 __metatable 보호는 사용자 스크립트가 여전히 다음을 수행할 수 있음을 의미합니다. 참조 이러한 유형은 메타테이블을 전역적으로 바꾸거나 다시 작성할 수 없습니다. 다른 모든 사용자의 동작을 조용히 변경하는 대신, 이를 시도하는 것은 깔끔하게 실패합니다.

2. 레거시 환경 API는 명시적으로 선택 가능합니다.

환경을 조작할 수 있는 이전 Lua API는 이제 다음과 같습니다. 기본적으로 비활성화 운영자가 명시적으로 활성화한 경우에만 노출됩니다.

개념적으로 변경 사항은 다음과 같습니다.

패치 전: 더 이상 사용되지 않는 API는 스크립트 환경에서 항상 사용 가능

정적 const luaL_Reg redis_compat_funcs[] = {

{“getfenv”, luaB_getfenv},

{“setfenv”, luaB_setfenv},

{“newproxy”, luaB_newproxy},

{NULL, NULL}

};

스크립트 생성 환경(…) {

luaL_register(L, "_G", redis_compat_funcs);

}

패치 후: lua-enable-deprecated-api가 설정된 경우에만 등록

스크립트 생성 환경(…) {

if (server.lua_enable_deprecated_api) {

luaL_register(L, "_G", redis_compat_funcs);

}

}

lua-enable-deprecated-api가 활성화되어 있지 않으면 이러한 함수는 스크립트 환경에 존재하지 않아 컨텍스트 간 조작을 위한 강력한 수단이 사라집니다.

이러한 변화를 종합하면 다음과 같은 이점이 있습니다.

• 스크립트는 핵심 메타테이블을 다시 작성하여 다른 모든 스크립트의 기본 동작을 자동으로 패치할 수 없습니다.
• 환경 조작 기본 요소는 다음과 같습니다. 만 운영자가 의도적으로 켜는 경우에만 사용 가능합니다.

이를 통해 Lua 런타임이 더 예측 가능해지고 각 스크립트가 의도한 권한과 컨텍스트에 훨씬 더 가깝게 유지됩니다. 이는 공유 또는 다중 테넌트 Redis 배포에 중요합니다.

CVE-2025-49844: 파서의 Lua 사용 후 해제

이 버그는 Redis가 Lua 파서를 통합하는 방식에 존재합니다. 특정 조건에서, 정교하게 조작된 Lua 스크립트가 잘못된 시점에 가비지 컬렉션을 트리거하여 Redis가 이미 해제된 메모리 포인터를 읽도록 만들 수 있습니다.

이 CVE에 대한 패치는 여기에서 참조할 수 있습니다. d5728cb5795

패치 분석
주요 변경 사항은 이제 Redis가 파싱하는 동안 파서가 사용하는 Lua 객체(청크 이름 등)에 대한 적절한 참조를 Lua 스택에 유지하므로 가비지 수집기가 이를 활성 상태로 간주하고 조기에 해제하거나 이동할 수 없다는 것입니다.

이전에는 청크 "name"이 인라인으로 생성되어 렉서에 직접 전달되었습니다.

luaX_setinput(L, &lexstate, z, luaS_new(L, 이름));

해당 값이 명확하게 고정되지 않았기 때문에(예를 들어 Lua 스택에) GC나 defrag와 공격적인 스크립팅이 불운하게 섞이면 이론적으로 파서가 이동되거나 해제된 항목에 대한 포인터를 보유하게 될 수 있습니다.

패치된 코드는 해당 소유권을 명시적으로 나타냅니다.

TString *tname = luaS_new(L, 이름);

setsvalue2s(L, L->top, tname); /* 스택에 이름을 유지합니다 */

증가_상단(L);

luaX_setinput(L, &lexstate, z, tname); /* 안전하게 렉싱/파싱에 사용 */

/* … 청크를 구문 분석합니다 … */

–L->top; /* 완료되면 참조를 삭제합니다. */

이 상태를 전체 파싱 과정에서 참조함으로써, GC와 defrag는 이제 해당 상태를 활성 상태로 간주하여 처리 중에 회수하거나 재배치할 수 없습니다. 이를 통해 사용 후 해제를 가능하게 했던 좁은 타이밍 창이 사실상 사라집니다.

위험에 처한 배포 시나리오

이러한 문제는 다음과 같은 환경에서 특히 중요합니다.

• Redis에서는 애플리케이션이 Lua 스크립팅을 사용합니다.
• 동일한 Redis 클러스터는 여러 팀이나 테넌트에서 공유됩니다.
• 신뢰할 수 없는 입력이나 사용자가 제어하는 ​​입력을 통해 직접 또는 애플리케이션을 통해 Redis에 접근할 수 있습니다.

권장 조치

1. 먼저 패치하세요

• 패치된 Redis 8.2.2 빌드로 업그레이드하세요.
• 신뢰할 수 없거나 반신뢰할 수 있는 코드가 Lua를 실행할 수 있는 곳(예: EVAL/SCRIPT LOAD를 통해)이나 Redis 클러스터가 여러 팀/테넌트에서 공유되는 곳에서는 이를 높은 우선순위로 처리합니다.

2. Lua 스크립팅 잠금

• ACL을 사용하여 Lua 스크립팅을 신뢰할 수 있는 서비스에만 제한합니다.
• Redis를 개인 네트워크에 유지하고 인터넷에 직접 노출되지 않도록 하세요.
• 명확하고 감사된 필요성이 없는 한 lua-enable-deprecated-api를 비활성화해 두세요.

3. 민감한 워크로드를 세분화합니다.

• 신뢰할 수 없거나 고객 중심의 Lua를 별도의 Redis 인스턴스에서 실행합니다.
• 중요하거나 민감한 데이터가 보관된 클러스터와 테넌트 제어 스크립트를 섞어 사용하지 마세요.

4. 보안 제어를 사용하여 가시성을 추가합니다(패치 대체가 아님)

• IPS/IDS/WAF를 구성하여 직접적인 Redis 액세스와 의심스러운 Redis 프로토콜 사용을 감지하고 차단합니다.
• Redis 호스트에서 EDR/AV/런타임 보호 기능을 사용하여 악용과 유사한 동작을 발견합니다.

참조 :

• https://github.com/redis/redis/commits/8.2.2/
• https://nvd.nist.gov/vuln/detail/CVE-2025-46817
• https://nvd.nist.gov/vuln/detail/CVE-2025-46818
• https://nvd.nist.gov/vuln/detail/CVE-2025-46819
• https://nvd.nist.gov/vuln/detail/CVE-2025-49844

저자 :

비나이 쿠마르

아드립 무케르지

난디니 세스

수완지트 자그탑