해설 — 가변길이 문자열/바이트 필드 역직렬화와 길이 검증 (C++)

난이도: 상

답변 프레임워크: 요약 → 문제 분류 → 원인 → 수정안 → 더 나은 설계

요약

Reader 가 공격자 제어 길이/개수를 검증 없이 신뢰한다. (A) readU16/readU32 와 문자열 본문 복사에 남은 바이트 경계 검사가 전혀 없어 버퍼 끝을 넘어 읽는다 (data_[pos_++] OOB read → 인접 힙/다른 플레이어 패킷 정보 유출, 또는 크래시). (B) reserve(len)·vector buf(len)·reserve(count) 가 신뢰되지 않은 값으로 거대한 메모리를 즉시 선할당(u32 블롭은 최대 ~4GB, count×len 중첩 증폭) → 6바이트 패킷으로 OOM/DoS. (C) pos_ 가 size_ 와 무관하게 증가해 이후 remaining = size_ - pos_ 같은 size_t 산술이 언더플로 되면 거대한 양수가 되어 무한루프/추가 OOB 로 번진다. 정답 한 줄: 모든 읽기 전에 need <= remaining 을 검사하고, 길이/개수에 프로토콜 상한을 두며, 신뢰되지 않은 값으로 선할당하지 말고(또는 clamp), UTF-8 을 검증한다.

변별: 본 문제는 "정상 프레이밍된 메시지 내부의 가변길이 필드" 파싱이다. problem1(길이프리픽스 스트림 프레이밍/부분수신), problem4(범용 패킷 검증), problem13(VarInt 정수 디코딩)과 달리, 여기서는 문자열/블롭 본문의 길이·개수·UTF-8 와 size_t 커서 산술이 핵심이다.

---

문제점

(A) 경계 검사 없는 읽기 — 버퍼 오버리드 / 정보 유출 (보안/버그) ★간판

• 증상: readU16 은 data_[pos_+1] 까지, readString 은 data_[pos_++] 를 len 번, 남은 바이트 확인 없이 읽는다. len 이 실제 남은 바이트보다 크면 버퍼 경계를 넘어 인접 메모리를 읽어 문자열에 담는다 → 인접 힙(다른 세션 버퍼/키/포인터)이 클라로 유출되거나, 매핑되지 않은 페이지 접근으로 크래시. 전형적 Heartbleed류 over-read.
• 재현조건: len(또는 count) 을 실제 페이로드보다 크게 보낸 악성 패킷 한 개면 충분.
• 근본 원인: 읽기 단위마다 pos_ + need <= size_ 불변식을 검사하지 않음.

(B) 신뢰되지 않은 길이/개수 선할당 — 메모리 증폭 DoS (보안/리소스)

• 증상: s.reserve(len), std::vector<uint8_t> buf(len)(u32 → 최대 4,294,967,295), titles.reserve(count) 가 검증 전에 할당한다. readBlob 에 len=0xFFFFFFFF 만 실어 보내면 실제 바이트가 없어도 ~4GB 할당 시도 → OOM/스왑/프로세스 종료. count 가 크면 벡터 예약 + 루프마다 문자열 예약으로 곱셈 증폭. 작은 패킷으로 거대한 자원 소모.
• 근본 원인: "선언된 크기" 와 "실제 가용 바이트" 를 분리하지 않고, 상한(cap)이 없다.

(C) size_t 커서 언더플로 / UTF-8 미검증 — 파싱 붕괴 (버그/정확성)

• 증상: pos_ 가 size_ 를 넘어 증가해도 막지 않는다. 다른 코드가 size_ - pos_(size_t) 로 잔여를 계산하면 언더플로 → 거대한 양수 → 추가 OOB/무한루프. 또 바이트를 그대로 std::string 에 담아 불완전/오버롱 UTF-8 을 통과시켜 다운스트림 (DB, 로그, 길이기반 로직, 클라 렌더)에서 깨진다. 닉네임 길이 제한 등 도메인 규칙도 없음.
• 근본 원인: 커서 전진에 상한 검사가 없고, 인코딩 유효성/도메인 상한 검증이 없다.

---

수정안

핵심: ① 읽기 단위마다 경계 검사(실패 시 거부), ② 길이·개수에 프로토콜 상한, ③ 선할당은 가용 바이트로 clamp, ④ UTF-8/도메인 검증.

#include <cstdint>
#include <string>
#include <vector>
#include <stdexcept>
#include <algorithm>

struct ParseError : std::runtime_error { using std::runtime_error::runtime_error; };

