버퍼 오버플로우 (Buffer Overflow)
쉽게 풀면
컵에 물을 따르는 상황을 생각해봅시다. 컵의 용량은 정해져 있는데 그보다 많은 물을 부으면 물이 넘쳐서 옆에 있는 다른 물건까지 젖게 됩니다. 프로그램의 "버퍼"도 이런 컵과 같습니다. 예를 들어 이름을 저장할 공간을 10글자로 잡아뒀는데, 사용자가 20글자를 입력하면 나머지 10글자가 원래 다른 데이터나 실행 코드가 있던 메모리 영역을 덮어쓸 수 있습니다. 공격자는 이 원리를 악용해서 넘치는 데이터 자리에 악성 코드를 몰래 심어 실행시키기도 하는데, 이것이 버퍼 오버플로우 공격입니다.
왜 중요한가
버퍼 오버플로우는 소프트웨어 보안 분야에서 가장 오래되고 근본적인 취약점 유형 중 하나로, 원격 코드 실행이나 권한 상승 같은 심각한 공격으로 이어질 수 있어 시스템 보안 연구에서 꾸준히 다뤄집니다. 그래서 이를 탐지하는 정적·동적 분석 기법, 취약점을 자동으로 찾아내는 퍼징(fuzzing) 기법, 메모리 안전성을 보장하는 프로그래밍 언어와 런타임 방어 기법 연구가 모두 이 개념과 맞닿아 있습니다. 임베디드 시스템이나 운영체제 커널처럼 성능 때문에 여전히 C/C++을 쓰는 영역에서는 지금도 실무적으로 중요한 문제로 남아 있습니다.
핵심 정리
- 버퍼 오버플로우는 버퍼에 쓰는 데이터가 경계 검사 부족으로 버퍼 바깥, 곧 인접한 메모리 주소의 값까지 훼손하는 현상입니다. 대상 버퍼보다 큰 데이터를 경계 확인 없이 복사할 때 생깁니다.
- C와 C++는 배열에 쓰는 데이터가 경계 안인지 자동으로 검사하지 않고, 메모리를 직접 다루게 해 줍니다. 이 때문에 이 언어들과 전통적으로 연결됩니다. Java, Python, Eiffel처럼 형식이 엄격하고 메모리 직접 접근을 허용하지 않는 언어는 대부분의 경우 이 문제를 막습니다.
- 문서로 확인되는 가장 이른 악의적 악용은 1988년 모리스 웜의 전파 수단 가운데 하나였습니다.
- 방어는 한 겹이 아니라 여러 겹으로 설계합니다. 경계 검사를 해 주는 라이브러리·언어, 반환 주소 앞의 값을 검사하는 스택 카나리, 주소를 무작위로 배치하는 ASLR, 데이터 영역의 실행을 막는 DEP/NX가 대표적입니다. ASLR은 악용을 어렵게 만들 뿐 불가능하게 하지는 않습니다.
- 연구 문헌에서는 메모리 오류를 오래된 보안 과제로 다룹니다. Szekeres 등(2013, 2014)의 논문 제목이 ‘메모리를 둘러싼 끝없는 전쟁’(Eternal war in memory)이고, Shacham 등(2004)은 주소 공간 무작위화의 효과(effectiveness)를 논문 주제로 삼았습니다.
예시로 보기
| 방어 | 하는 일 | 한계(논문에서 같이 언급되는 점) |
|---|---|---|
| 경계 검사·메모리 안전 언어 | 범위를 벗어난 접근을 막거나 오류로 처리 | 해당 언어·라이브러리를 써야 효과가 있음 |
| 스택 카나리 | 함수 종료 때 심어 둔 값이 바뀌었는지 검사 | 주로 스택 버퍼 오버플로를 탐지 |
| ASLR | 주소를 실행마다 무작위로 배치 | 악용을 어렵게 할 뿐 불가능하게 하지는 않음 |
| DEP/NX | 데이터 영역을 실행 불가로 표시 | 데이터 영역에 심어 둔 코드의 실행을 차단 |
위 표는 개념 비교용 요약입니다. 취약점 탐지 연구는 정적 분석(실행 없이 코드 검사)과 퍼징(입력을 바꿔 가며 실행)을 서로 보완하는 접근으로 다루는 경우가 많습니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| Java나 Python에는 버퍼 오버플로우가 없다. | 형식이 엄격하고 메모리 직접 접근을 허용하지 않는 언어는 버퍼 오버플로우를 ‘대부분의 경우’ 막는다고 설명됩니다. ‘전혀 없다’고 쓰면 과장입니다. |
| ASLR이나 카나리가 있으면 안전하다. | 이런 방어는 악용을 어렵게 만드는 것이지 취약점을 없애는 것이 아닙니다. 근본 해결은 경계를 지키는 코드 작성과 검사입니다. |
| SQL 인젝션과 같은 종류의 공격이다. | 둘 다 입력값 처리 부실에서 오지만, 버퍼 오버플로우는 데이터베이스가 아니라 프로세스 메모리의 경계를 침범하는 문제입니다. |
| 오래된 취약점이라 이제는 연구할 것이 없다. | 1988년의 악용 사례 이후에도 Szekeres 등의 2013·2014년 논문처럼 메모리 오류를 다루는 연구가 이어졌습니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
이 문장은 프로그램 코드를 실행하지 않고도 분석해서(정적 분석), 배열이나 메모리 공간의 크기를 제대로 확인하지 않는 위험한 코드 구간을 자동으로 찾아냈다는 뜻입니다.
이 문장은 실제로 프로그램을 실행시키면서(동적 분석) 다양한 입력값을 무작위로 넣어보는 방식(퍼징)으로, 임베디드 기기에 들어가는 저수준 프로그램에서 버퍼 오버플로우가 발생하는 지점을 찾아냈다는 뜻입니다.
이 문장은 프로그램이 실행되기 전인 컴파일 단계에서부터 언어 차원의 규칙(소유권 시스템)으로 메모리를 잘못 다루는 코드 자체를 막아, 버퍼 오버플로우가 일어날 여지를 없애는 접근을 설명한 것입니다.
조금 더 깊게 보면
버퍼 오버플로우는 넘치는 위치에 따라 흔히 스택 오버플로우와 힙 오버플로우로 구분되며, 특히 스택 위에서 함수의 반환 주소를 덮어써 공격자가 원하는 코드를 실행시키는 방식이 고전적으로 많이 연구되었습니다. 이를 막기 위한 방어 기법으로는 스택에 임의의 값(카나리)을 심어두고 함수 종료 시 값이 바뀌었는지 확인하는 스택 카나리, 메모리 주소를 매번 무작위로 배치해 공격을 어렵게 만드는 주소 공간 배치 난수화(ASLR), 데이터 영역을 실행 불가능하게 만드는 실행 방지(DEP/NX) 등이 논문에서 자주 함께 언급됩니다. 취약점 탐지 논문을 읽을 때는 정적 분석과 동적 분석(퍼징)이 서로 다른 장단점을 가진 상호보완적 접근이라는 점을 함께 알아두면 도움이 됩니다.
주의할 점
버퍼 오버플로우는 C, C++처럼 메모리를 직접 다루는 저수준 언어에서 특히 흔하며, Java나 Python처럼 메모리 경계를 자동으로 검사하는 언어에서는 상대적으로 드뭅니다. SQL 인젝션처럼 입력값 검증이 부실할 때 발생한다는 공통점이 있지만, 버퍼 오버플로우는 데이터베이스가 아니라 메모리 공간 자체를 침범한다는 점에서 다릅니다.
헷갈리기 쉬운 용어
취약점 이름과 방어 기법 이름이 한 논문에 같이 나오므로 구분해 두면 편합니다.
| 용어 | 한 줄 설명 | 성격 |
|---|---|---|
| 버퍼 오버플로우 | 경계를 넘어 인접 메모리를 훼손하는 오류 | 취약점(원인) |
| 버퍼 오버플로우 익스플로잇 | 이 오류를 이용해 프로그램의 동작을 바꾸려는 공격 쪽의 용어 | 공격 |
| 스택 카나리 | 반환 주소 앞의 값이 바뀌었는지 검사 | 방어 |
| ASLR | 메모리 배치 주소를 무작위로 바꿈 | 방어 |
| SQL 인젝션 | SQL 질의에 악의적 입력을 끼워 넣는 공격 | 다른 종류의 입력 검증 실패 |
참고 문헌
- Shacham, H., Page, M., Pfaff, B., Goh, E.-J., Modadugu, N., & Boneh, D. (2004). On the effectiveness of address-space randomization. Proceedings of the 11th ACM Conference on Computer and Communications Security, 298–307.
- Szekeres, L., Payer, M., Wei, T., & Song, D. (2013). SoK: Eternal war in memory. 2013 IEEE Symposium on Security and Privacy, 48–62.
- Szekeres, L., Payer, M., Wei, L. T., & Sekar, R. (2014). Eternal war in memory. IEEE Security & Privacy, 12(3), 45–53.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.