---
title: "iTerm2 쓰면 `cat readme.txt` 한 줄로 RCE가 터진다"
published: 2026-04-17T18:43:32.000Z
canonical: https://jeff.news/article/1822
---
# iTerm2 쓰면 `cat readme.txt` 한 줄로 RCE가 터진다

iTerm2의 SSH integration 기능이 터미널 출력 소스를 검증하지 않아, 악성 텍스트 파일을 cat만 해도 가짜 conductor 세션으로 속여 원격 코드 실행이 가능하다는 버그가 공개됐다. 3월 31일 패치됐지만 stable 릴리스엔 아직 미반영. base64 청크 충돌까지 동원한 정교한 익스플로잇이다.

- `cat readme.txt` 한 줄로 RCE(원격 코드 실행)가 터진다는 얘기. 조건은 단 하나, **iTerm2를 쓰고 있을 것**
  - 처음 보면 미친 소리 같지만 iTerm2의 "SSH integration" 기능을 파고들면 말이 됨
  - 발견자는 calif.io 리서처들. OpenAI와 협업 프로젝트로 진행. 3월 30일 신고, 31일 커밋으로 수정됐지만 아직 stable 릴리스엔 반영 전

### iTerm2의 SSH integration이 뭐길래

- iTerm2는 SSH 세션을 "맹목적으로 명령어를 타이핑"하는 방식이 아니라 원격에 헬퍼 스크립트를 심어놓고 대화하는 구조
  - 그 스크립트 이름이 **conductor**. `it2ssh`로 SSH 통합을 띄우면 conductor가 원격 셸에서 돌기 시작함
  - 그다음부터는 iTerm2 ↔ conductor가 터미널 이스케이프 시퀀스를 프로토콜 삼아 대화함. 로그인 셸 감지, 파이썬 체크, 디렉토리 이동, 파일 업로드, 명령 실행까지 전부 이 채널로
- 핵심은 "별도 네트워크 서비스가 없다"는 것
  - conductor는 그냥 원격 셸 안에서 돌아가는 스크립트고, 프로토콜은 일반 터미널 I/O에 얹혀 흘러감
  - `DCS 2000p`로 conductor를 hook하고, `OSC 135`로 pre-framer 메시지를 주고받음

### 버그의 정체 — 신뢰 검증이 없다

- iTerm2는 **터미널 출력이 진짜 원격 conductor에서 온 건지 검증하지 않음**
  - 그래서 악의적 파일, 서버 응답, MOTD 배너 등 "아무 텍스트"가 가짜 DCS 2000p + 가짜 OSC 135를 찍어내면 iTerm2가 속아넘어감
  - iTerm2 입장에서는 "아, SSH conductor 세션 시작됐구나" 하고 정상 워크플로우를 돌리기 시작함

> [!WARNING]
> 단순히 파일을 `cat`하는 것만으로 트리거된다. 악성 README가 git 저장소에 포함되어 있거나, 웹에서 다운받은 텍스트 파일, 심지어 원격 서버의 MOTD에도 숨어있을 수 있다는 뜻.

### 공격 시퀀스

```mermaid
sequenceDiagram
    participant 악성파일 as readme.txt
    participant iTerm2
    participant PTY
    participant 로컬셸 as 로컬 셸

    악성파일->>iTerm2: 가짜 DCS 2000p hook
    iTerm2->>iTerm2: conductor 파서 인스턴스화
    iTerm2->>PTY: getshell() 자동 전송
    악성파일->>iTerm2: 가짜 OSC 135 (성공 응답)
    iTerm2->>PTY: pythonversion() 전송
    악성파일->>iTerm2: OSC 135 (실패 응답)
    iTerm2->>PTY: run <공격자 제어 sshargs> 전송
    PTY->>로컬셸: base64 청크들 입력
    로컬셸->>로컬셸: 마지막 청크 = ace/c+aliFIo 실행
```

- 공격자는 새 요청을 주입할 필요가 없음. **iTerm2가 알아서 요청을 발사**하고, 악성 출력은 답변만 위조하면 됨
  - conductor 상태 기계가 fallback 경로로 넘어가게 유도해서 `run(...)` 명령을 구성하게 만듦
  - 이때 공격자가 조작한 `sshargs` 값이 최종 명령에 섞여 들어감

### PTY 혼동이 마지막 퍼즐

- 정상 상황에서는 iTerm2가 base64로 인코딩한 conductor 명령을 PTY에 쓰면 ssh가 원격으로 포워드
  - 공격 상황에서는 원격 conductor가 실제로는 없음. 그래서 PTY에 쓰여진 base64가 **로컬 셸의 입력**이 됨
  - 대부분의 청크는 쓰레기 명령으로 에러 나고 끝남
