iTerm2 쓰면 `cat readme.txt` 한 줄로 RCE가 터진다

• 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 세션 시작됐구나" 하고 정상 워크플로우를 돌리기 시작함

공격 시퀀스

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 릴리스에는 아직 반영 안 됨

기술 맥락

이번 버그의 본질은 "같은 채널로 데이터와 제어 신호를 섞으면 벌어지는 전형적 사고"예요. 터미널 이스케이프 시퀀스는 원래 "커서 이동해라", "색 바꿔라" 같은 제어 명령을 문자 스트림 속에 끼워 넣으려고 만들어진 거거든요. 근데 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의 유사 버그가 있었고, 이번 사례는 그 흐름의 연장선이에요.