[KRCERT]Redis 제품 보안 업데이트 권고

내용 요약

Redis가 최근 공개한 Use After Free (UAF) 취약점(CVE‑2025‑49844)은 여러 버전에서 발생하며, 해당 버전을 사용하는 모든 환경에 심각한 보안 위험을 초래합니다.
따라서 6.2.20 이하, 7.0 이하, 7.2.11 이하, 7.4.6 이하, 8.0.4 이하, 8.2.2 이하 버전을 사용 중이라면 즉시 최신 버전으로 업그레이드할 것을 권고합니다.

---

핵심 포인트

• 취약점 종류: Use After Free (UAF) – 메모리 관리 오류로 인해 원치 않는 데이터 접근이 가능.
• 영향 범위: Redis 6.x, 7.x, 8.x 시리즈 중 특정 버전 이하 모두.
• 급속 대응: 최신 버전(6.2.20+, 7.0+, 7.2.11+, 7.4.6+, 8.0.4+, 8.2.2+) 으로 즉시 업그레이드.

---

기술 세부 내용

1️⃣ Use After Free (UAF) Vulnerability (CVE‑2025‑49844)

항목	상세 내용
정의	UAF는 객체가 해제된 후에도 여전히 접근이 가능한 상황에서 발생합니다. 악의적 사용자는 해제된 메모리 영역을 재사용해 임의의 코드 실행, 데이터 변조 등 다양한 공격을 수행할 수 있습니다.
Redis에서의 발생 메커니즘	Redis는 redis.c에서 freeObject()를 호출해 메모리를 반환한 뒤, 동일한 포인터가 재사용되는 경우가 있습니다. 이때 클라이언트가 전송한 명령이 해제된 객체를 참조하면, 이전에 할당되었던 데이터가 그대로 남아 있을 수 있어 원치 않는 접근이 가능해집니다.
공격 시나리오	1. 서비스 거부 (DoS) – UAF를 악용해 무한 루프나 메모리 손상으로 서버 다운. 2. 데이터 변조 – 해제된 객체를 재활용해 중요한 키/값을 조작. 3. 원격 코드 실행 – 내부 포인터 조작으로 악의적 코드를 삽입 및 실행.
취약점 영향	Redis 클러스터, Sentinel, Redis‑Gears 등 모든 인스턴스에 적용. 운영 중인 모든 클라이언트가 위험에 노출됩니다.
감지 방법	redis-cli를 통한 MONITOR 명령으로 비정상적인 메모리 접근을 모니터링하거나, redis-stack에 포함된 RedisInsight를 활용해 런타임 메모리 사용 패턴을 시각화.
방어 원리	최신 버전에서는 memwatch와 같은 런타임 메모리 보호 기능을 강화하고, freeObject() 호출 시 메모리 블랭크를 추가해 해제된 메모리 영역을 즉시 무효화. 또한 valgrind를 통한 정적 분석과 함께 ASAN(AddressSanitizer)를 활성화해 개발 단계에서 사전 검출.

Tip:
- 고정된 버전을 사용 중인 경우, docker pull redis:<target-version> 으로 바로 이미지 업데이트.
- Helm 기반 클러스터라면 helm upgrade --set image.tag=<latest> 로 빠르게 롤아웃.

---

2️⃣ 업데이트 및 업그레이드 절차

