Wahr/Falsch
문제
독일어 원문
Programmierer fügen Stack Canaries manuell zwischen lokale Variablen und sicherheitskritische Daten ein.
한국어 해석
programmer가 stack canary를 수동으로 끼워 넣는다.
Wahr/Falsch 즉시 채점
선택 후 즉시 개념 함정을 확인하세요.
단계별 힌트
막혔을 때만 한 단계씩 여세요. 정답을 바로 읽는 것보다 기억을 꺼내는 시간이 중요합니다.
- 첫 힌트: 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
- Falsch로 표시한다.
- 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
- 함정: canary가 모든 memory corruption을 막는다고 쓰지 않는다.
- 후속 점검: canary leak이 있으면 방어가 약해지는 이유는?
채점 기준으로 내 답안 점검하기
- Falsch로 표시한다.
- 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
답안 슬롯 자가 점검 — 실제로 말하거나 쓴 항목만 체크하세요.
0/2 slots
정답과 핵심 해설 확인하기
Falsch. 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
- Falsch로 표시한다.
- 보통 compiler 옵션과 runtime이 stack frame에 canary를 자동 삽입하고 return 전에 변조를 검사한다.
Falsch
개념부터 다시 보는 상세 풀이
BEGINNER LESSON
Stack Canary: 누가 넣고, 언제 검사하며, 무엇을 못 막는가
ZERO-BASE START
정말 아무것도 모른다고 가정하고 시작합니다
전문 용어를 알고 있다고 가정하지 않습니다. 먼저 일상적인 장면을 보고, 그 장면의 사람과 행동에 실제 보안 용어를 하나씩 붙인 뒤, 시스템에서 일어나는 순서를 따라갑니다.
기초 개념 01
C의 buffer와 length 없는 sprintf
1타 강사식 시작: 이름은 잠시 가리고 장면부터 봅시다
10칸짜리 서랍에 30개 물건을 밀어 넣으면 옆 서랍의 물건까지 밀어내는 것과 같다. C는 자동으로 벽을 만들어 막아 주지 않는다.
지금은 이 비유를 완벽히 외울 필요가 없습니다. 누가 무엇을 가지고 있고, 무엇을 하려 하며, 어느 지점에서 문제가 생기는지만 찾으면 됩니다.
이제 실제 용어를 하나씩 붙여 봅시다
C의 char array는 정해진 크기의 연속된 memory 공간이다. Buffer에 들어갈 문자열 길이를 확인하지 않고 sprintf로 쓰면 경계를 넘어 인접 memory를 덮을 수 있다. 이를 buffer overflow라고 하며 crash, data corruption, 경우에 따라 code execution으로 이어질 수 있다. snprintf는 최대 길이를 받지만 반환값과 null termination 조건도 확인해야 한다.
TERMS FROM ZERO
전문 용어를 한 단어씩 풀기
아래 단어는 이미 안다고 가정하지 않습니다. 먼저 쉬운 뜻을 읽고, 본문에서 같은 단어가 나오면 이 정의로 다시 바꾸어 읽으세요.
Buffer
프로그램이 byte나 문자를 잠시 저장하도록 확보한 연속 memory 공간입니다.
Boundary / Bounds
Buffer가 합법적으로 사용할 수 있는 시작과 끝 범위입니다.
Null terminator
C 문자열의 끝을 표시하는 값 `\0`으로, 저장 공간 1바이트를 차지합니다.
Stack frame
한 함수 호출의 local variable, 저장된 register, return 관련 정보가 놓이는 stack 영역입니다.
Buffer overflow
확보한 buffer 범위를 넘어 write하여 인접 memory를 손상시키는 오류입니다.
프로그램이나 프로토콜 안에서는 다음 순서로 움직입니다.
- 목적지 buffer 크기를 확인한다.
- 공격자가 제어하는 문자열의 최대 길이를 확인한다.
- Format 후 필요한 길이가 buffer보다 큰지 계산한다.
- Bounded API와 반환값 검사, 명시적 길이 검증을 적용한다.
왜 여기서 많이 틀릴까요?
sprintf의 format string이 고정되어 있어도 출력 전체 길이가 제한되지 않으면 overflow가 생길 수 있다.
조건을 생략하거나 서로 다른 기능을 같은 것으로 취급했는지 확인하세요. 정답 문장을 외우는 것보다 틀린 이유를 말할 수 있어야 변형 문제를 풀 수 있습니다.
핵심부터 말하면 Falsch. 일반적으로 compiler가 함수의 stack frame에 canary 검사 코드를 삽입하고 runtime이 return 직전에 값의 변조를 확인합니다.
이 글에서 익힐 것
stack canary의 위치와 검사 시점을 이해한다.
programmer의 수동 변수와 compiler 방어 기능을 구분한다.
canary가 예방이 아니라 변조 탐지 중심의 완화책임을 이해한다.
먼저 알아야 할 개념
광산의 카나리아처럼 위험을 없애는 벽이 아니라 위험이 발생했음을 알려 주는 경보기입니다. 함수가 시작될 때 비밀에 가까운 값을 stack에 두고, 끝날 때 그대로인지 확인합니다.
예제로 확인하기
상황 설정
간단히 `[local buffer][canary][saved control data]` 순서의 stack frame을 생각합니다.
풀이 순서
함수 진입 때 compiler가 생성한 코드가 canary 값을 stack에 저장합니다.
buffer overflow가 buffer 끝을 넘어 control data 쪽으로 진행되면 보통 중간의 canary도 덮습니다.
함수 return 직전에 삽입된 검사 코드가 현재 canary와 기대값을 비교합니다.
값이 다르면 정상 return을 중단하고 프로그램을 종료해 손상된 return address 사용을 막으려 합니다.
canary 값을 공격자가 미리 알아내거나 canary를 건드리지 않는 memory corruption이라면 우회 가능성이 남습니다.
해설
보통 개발자가 소스에 canary 변수를 손으로 넣는 것이 아니라 compiler 옵션과 runtime 지원으로 자동 적용됩니다.
정답까지 사고 과정
문장의 행위 주체가 programmer인지 compiler/runtime인지 봅니다.
일반적 구현 주체가 compiler/runtime이므로 programmer라고 한 부분이 틀렸습니다.
canary의 동작을 ‘저장 → overwrite 가능 → return 전 비교 → abort’로 설명합니다.
모든 memory corruption을 막지는 않는다는 한계를 덧붙입니다.
시험장에서는 이렇게 쓰기
최소 답안
Falsch.
안전한 두 문장 답안
Falsch. Stack Canaries werden typischerweise durch den Compiler in den Stack Frame und die Rücksprungprüfung eingebaut. Vor dem Return wird geprüft, ob der Canary verändert wurde.
자주 틀리는 지점
canary가 overflow write 자체를 멈춘다고 쓰기
canary가 NX·ASLR과 같은 기능이라고 생각하기
canary가 leak되어도 항상 완전하게 작동한다고 단정하기
한 줄로 기억하기
Compiler가 경보값을 놓고, return 직전에 확인한다.
스스로 확인하기
canary가 바뀌는 시점과 검사되는 시점은?
canary 값을 공격자가 알면 왜 방어가 약해질 수 있는가?
이 문제가 어려운 이유
짧은 문제 문장 ‘programmer가 stack canary를 수동으로 끼워 넣는다.’ 안에 정의, 조건, 처리 순서가 압축되어 있습니다. 아래 예시에서는 이를 한 단계씩 펼쳐 확인합니다.
AI 구두시험용 프롬프트
한 문항만 풀어라. 먼저 정답을 열지 말고 90초 안에 답안을 말한 뒤, css-ws2025-26-seceng-mc-004의 채점 프레임으로 스스로 채점하라. 문제: programmer가 stack canary를 수동으로 끼워 넣는다.
학습 기록