iTerm2 사용자라면 'cat readme.txt'도 위험하다 - 터미널 이스케이프 시퀀스의 함정

"그냥 cat 한 번 했을 뿐인데"

터미널에서 파일 내용을 보고 싶을 때 가장 먼저 치는 명령어가 뭔가요? 아마 cat일 거예요. README 파일이든 로그 파일이든 일단 cat 한 번 던져서 내용 확인하는 게 너무 익숙한 습관이죠. 그런데 만약 이 단순한 cat readme.txt 한 줄이 여러분 컴퓨터에서 임의의 명령을 실행시킬 수 있다면 어떨까요? 그것도 macOS 개발자들이 가장 많이 쓰는 터미널 중 하나인 iTerm2 에서요.

최근 calif.io 블로그에서 공개된 분석에 따르면, iTerm2의 특정 기능을 통해 악의적으로 조작된 텍스트 파일을 cat으로 출력하기만 해도 임의의 코드 실행이 가능한 취약점이 있었어요. 이게 무서운 이유는 우리가 cat을 안전한 명령이라고 굳게 믿어왔기 때문이에요. 파일을 "읽기만" 하는 거니까 위험할 게 없다고 생각했죠. 하지만 현대 터미널은 단순히 글자를 출력하는 도구가 아니에요.

터미널 이스케이프 시퀀스가 뭐길래

이 문제를 이해하려면 이스케이프 시퀀스(escape sequence) 가 뭔지 알아야 해요. 터미널에는 글자뿐 아니라 "이 부분은 빨갛게 칠해줘", "커서를 위로 옮겨줘", "화면을 지워줘" 같은 명령도 같이 보낼 수 있어요. 이런 명령은 보통 ESC 문자(아스키 코드 27, \x1b)로 시작하는 특별한 문자 조합으로 표현되는데, 이게 이스케이프 시퀀스예요. 우리가 터미널에서 보는 화려한 색깔이나 진행률 바도 다 이걸로 만들어지는 거죠.

문제는 일부 터미널이 이 이스케이프 시퀀스에 너무 강력한 기능을 추가했다는 거예요. iTerm2의 경우 다른 앱에서 파일을 열거나, 알림을 띄우거나, 이미지를 표시하는 등의 확장 기능을 시퀀스로 지원해 왔어요. 그중 일부 시퀀스가 외부 명령을 호출할 수 있는 통로가 되어버린 거죠. 공격자는 텍스트 파일 안에 이런 특별한 바이트 조합을 숨겨놓고, 피해자가 그 파일을 cat이나 less로 열기만 하면 시퀀스가 해석되면서 의도하지 않은 동작이 실행되는 거예요.

구체적으로 어떤 위험이 있을까

이런 종류의 취약점은 사실 처음이 아니에요. 2003년에는 xterm에 비슷한 문제가 있어서 "터미널 타이틀을 설정"하는 시퀀스를 통해 임의 명령 실행이 가능했고, 2017년에는 Terminal.app, Hyper, iTerm2 등 여러 터미널에서 URL 자동 감지 기능을 통한 RCE 취약점이 발견된 적이 있죠. 이번 분석은 iTerm2의 특정 기능 조합에서 여전히 비슷한 패턴의 위험이 살아있음을 보여준 사례예요.

공격 시나리오는 생각보다 간단해요. 깃허브에서 누군가의 저장소를 클론하고 README를 cat으로 확인했는데, README에 숨어있던 시퀀스가 셸 명령을 실행시켜서 SSH 키나 환경 변수를 외부로 빼돌리는 식이죠. 또는 로그 파일에 사용자 입력이 그대로 들어가는 서비스라면, 공격자가 일부러 이스케이프 시퀀스를 포함한 입력을 보내고, 운영자가 나중에 로그를 cat으로 확인하다가 당하는 시나리오도 가능해요.

다른 터미널들은 어떨까

사실 이 문제는 iTerm2만의 문제가 아니라 터미널 에뮬레이터 전반의 오래된 숙제예요. Alacritty, Kitty, WezTerm 같은 모던 터미널들은 위험한 시퀀스를 기본적으로 비활성화하거나 제한된 화이트리스트만 허용하는 방식으로 대응하고 있어요. 반면 기능이 풍부한 터미널일수록 공격 표면이 넓어진다는 딜레마가 있죠. iTerm2는 이미지 표시, 셸 통합, 트리거 등 강력한 기능들을 자랑해왔는데, 그게 양날의 검이 된 셈이에요.

Windows Terminal이나 Linux의 GNOME Terminal 같은 곳에서도 비슷한 종류의 문제가 주기적으로 발견되고 있어요. 결국 "모든 입력은 신뢰할 수 없다"는 보안의 기본 원칙이 터미널에도 그대로 적용되는데, 우리는 그동안 너무 쉽게 "내 컴퓨터의 파일이니까 안전해"라고 가정해왔던 거죠.

한국 개발자에게 주는 시사점

실무에서 당장 할 수 있는 일이 몇 가지 있어요. 첫째, iTerm2를 최신 버전으로 업데이트 하세요. 보안 패치가 나왔다면 즉시 적용해야 해요. 둘째, 출처가 의심스러운 텍스트 파일을 볼 때는 cat 대신 less -R 없이 사용하거나, VS Code 같은 GUI 에디터로 여는 게 더 안전해요. 가장 보수적인 방법으로는 xxd나 hexdump로 바이트를 직접 확인하는 방법도 있고요.

특히 보안에 민감한 작업을 하는 분들이라면, 신뢰할 수 없는 저장소를 클론하거나 외부에서 받은 로그를 분석할 때 별도의 격리된 환경(VM이나 컨테이너)을 쓰는 습관을 들이는 것도 좋아요. 또 서비스 운영자라면 사용자 입력을 로그에 남길 때 제어 문자를 필터링하는 처리를 해두는 것도 중요한 방어 수단이 됩니다.