class Reader {
public:
    Reader(const uint8_t* data, size_t size) : data_(data), size_(size) {}

    size_t remaining() const { return size_ - pos_; }   // pos_ <= size_ 불변식 유지

    void need(size_t n) const {
        if (n > remaining()) throw ParseError("short read");   // 항상 경계 검사
    }

    uint16_t readU16() {
        need(2);
        uint16_t v = static_cast<uint16_t>(data_[pos_] | (data_[pos_ + 1] << 8));
        pos_ += 2;
        return v;
    }
    uint32_t readU32() {
        need(4);
        uint32_t v = static_cast<uint32_t>(data_[pos_]) |
                     (static_cast<uint32_t>(data_[pos_+1]) << 8) |
                     (static_cast<uint32_t>(data_[pos_+2]) << 16) |
                     (static_cast<uint32_t>(data_[pos_+3]) << 24);
        pos_ += 4;
        return v;
    }

    std::string readString(size_t maxLen) {
        uint16_t len = readU16();
        if (len > maxLen) throw ParseError("string too long");  // 프로토콜 상한
        need(len);                                              // 가용 바이트 확인 후
        std::string s(reinterpret_cast<const char*>(data_ + pos_), len); // 그제서야 복사
        pos_ += len;
        if (!isValidUtf8(s)) throw ParseError("invalid utf8");
        return s;
    }

    std::vector<uint8_t> readBlob(size_t maxLen) {
        uint32_t len = readU32();
        if (len > maxLen) throw ParseError("blob too long");
        need(len);                              // 실제 바이트가 있어야 할당
        std::vector<uint8_t> buf(data_ + pos_, data_ + pos_ + len);
        pos_ += len;
        return buf;
    }

private:
    static bool isValidUtf8(const std::string&);   // 표준 UTF-8 검증
    const uint8_t* data_;
    size_t size_;
    size_t pos_ = 0;
};

constexpr size_t kMaxTitle = 64;
constexpr size_t kMaxMailCount = 100;

std::vector<std::string> parseMailTitles(const uint8_t* buf, size_t n) {
    Reader r(buf, n);
    uint16_t count = r.readU16();
    if (count > kMaxMailCount) throw ParseError("too many titles"); // 개수 상한
    std::vector<std::string> titles;
    titles.reserve(std::min<size_t>(count, kMaxMailCount));         // clamp 예약
    for (uint16_t i = 0; i < count; ++i)
        titles.push_back(r.readString(kMaxTitle));
    return titles;
}

포인트

• need(n) 으로 모든 읽기 전 경계 검사 → 오버리드/유출 원천 차단. remaining() 은 pos_ <= size_ 불변식 덕에 언더플로 불가.
• 길이/개수에 프로토콜 상한(닉네임·제목·메일 수)을 두고 위반 시 연결 차단/패킷 폐기.
• 선할당은 검증·clamp 후 → 작은 패킷으로 거대한 메모리 못 만든다.
• UTF-8 검증으로 다운스트림 깨짐 방지.

---

더 나은 설계 (+트레이드오프)

1. 스키마 기반 직렬화(FlatBuffers/Protobuf/Cap'n Proto) + 검증 계층: 손으로 짠 파서 대신 검증된 코드 생성. 트레이드오프: 의존성/포맷 고정, 여전히 "도메인 상한" 검증은 직접 해야.
2. zero-copy view(std::string_view/span) + 지연 복사: 경계 검사 후 뷰만 넘기고 꼭 필요할 때 복사 → 할당 최소화. 트레이드오프: 수명 관리 주의(버퍼보다 오래 살면 안 됨).
3. 전체 메시지 크기 상한 + 필드별 상한을 한 곳에 선언(프로토콜 명세에 max 명시). 파서가 그 표를 강제. 트레이드오프: 명세-코드 동기화 필요.
4. 퍼징(libFuzzer/AFL)으로 파서 강건성 검증 + over-read 검출용 ASAN 상시화.

---

면접 포인트 (예상 질문)

1. len 검증 없이 data_[pos_++] 를 len 번 읽으면 C++ 에서 무슨 일이 생기나? 왜 정보 유출(Heartbleed류)로 이어지는가?
2. size_ - pos_ 를 size_t 로 계산하면 왜 위험하고, pos_ <= size_ 불변식이 어떻게 막는가?
3. u32 길이 1개로 4GB 할당을 유발하는 DoS 를, 기능을 깨지 않으면서 어떻게 막는가? (상한 + 가용바이트 검증 + clamp)