- 진짜 트릭은 마지막 청크
  - 공격자는 `sshargs`를 정교하게 골라서 base64 인코딩 후 **마지막 128바이트 청크가 `ace/c+aliFIo`가 되도록** 맞춤
  - 이 문자열은 "conductor 인코딩 경로에서 나올 수 있는 값"이면서 동시에 "유효한 상대 경로"
  - PoC에서는 이 경로에 실행 가능한 스크립트를 미리 심어놓음. cat하는 디렉토리에 `ace/` 폴더가 공존해야 성공함

### 재현과 타임라인

- `genpoc.py`로 PoC 재현 가능
  - 생성 산출물: `ace/c+aliFIo`(실행 가능한 헬퍼)와 `readme.txt`(악성 DCS/OSC 시퀀스)
  - 재현 조건: `ace/c+aliFIo`가 있는 디렉토리에서 `cat readme.txt`를 실행해야 함
- 디스클로저 타임라인
  - 3월 30일 iTerm2에 신고 → 3월 31일 commit `a9e745993c2e2cbb30b884a16617cd5495899f86`로 수정
  - 단, 글 작성 시점 기준으로 **stable 릴리스에는 아직 반영 안 됨**

> [!IMPORTANT]
> iTerm2 stable 버전 업데이트 전까지는 출처 불명의 텍스트 파일을 `cat`하기 전에 한 번 더 생각해볼 것. `less`나 에디터로 여는 것도 이스케이프 시퀀스 렌더링 여부에 따라 위험할 수 있다.

---

## 기술 맥락

이번 버그의 본질은 "같은 채널로 데이터와 제어 신호를 섞으면 벌어지는 전형적 사고"예요. 터미널 이스케이프 시퀀스는 원래 "커서 이동해라", "색 바꿔라" 같은 제어 명령을 문자 스트림 속에 끼워 넣으려고 만들어진 거거든요. 근데 iTerm2가 거기에 SSH integration이라는 "원격 프로토콜"까지 얹어버리니까, 텍스트 출력이 곧 프로토콜 메시지가 되는 구조가 돼버린 거예요.

PTY(pseudoterminal)를 이해해야 왜 이게 터지는지 보여요. PTY는 과거 하드웨어 터미널의 소프트웨어 대체품이에요. 키보드 입력이 들어오는 쪽(master)과 셸이 읽는 쪽(slave)이 짝을 이루는 구조인데, iTerm2가 "원격 conductor에 명령 보내겠다"고 PTY에 쓰면 ssh가 그걸 원격으로 전달해요. 문제는 conductor가 실제로 존재하지 않을 때, 그 바이트들이 그냥 로컬 셸로 들어가버린다는 점이에요.

공격자가 `sshargs`를 base64 충돌로 설계한 건 정말 예술적인 접근이에요. base64 인코딩의 블록 구조를 이용해서 "마지막 128바이트 청크가 특정 문자열이 되도록" 역산한 거거든요. `/`가 들어간 상대 경로까지 만들어내는 걸 보면, 이건 단순한 RCE가 아니라 인코딩 규칙을 파일시스템과 결합한 체인 익스플로잇이에요.

교훈은 분명해요. 터미널 에뮬레이터에 "똑똑한 기능"을 넣을 때마다 공격 표면이 늘어난다는 거죠. VS Code의 link detection, iTerm2의 image protocol, Ghostty의 kitty graphics 같은 것들이 전부 같은 위험을 안고 있어요. 이전에도 AI로 발견된 Vim/Emacs의 유사 버그가 있었고, 이번 사례는 그 흐름의 연장선이에요.

## 핵심 포인트

- iTerm2의 SSH integration은 원격 conductor 스크립트와 터미널 이스케이프 시퀀스(DCS 2000p, OSC 135)로 대화하는 구조인데, 출력 소스를 검증하지 않아 아무 파일이 conductor 행세를 할 수 있다
- 악성 파일은 요청을 주입할 필요가 없다. iTerm2가 getshell, pythonversion을 자동으로 발사하고 공격자는 답변만 위조하면 된다
- sshargs 필드를 base64 충돌로 정교하게 설계해, 최종 명령의 마지막 128바이트 청크가 ace/c+aliFIo라는 유효 경로가 되도록 역산했다
- 로컬 셸이 PTY로 쓰인 base64 청크들을 그대로 입력받아 실행 — PTY 혼동을 이용한 체인
- 3월 30일 신고, 31일 커밋으로 수정됐지만 글 작성 시점 기준 stable 릴리스에는 아직 반영 안 됨

## 인사이트

터미널 에뮬레이터에 '편의 기능'을 추가할 때마다 공격 표면이 늘어난다는 교훈. 출력 신뢰 검증 없는 채널 공유 프로토콜은 시한폭탄이다.