C&C 제너럴스 RCE·웜 취약점 분석: P2P의 함정
한때 LAN 파티에서 밤새 즐기던 게임도, 네트워크 코드를 들여다보면 “그 시절 보안 감수성”이 그대로 남아 있는 경우가 많아요. 이번에 공개된 Command & Conquer: Generals(제로아워 포함) 소스코드를 기반으로, 실제로 원격 코드 실행(RCE, Remote Code Execution) 과 웜(worm) 전파까지 가능한 취약점 사례가 정리돼 눈길을 끕니다.
C&C: Generals 네트워크 구조가 만든 큰 공격면(Attack Surface)
이 게임의 멀티플레이는 기본적으로 P2P(peer-to-peer) 구조라서, 방(host)뿐 아니라 참여자 각자가 네트워크로 “열려” 있어야 해요. 로비용으로 UDP 8086, 실제 게임 동기화 트래픽은 UDP 8088을 쓰는데, 즉 멀티를 하려면 두 포트가 외부와 통신 가능해야 합니다. 공격자 입장에선 “서버 한 곳”이 아니라 플레이어 모두가 잠재적 타깃이 되는 셈이죠.
패킷은 CRC32, 매직 헤더, 타입 태그(TLV 유사 구조) 등을 갖추고 XOR 기반 인코딩도 있지만, 핵심은 클라이언트 인증이 없고 하드코딩 XOR 키로 처리된다는 점이에요. 게다가 큰 payload를 가능하게 하는 패킷 조각화(fragmentation) 메커니즘까지 있어서, 취약점이 하나만 맞물려도 임팩트가 커집니다. 이런 구조는 “게임이 오래됐다” 정도가 아니라, 보안 관점에선 설계상 위험이 누적된 상태라고 보는 게 맞아요.
핵심 취약점 1: 파일명 처리의 스택 오버플로우(Stack Overflow)
가장 먼저 소개된 건 NetPacket::readFileMessage / readFileAnnounceMessage에서의 메모리 손상 취약점이에요. 코드가 _MAX_PATH 크기의 filename 버퍼에 대해, NULL(0) 문자가 나올 때까지 신뢰할 수 없는 데이터를 계속 복사합니다. 길이 검증이 없으니, 공격자가 긴 문자열을 보내면 스택 버퍼 오버플로우가 발생해 흐름 제어(EIP)를 가져갈 수 있었죠.
더 무서운 건 당시 환경 특성입니다. 게임이 32비트로 동작하고, 일부 라이브러리가 ASLR(Address Space Layout Randomization) 이 적용되지 않아 ROP(Return-Oriented Programming) 구성 난이도가 내려갔다고 해요. 패킷 길이 제한이 있어도 조각화로 우회가 가능하니, 결과적으로 원격에서 안정적인 코드 실행이 가능한 조건이 만들어진 겁니다. “옛날 게임”이 LAN/온라인에서 돌 때 어떤 위험이 생기는지 아주 명확한 사례죠.
핵심 취약점 2: 임의 파일 드롭(Arbitrary File Drop)로 지속성(Persistence)까지
같은 readFileMessage 계열 처리 흐름에서, 수신된 파일을 저장할 때 확장자 제한이나 경로 제한(디렉터리 트래버설 방지) 이 거의 없었습니다. 즉 공격자는 게임 폴더 밖 경로를 지정하거나, 임의 확장자 파일을 떨어뜨릴 수 있었어요.
여기서 포인트는 “파일 쓰기” 자체가 끝이 아니라는 점입니다. 연구진은 게임이 시작될 때 로컬 경로의 dbghelp.dll을 로딩하려는 동작을 이용해, 해당 위치에 악성 DLL을 심어 다음 게임 실행 시 자동 로드되게 만들었습니다. 정리하면 원격 파일 드롭 → DLL 하이재킹(DLL Hijacking) → 지속적인 코드 실행으로 이어지는 시나리오예요. 실사용 관점에선, 한 번 당하면 게임을 껐다 켜도 계속 영향을 받을 수 있다는 의미라서 심각도가 훨씬 올라갑니다.
핵심 취약점 3: 조각화 로직의 OOB Write(Out-of-Bounds Write)
패킷 조각을 합치는 로직(NetCommandWrapperListNode::copyChunkData)에서는 offset과 length가 사실상 공격자 컨트롤인데도, m_data 버퍼 경계를 검증하지 않고 memcpy를 수행합니다. 즉, 원하는 위치에 원하는 길이만큼 데이터를 써버리는 OOB Write가 가능한 형태죠.
이 취약점은 단독으로도 위험하지만, 앞서 말한 “큰 payload를 조각화로 보낼 수 있는 구조”와 결합되면 공격 옵션이 넓어집니다. 예를 들어 안정적인 익스플로잇을 만들거나, 크래시 유발 DoS를 넘어 메모리 손상 기반 RCE로 이어질 가능성도 커져요. 게임 네트워크에서 흔히 “성능/지연” 위주로 만들다 보니 이런 검증이 빠진 사례가 많다는 점도 시사합니다.
웜(worm) 데모: P2P 게임에서 전파가 쉬운 이유
연구진은 취약점을 “RCE 가능”에서 끝내지 않고, 실제 임팩트를 보여주기 위해 웜 형태의 페이로드를 만들었습니다. 흐름은 간단해요. 먼저 파일 드롭 취약점으로 DLL을 심고, 메모리 손상 취약점으로 LoadLibrary 형태로 즉시 로드해 현재 세션에서도 동작하게 만듭니다. 그리고 WSOCK32.dll의 recvfrom에 IAT Hook(Import Address Table 후킹) 을 걸어 들어오는 패킷을 가로채 “매직 패킷/매직 채팅”을 처리합니다.
전파(spread) 단계도 RTS 멀티 환경에 특화돼 있어요. 플레이어가 입장할 때 교환되는 메시지에서 유저/IP 정보를 얻고, 감염 대상에게 다시 페이로드를 보내는 구조죠. 특히 P2P 특성상 한 게임 내에서 여러 플레이어가 서로 통신하니, 한 명이 감염되면 같은 방 전체로 확산될 여지가 큽니다. 현실에서도 “사설 서버/커뮤니티 매치” 같은 환경이 많다면, 이런 전파형 공격이 더 설득력 있게 다가올 수밖에 없어요.
커뮤니티 패치와 대응: ‘EoL 게임’의 보안은 누가 맡나
EA는 이 타이틀을 레거시(EoL, End-of-Life)로 보고 공식 지원 범위 밖이라 확인했고, CVE 발급도 “레거시 타이틀엔 하지 않는다”는 입장이었습니다. 대신 연구진은 MITRE로 에스컬레이션해 CVE를 추진 중이고, 동시에 커뮤니티 포크인 GeneralsGameCode 쪽에 2025년 12월부터 디스클로저와 패치 조율을 진행했습니다.
실제로 커뮤니티 쪽에선 다음과 같은 수정이 공유됐어요.
readFileMessage메모리 손상 패치: 스택 오버플로우/파싱 취약점 완화에 직접적이라 가장 우선순위가 높아요.- 조각화(fragmentation) 메모리 손상 패치: 대형 payload 경로를 막아 익스플로잇 난이도를 크게 올려요.
- 파일 확장자 검증 패치: DLL 드롭/자동 로드 같은 “지속성” 시나리오를 차단하는 데 핵심이에요.
마무리: “옛날 게임”을 지금도 한다면 이렇게 점검해보세요
이번 사례는 단순히 특정 게임이 취약했다기보다, P2P 네트워크 + 무인증 + 구식 검증 로직 조합이 얼마나 치명적인지 보여줍니다. 특히 커뮤니티 서버나 유저 호스팅 환경에선 “내 PC가 서버”가 되는 순간이 많아서, 공격면이 생각보다 넓어요.
지금도 C&C: Generals 같은 레거시 게임을 즐긴다면, 최소한 커뮤니티 패치 적용 여부와 필요 포트(8086/8088) 노출 범위부터 점검해보는 걸 추천해요. 그리고 이런 글을 한 번쯤 읽고 나면, “EoL 소프트웨어는 누가 안전을 책임지는가?”라는 질문도 자연스럽게 남습니다. 여러분은 레거시 타이틀의 보안을 벤더, 커뮤니티, 사용자 중 누가 어디까지 책임져야 한다고 보시나요?
