By Mark 목차
운영체제 권한 분석: 해커의 시선으로 바라본 3가지 권한의 허상과 심층 작동 원리
이 글에서는 권한의 허상에 대한 깊이 있는 분석을 진행합니다. 권한의 허상은 제가 타인에게 설명할때 종종 사용하는 개념입니다. 다만 내용은 아주 예전 이야기로 현재는 별로 적용되는 내용은 아닙니다. 제가 하고자 하는 말은 개념의 전환을 이야기 하는 것으로 이해 해주시면 될 것 같습니다. 20년 경력을 하나씩 소개하는 글을 작성하려고 합니다.
우리는 컴퓨터를 사용할 때 ‘관리자 권한으로 실행’이라거나 ‘sudo’라는 명령어를 자연스럽게 사용합니다. 대학교 운영체제(OS) 강의 시간에도 커널 모드와 유저 모드의 분리, 그리고 시스템 콜(System Call)을 통한 안전한 자원 접근에 대해 배웁니다. 하지만 이론적으로 배우는 OS의 철벽 같은 방어선과, 실제 상업적 보안 제품을 만들거나 해킹 사고를 분석하며 마주하는 OS의 민낯은 큰 차이가 있습니다.
오늘 다룰 내용은 대학 강의실의 정제된 이론을 넘어, 시스템의 가장 밑바닥인 커널(Kernel) 수준에서 바라본 ‘권한’의 실체에 대한 이야기입니다. 특히 윈도우와 리눅스라는 양대 산맥을 오가며 개발과 보안을 경험하며 느꼈던 그 강렬한 충격의 기록이기도 합니다.
권한의 허상은 해킹 기법과도 밀접한 관련이 있습니다. 학습자에서 해커로 넘어가는 개념적인 전환이 필요한 내용입니다.
1. 대학 강의실과 실전 개발 현장의 괴리
대학교에서 OS를 배울 때 우리는 시스템 콜을 매우 성스러운 ‘교량’처럼 학습합니다. “사용자가 직접 하드웨어에 접근하면 위험하니, OS라는 전능한 존재에게 부탁(Request)을 하는 통로”라고 말이죠. 하지만 실제 상업용 제품, 특히 보안 솔루션을 개발하다 보면 이 시스템 콜은 전혀 다른 의미로 다가옵니다. 결국 권한은 보안 위협으로 작용할 수 있습니다.
시스템 콜을 바라보는 두 가지 시선
개발자의 입장에서 시스템 콜은 단순히 기능을 호출하는 API에 불과합니다. 하지만 보안을 설계하거나 뚫으려는 사람의 눈에는 시스템 콜이 ‘성벽의 틈새’로 보입니다. 상업적 목적의 제품을 만들 때는 이 시스템 콜 하나하나가 성능의 병목점이 되기도 하고, 반대로 공격자가 커널의 통제권을 빼앗기 위해 조작(Hooking)해야 하는 최우선 공략 대상이 되기도 합니다.
따라서 권한의 허상은 해커의 사고 방식을 이해하는 데 도움이 됩니다.
저는 이론적으로만 알던 이 통로들을 직접 뜯어보고 조작하며 큰 충격을 받았습니다. 학교에서는 “절대 넘을 수 없다”고 가르쳤던 유저와 커널의 경계가, 실전에서는 종이 한 장 차이의 논리적 구분일 뿐이라는 사실을 깨달았기 때문입니다. 너무나 쉽게 변경되고, 너무나 쉽게 권한을 받을 수 있었습니다.
2. 권한의 실체: 당신이 믿고 있는 성벽은 비트의 나열일 뿐이다
우리가 흔히 말하는 ‘루트(Root) 권한’ 혹은 ‘시스템 관리자 권한’은 운영체제 내에서 어떤 절대적인 힘을 가진 물리적 실체처럼 느껴지곤 합니다. 하지만 커널 디버거를 켜고 메모리 깊숙한 곳을 들여다보면, 그 거창한 권한의 실체는 사실 메모리 위의 아주 작은 숫자, 즉 비트(Bit)의 나열에 불과합니다.
메모리 속의 숫자 놀이
결론적으로 권한의 허상은 대부분의 보안 전문가가 전환해야될 개념으로 생각됩니다.
윈도우에서는 EPROCESS라는 구조체가, 리눅스에서는 task_struct라는 구조체가 각 프로세스의 모든 정보를 담고 있습니다. 이 거대한 데이터 덩어리 안에는 “이 프로세스가 어떤 권한을 가지고 있는가?”를 나타내는 작은 공간이 있습니다.
만약 어떤 방법으로든 커널 메모리에 접근하여 특정 위치의 0을 1로 바꾸거나, 유저 ID를 뜻하는 1000을 0(Root)으로 덮어쓸 수 있다면 어떻게 될까요? OS는 방금 전까지 평범한 사용자였던 프로세스를 아무런 의심 없이 ‘신(God)’으로 대접하기 시작합니다.
이것이 바로 제가 느꼈던 권한의 허상입니다. 우리가 철석같이 믿고 있던 보안 체계는 결국 “이 메모리 주소의 비트 값이 외부의 개입으로 변하지 않을 것”이라는 연약한 전제 조건 위에 서 있는 셈입니다.
3. 중학생도 이해하는 ‘권한 뺏기’ (Bash 익스플로잇의 예시)
그렇다면 해커들은 어떻게 이 ‘비트의 나열’을 조작해서 권한을 얻어낼까요? 가장 유명한 리눅스의 Bash 익스플로잇 과정을 아주 쉬운 비유로 설명해 보겠습니다.
성문의 암호와 고장 난 메모지
컴퓨터를 커다란 성(Castle)이라고 상상해 봅시다. 당신은 이 성에 방문한 손님(일반 사용자)입니다. 성 안에는 왕만 들어갈 수 있는 비밀 창고(Root 권한)가 있고, 그 앞에는 문지기(OS)가 서 있습니다.
평소에 문지기는 당신의 신분증을 철저히 검사합니다. 그런데 이 성에는 손님들이 문지기에게 메모를 남길 수 있는 게시판(Bash 같은 프로그램)이 하나 있다고 가정해 봅시다.
- 상황 발생: 해커는 게시판에 아주 아주 긴 메모를 적습니다. 게시판의 크기는 손바닥만 한데, 해커는 트럭 한 대 분량의 종이를 쑤셔 넣습니다.
- 사고 발생: 게시판이 꽉 차다 못해 터져버리면서, 바로 옆에 있던 문지기의 ‘출입 매뉴얼’ 위로 잉크가 쏟아집니다.
- 결과: 매뉴얼의 “신분증을 확인한다”라는 문구가 잉크에 지워지고, 그 자리에 해커가 미리 준비한 “누구든 통과시킨다”라는 문구가 교묘하게 적힙니다.
- 권한 상승: 이제 문지기는 바보가 되어버렸습니다. 해커가 당당하게 걸어가면 문지기는 “어? 매뉴얼에 통과시키라고 되어 있네?”라며 왕의 창고 문을 열어줍니다.
실제 Bash 익스플로잇(예: Shellshock 등)도 이와 비슷합니다. 프로그램이 처리할 수 있는 양보다 훨씬 많거나 복잡한 데이터를 보내서, 프로그램의 원래 흐름을 망가뜨리고 해커가 원하는 명령어를 강제로 실행하게 만드는 것이죠. 결국 ‘시스템의 빈틈’을 이용해 앞서 말한 ‘권한 비트’를 조작하는 행위로 이어집니다.
4. 2025년의 관점에서 본 운영체제 보안의 흐름
2025년 현재, 운영체제 보안은 단순히 비트를 숨기는 단계를 넘어섰습니다. 이제는 eBPF(extended Berkeley Packet Filter) 같은 기술을 통해 커널 내부의 움직임을 실시간으로 감시하거나, 제로 트러스트(Zero Trust) 원칙을 커널 수준까지 확장하고 있습니다.
하지만 기술이 아무리 발전해도 변하지 않는 진리는 있습니다. 모든 소프트웨어는 사람이 만들며, 논리가 있는 곳에는 반드시 빈틈이 존재한다는 것입니다.
오늘 제가 이야기한 권한의 허상과 시스템 콜의 이면은 보안의 끝이 아니라 시작입니다. 이 글을 읽으며 “진짜로 메모리 주소를 바꾸면 권한이 생길까?” 혹은 “윈도우의 Token 구조체는 어떻게 생겼을까?”라는 궁금증이 생기셨나요? 그렇다면 여러분은 이미 해커의 시선을 갖기 시작한 것입니다.
관심이 생기신 분들은 아래와 같은 키워드로 더 깊이 탐구해 보시기 바랍니다.
- Linux Credential Structure (struct cred)
- Windows Token Manipulation
- Privilege Escalation via Buffer Overflow
- Kernel Exploit Development
이 키워드들만 구글에 검색해 보아도, 오늘 제가 설명한 ‘비트의 나열’이 실제 코드로 어떻게 구현되어 있는지 금방 찾아내실 수 있을 것입니다.
5. 마치며: 보이는 것이 전부가 아니다
대학에서 배운 지식은 훌륭한 기초가 됩니다. 하지만 그 기초 위에 안주하는 순간, 우리는 기술의 본질을 놓치기 쉽습니다. 윈도우와 리눅스 커널이라는 거대한 미로를 직접 헤매며 얻은 교훈은, 시스템은 우리가 생각하는 것보다 훨씬 유연하며 동시에 취약하다는 점이었습니다.
권한이라는 이름의 허상을 깨닫고 나면, 비로소 시스템을 어떻게 더 안전하게 방어할 수 있을지에 대한 진정한 답이 보이기 시작합니다. 다음 글에서는 제가 실제로 루트킷(Rootkit)이라는 공격 기술의 탄생에 대해서 적어보겠습니다. Windows 초기버전이나 Linux 초기버전에서 그 파괴적인 기술을 어떻게 가장 강력한 보안 드라이버로 변모시켰는지, 그 치열한 수비의 과정을 공유해 보겠습니다.
다만 이제 루트킷은 단순히 소프트웨어적인 트릭으로 만드는 것이 아니라, 디지털 서명 탈취, 하드웨어 취약점(펌웨어) 공략, 혹은 복잡한 가상화 우회 기술이 필요한 영역이 되었습니다. 공격 비용이 너무 높아져서 일반적인 악성코드보다는 국가 단위의 APT 공격 그룹에서나 주로 사용하는 도구가 되었기 때문에 공유해도 실제로 사용할 수 있는 사람은 거의 없을 것이라 생각됩니다. (쓸수 있는 사람은 이미 쓰고 있을 것이라 생각됩니다.)