프로그래밍공부(Programming Study)/CS-운영체제(OS)

eBPF는 왜 안전한가 (그리고 언제 위험한가)

Chann._.y 2026. 4. 7.

728x90

앞 글에서 eBPF로 malloc을 추적하는 방법을 봤다.

코드를 바꾸지 않고도:

어떤 함수에서 malloc이 호출되는지 보고
얼마나 할당되는지 보고
흐름까지 따라갈 수 있다

여기까지 보면 한 번쯤 이런 생각이 든다.

“이거 커널에서 코드 실행하는 거잖아… 위험한 거 아닌가?”

맞는 질문이다.
그리고 이걸 제대로 이해해야 eBPF를 안심하고 쓸 수 있다.

eBPF가 위험해 보이는 이유

eBPF를 처음 보면 불안한 이유는 단순하다.

커널에서 실행됨
동적으로 로드됨
외부에서 코드 주입 가능

이걸 그대로 받아들이면 거의 이런 느낌이다.

“커널에 코드 꽂아 넣는 거 아냐?”

그런데 실제로는 그렇게 동작하지 않는다.

eBPF는 커널을 “수정”하지 않는다

이건 중요한 포인트다.

eBPF는 커널 코드를 바꾸지 않는다

대신 이렇게 한다.

커널 이벤트 발생
 ↓
hook
 ↓
eBPF 코드 실행

즉,

정해진 지점에서, 잠깐 끼어들어 실행되는 구조다

이 차이가 크다.

커널 수정 ❌
커널 확장 ⭕

핵심: verifier가 모든 걸 막는다

eBPF가 안전한 이유는 사실 하나로 정리된다.

verifier

커널은 eBPF 프로그램을 실행하기 전에
무조건 검사를 한다.

이게 그냥 간단한 체크가 아니다.

verifier가 보는 것

메모리 접근 안전한지
포인터 이상한 데 안 가는지
무한 루프 없는지
허용된 함수만 쓰는지

👉 통과 못 하면?

그냥 실행 자체가 안 된다

즉,

위험한 코드는 아예 커널에 들어가지 못한다

그래서 가능한 것과 불가능한 것이 나뉜다

가능한 것

함수 호출 관찰
데이터 수집
통계 집계
네트워크 처리

불가능한 것

임의 메모리 덮어쓰기
커널 구조 변경
무한 루프
시스템 망가뜨리기

👉 핵심은 이거다.

읽고 관찰하는 건 강하지만, 마음대로 바꾸는 건 못 한다

그런데 “완전히 안전하다”는 건 아니다

여기서 중요한 포인트가 하나 더 있다.

안전하게 설계되어 있지만, 완벽하진 않다

실제로 문제가 되는 경우

1. verifier 버그

verifier가 완벽하면 좋겠지만,
결국 소프트웨어라 버그가 있을 수 있다.

이게 뚫리면:

잘못된 메모리 접근
커널 권한 상승

같은 문제가 가능해진다.

👉 그래서 eBPF 취약점 얘기가 나온다.

2. 성능 문제

이건 꽤 현실적인 문제다.

eBPF 프로그램이 너무 무겁거나
너무 자주 실행되면:

CPU 사용 증가
latency 증가

👉 즉,

성능 DoS는 가능하다

3. 정보 수집 (관찰 자체가 위험)

eBPF는 강력한 관찰 도구다.

그래서 반대로 생각하면:

syscall 추적 가능
네트워크 흐름 확인 가능

👉 잘못 쓰면

민감 정보 수집 도구가 될 수도 있다

그래서 권한이 중요하다

이걸 보면 결론이 하나 나온다.

아무나 eBPF를 못 쓰게 해야 한다

그래서 기본적으로:

root 권한 필요
CAP_BPF 같은 capability 필요

즉,

이미 강한 권한이 있어야 쓸 수 있다

중요한 관점 하나

여기서 많이 헷갈리는 부분이다.

❌ eBPF가 위험하다

✅ 정확한 표현

권한 + 취약점이 있으면 위험해진다

즉,

eBPF 자체가 문제라기보다
“강력한 도구”라는 게 핵심이다

비유로 보면

eBPF = 관리자 콘솔

정상 → 시스템 분석 도구
악용 → 공격 도구

👉 도구 자체는 중립이다.

정리하면

eBPF는 커널을 수정하지 않는다
hook 기반으로 동작한다
verifier가 안전성을 강제한다
하지만 취약점이 있으면 공격 surface가 된다

여기까지 오면 다음 질문이 나온다

이제 자연스럽게 이런 생각이 든다.

“그럼 eBPF 내부 구조는 어떻게 생긴 거지?”
“어떻게 저걸 실행하는 거지?”

한 줄 정리

eBPF는 커널을 직접 수정하는 것이 아니라 제한된 환경에서 코드를 실행하는 구조이며, verifier를 통해 안전하게 동작하지만 잘못 사용되거나 취약점이 존재하면 공격 경로가 될 수 있다.