단계	상세 설명	도구 / 명령
1️⃣ 백업	데이터 무결성을 위해 RDB/AOF 파일을 백업.	cp /var/lib/redis/dump.rdb /backup/
2️⃣ 서비스 중단	클러스터 전반에서 PAUSE 명령을 사용해 쓰기 중단 후, 인스턴스를 순차적으로 재시작.	redis-cli -h <host> -p <port> PAUSE 5000
3️⃣ 버전 확인	현재 설치된 버전과 호환되는 최신 버전 조회.	redis-server --version → GitHub Releases(https://github.com/redis/redis/releases)
4️⃣ 업그레이드	운영 중인 환경에 따라 패키지 매니저 또는 Docker를 사용.	* 패키지: apt-get upgrade redis / yum update redis * Docker: docker pull redis:<new-version> * Helm: helm upgrade redis-stack <repo>/redis-stack --version <new-version>
5️⃣ 재가동	새로운 이미지/버전으로 인스턴스를 재가동 후 정상 동작 여부 확인.	systemctl restart redis / docker run -d
6️⃣ 검증	redis-cli로 연결해 INFO 명령을 통해 버전과 메모리 상태를 확인.	redis-cli -h <host> -p <port> INFO
7️⃣ 모니터링	업그레이드 직후, MONITOR와 RedisInsight로 성능/보안 이벤트를 실시간 모니터링.	redis-cli MONITOR

주의:
- 버전 간 호환성: Redis 7.x→8.x 전환 시, CONFIG SET에 maxmemory-policy 및 appendonly 옵션을 재검토.
- 스냅샷 손상 방지: SAVE 혹은 BGSAVE를 통한 스냅샷 전에 SLOWLOG RESET을 호출해 오래된 로그를 정리.
- 보안 그룹: 업그레이드 후에는 방화벽 규칙을 재검토해 내부 트래픽만 허용하도록 구성.

---

3️⃣ 영향 및 대응 시나리오

상황	영향	대응 조치
사내 인프라	내부 Redis 인스턴스가 DoS 또는 데이터 변조에 노출.	즉시 업그레이드 + redis-annotate 를 통해 비정상 트래픽 로그 기록.
공공 클라우드	클러스터가 외부 공격에 노출, IP 허용 리스트를 통해 접속을 제한해도 UAF는 내부에서 발생.	Kubernetes 의 NetworkPolicy와 Redis Operator의 podSecurityPolicy를 적용해 실행 권한 최소화.
마이크로서비스	여러 서비스가 Redis를 공유, 한 서비스의 취약점이 전체 서비스에 영향을 미침.	Service Mesh(Istio, Linkerd)를 통해 트래픽을 분리하고, Redis Sentinel를 활용해 자동 장애 조치.
멀티테넌시	각 테넌트가 독립적인 Redis 인스턴스를 사용, 취약점이 전체 테넌트에 확산.	Redis Enterprise에서 제공하는 Tenant Isolation를 적용하거나, 각 테넌트마다 별도 Docker 컨테이너로 격리.

FAQ
Q1. 업그레이드 후 기존 데이터가 손상되나요?
A1. 보통은 dump.rdb 혹은 appendonly.aof 파일이 그대로 유지되므로 데이터 손상 위험이 낮습니다. 그러나 스냅샷 형식이 바뀌는 경우, redis-check-aof 및 redis-check-rdb로 파일을 검증하는 것이 안전합니다.
Q2. UAF를 즉시 차단할 수 있는 패치가 있나요?
A2. 현재 가장 신뢰할 수 있는 방법은 최신 버전으로 업그레이드하는 것이며, 그 사이에 maxmemory를 최소화하고 protected-mode yes를 활성화해 외부 접속을 제한할 수 있습니다.

---

최종 체크리스트
- [ ] 최신 버전 번호(6.2.20+, 7.0+, 7.2.11+, 7.4.6+, 8.0.4+, 8.2.2+) 확인
- [ ] 백업 완료 및 검증
- [ ] 보안 그룹 및 방화벽 재설정
- [ ] 모니터링 도구(REDISInsight, Prometheus) 업데이트
- [ ] 테스트 환경에서 사전 업그레이드 테스트

문의처
- 한국인터넷진흥원 사이버민원센터: 118 (국번없이)
- Redis GitHub Releases: https://github.com/redis/redis/releases
- CVE 상세: https://nvd.nist.gov/vuln/detail/CVE-2025-49844

끝

 

출처: https://knvd.krcert.or.kr/detailSecNo.do?IDX=6599