가장 안전한 OS의 허점, ‘오류 메시지’가 격리벽을 돌아왔다

Qubes OS는 프로그램과 데이터를 여러 가상 머신에 나눠 담아 공격 피해가 번지지 않게 하는 운영체제입니다. 그런데 QSB-118의 원인은 복잡한 가상화 기술이 아니었습니다. 파일 복사 실패를 알리는 오류 보고 기능이 격리벽을 거슬러 돌아오는 통로가 됐습니다.

파일은 한쪽으로 갔지만 메시지는 돌아왔습니다

Qubes OS에서는 업무, 금융, 개인 활동을 ‘큐브’라고 부르는 서로 다른 가상 머신에 나눠둘 수 있습니다. 한 큐브가 해킹되더라도 곧바로 다른 큐브까지 침범하지 못하도록 한 구조입니다.

문제는 큐브 사이에서 파일을 복사할 때 생겼습니다. 사용자가 출발지 큐브에서 목적지 큐브로 파일을 보내면 데이터는 정해진 방향으로 이동합니다. 겉보기에는 단방향 작업입니다.

하지만 복사는 실패할 수 있습니다. 목적지의 저장 공간이 부족하거나 파일을 쓸 수 없을 때가 대표적입니다. 이 사실을 사용자에게 알리려면 목적지에서 출발지로 오류 내용을 되돌려 보내야 합니다.

이 대목에 숨어 있던 역방향 통신이 드러납니다. 파일은 앞으로 가는데 오류 메시지는 뒤로 돌아옵니다. 사용 편의를 위한 백채널, 즉 되돌아오는 통신 경로가 생긴 것입니다.

평범한 오류 문구가 명령어로 해석된 이유

오류 메시지는 원래 화면에 표시하기만 하는 데이터입니다. 문제는 이 문자열을 처리하면서 셸 명령을 실행하는 system() 계열 방식을 썼다는 데 있습니다.

셸은 단순한 문장과 실행할 명령을 스스로 구분하지 못합니다. 프로그램이 외부에서 받은 문자열을 제대로 걸러내지 않은 채 명령문에 끼워 넣으면, 공격자는 오류 문구에 특수문자와 명령을 섞어 보낼 수 있습니다.

예를 들어 프로그램은 “파일 복사 실패”라는 알림만 띄우려 합니다. 하지만 조작된 목적지 큐브는 오류 내용에 추가 명령을 담아 돌려보낼 수 있습니다. 출발지 프로그램이 이를 데이터가 아니라 명령의 일부로 받아들이면 임의 코드 실행으로 이어집니다.

보안 개발자들이 system() 사용을 경계하는 까닭이 바로 이것입니다. 편리한 함수이지만 입력값이 조금이라도 외부에서 들어오면 공격 표면이 급격히 넓어집니다. 이번 취약점의 핵심도 화려한 가상 머신 탈출 기술이 아니라 오래된 명령어 삽입 문제였습니다.

신뢰할 수 없는 목적지가 출발지를 공격합니다

이 취약점에서 눈여겨볼 대목은 공격 방향입니다. 보통은 파일을 받는 목적지가 더 위험하다고 생각하기 쉽습니다. 악성 파일이 넘어가기 때문입니다.

이번에는 반대 방향도 위험했습니다. 신뢰도가 낮거나 이미 장악된 목적지 큐브가 오류 응답을 조작해 파일을 보낸 출발지 큐브를 공격할 수 있었습니다.

가령 중요한 문서를 보관한 큐브에서 분석용 큐브로 파일을 복사한다고 가정해 보겠습니다. 사용자는 중요 데이터가 바깥으로 나간다는 위험만 떠올리기 쉽습니다. 하지만 분석용 큐브가 공격자에게 장악된 상태라면, 복사 결과를 알려주는 응답을 이용해 출발지에서 코드를 실행하려고 시도할 수 있습니다.

다만 이 취약점이 Qubes OS 전체를 곧바로 무너뜨린다고 받아들이면 곤란합니다. 임의 코드가 실행된 큐브와 핵심 관리 영역인 dom0는 분명히 구분해야 합니다. Qubes OS의 격리 구조도 여전히 피해 범위를 줄여줍니다.

그래도 가볍게 볼 문제는 아닙니다. 사용자가 단방향이라고 생각한 작업에 뜻밖의 역방향 공격 경로가 있었기 때문입니다. 보안 모델을 세울 때는 기술 문서뿐 아니라 사용자가 기능을 어떻게 이해하는지도 살펴야 합니다.

커뮤니티가 다시 주목한 ‘작은 편의 기능’

이 이슈는 2026년 8월 30일 Hacker News에서 215점과 88개 댓글을 기록했습니다. 공개 후 하루 만에 적지 않은 개발자가 관심을 보였습니다.

반응은 크게 두 갈래였습니다. 먼저 “system()이 왜 위험한지 보여주는 또 하나의 사례”라는 지적이 나왔습니다. 입력값과 셸 명령을 섞지 말라는 오래된 원칙이 최첨단 보안 운영체제에서도 다시 확인된 셈입니다.

한편 Qubes OS 자체에 대한 신뢰를 거두지 않은 이들도 있었습니다. 한 사용자는 이 정도의 작전 보안이 필요한 표적은 아니지만 Qubes의 설계에는 여전히 깊은 인상을 받았다고 말했습니다. 또 다른 사용자는 금융 전용 노트북에서 Qubes OS를 계속 사용하고 있다고 밝혔습니다.

최근 한 달 동안 공개적으로 확인할 수 있는 커뮤니티 논의는 이 Hacker News 게시물에 주로 모여 있어 그 범위가 제한적입니다. 따라서 이용자 전체의 평가가 달라졌다고 단정하기는 어렵습니다. 지금까지는 “Qubes OS가 끝났다”보다 “강한 격리 시스템도 작은 보조 경로를 놓칠 수 있다”는 교훈에 무게가 실립니다.

QSB-118은 보안의 약한 고리가 늘 핵심 기능에만 숨어 있는 것은 아니라는 점을 보여줍니다. 때로는 사용자를 돕기 위해 만든 오류 한 줄이 전혀 예상하지 못한 통로가 되기도 합니다. 우리가 단방향이라고 믿는 기능에는 정말 돌아오는 길이 없을까요?