iTerm2 중대한 보안 업데이트 발표

• iTerm2 3.5.11은 2025년 1월 2일 빌드된 릴리스로, SSH 통합 관련 중대한 보안 수정 때문에 즉시 업데이트가 권장됨
• 영향 범위는 SSH 통합 기능을 사용한 3.5.6~3.5.10과 3.5.6 이후의 모든 베타 버전 사용자임
• 버그가 발생하면 입력과 출력이 원격 호스트의 /tmp/framer.txt에 기록되고, 같은 원격 호스트의 다른 사용자가 이 파일을 읽을 수 있음
• 조건은 it2ssh 사용 또는 프로필에서 Command가 "SSH"이고 "SSH Integration"이 선택된 경우이며, 원격 호스트 기본 검색 경로에 Python 3.7 이상이 있어야 함
• 사용자는 3.5.11로 업그레이드한 뒤, 영향받은 원격 호스트에서 /tmp/framer.txt를 삭제해야 함

---

영향 범위와 발생 조건

• iTerm2 3.5.11은 중대한 보안 수정을 포함한 릴리스이며 즉시 업데이트가 권장됨
• 영향을 받을 수 있는 버전은 SSH 통합 기능을 사용한 다음 버전임
  • 3.5.6
  • 3.5.7
  • 3.5.8
  • 3.5.9
  • 3.5.10
  • 3.5.6 이후의 모든 베타 버전
• 버그는 SSH 통합 기능에서 입력과 출력을 원격 호스트의 /tmp/framer.txt에 기록하게 만듦
  • 이 파일은 원격 호스트의 다른 사용자가 읽을 수 있을 수 있음
• 문제는 다음 조건이 모두 참일 때 발생함
  • it2ssh 명령을 사용함
  • 또는 Settings > Profiles > General에서 Command 팝업 메뉴가 "SSH"로 설정돼 있고, SSH 설정 대화상자에서 "SSH Integration"이 선택돼 있음
    • "Login Shell", "Command", "Custom Command" 설정은 해당 조건에 포함되지 않음
  • 원격 호스트의 기본 검색 경로에 Python 3.7 이상이 설치돼 있음

업데이트와 검증

• 사용자는 즉시 iTerm2 3.5.11로 업그레이드해야 함
• 영향받은 원격 호스트에서는 /tmp/framer.txt 파일을 삭제해야 함
• SSH 통합에서 로그 파일을 쓰는 코드는 삭제됐고, 다시 공개 릴리스되지 않을 예정임
• zip 파일의 SHA-256 값은 다음과 같음
  • 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
• zip 파일 검증에는 https://keybase.io/verify를 사용할 수 있음

[xguru]

놀라서 확인해보니 제 버전은 3.4.3 이네요. 요즘 터미널 잘 안써서 신경도 안썼더니 업데이트도 잘 안하게 됩니다.

[GN⁺]

Hacker News 의견들

• 프로덕션에 print() 디버깅이 들어간 사례처럼 보임
  https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
  https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

  • 코드 자체가 이상한 건 아니고, verbose 모드가 켜져 있을 때만 파일에 쓰는 구조임
    verbose 모드를 끈 커밋은 전체 framer 로그를 제거하기 직전의 이 커밋임: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
    VERBOSE 모드를 켠 커밋은 이쪽임: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
    아마 구현이나 디버깅 중 VERBOSE=1로 바꿔놓고 커밋 전에 VERBOSE=0으로 되돌리는 걸 잊은 듯함
  • TypeScript 개발에서는 console.log를 린트 오류로 만들어 병합할 수 없게 해뒀고, 가끔 정당한 필요가 있을 때는 console.info를 씀
    print 디버깅 자체는 괜찮고 쓸 때가 있지만, 실수로 남겨두지 않도록 보호 장치를 두는 게 좋음. 정말 하기 쉬운 실수임
  • 이게 3년이나 있었던 건가?

• SSH integration 기능의 버그 때문에 입력과 출력이 원격 호스트의 /tmp/framer.txt 파일에 기록됐고, 그 파일을 원격 호스트의 다른 사용자가 읽을 수도 있었다는 건 꽤 심각함
  예전에 SSH로 접속했지만 이제는 접근 권한이 없는 머신에도 이런 파일이 남아 있을 수도 있음

  • 발생 조건은 둘 다 만족해야 함
    1. it2ssh 명령을 썼거나, Settings > Profiles > General에서 Command 팝업 메뉴가 "SSH"로 설정되어 있고 "SSH Integration"이 체크되어 있었을 때임. "Login Shell", "Command", "Custom Command"는 해당하지 않음
    2. 원격 호스트의 기본 검색 경로에 Python 3.7 이상이 설치되어 있어야 함
  • 이 버그는 거의 발생하지 않을 듯함. 여기 있는 99%가 들어본 적도, 써본 적도 없을 만큼 매우 특수한 기능이기 때문임
    다만 bash나 zsh 대신 ssh를 기본 터미널 명령으로 쓰는 유형이라면, 다른 앱에서도 특이한 기능을 많이 쓰고 있을 가능성이 커서 iTerm만이 아니라 다른 공격 표면도 신경 써야 함

• iTerm2는 오랫동안 일과 개인 용도로 잘 써왔고, 앞으로도 계속 쓰면서 예전에 그랬듯 다시 기부할 생각임

• “이 실수를 깊이 후회하며 다시는 이런 일이 일어나지 않도록 조치를 취하겠다” 같은 문장을 보면 늘 한숨이 조금 나옴
  어떤 조치인지가 핵심인데, 이런 일이 다시 안 생기도록 무엇을 해야 할지도 잘 모르겠음. 모든 기능을 실행해보고 시스템 호출을 캡처해서 파일을 열거나 쓰지 않는지 확인하는 자동화 도구를 만들 수도 있겠지만, GUI 앱에서는 너무 어려워 보여 시도조차 안 할 것 같음. 그보다 덜한 조치로는 다시 안 생긴다고 보장하기 어렵게 느껴짐

  • Chrome/Chromium 퍼징에는 막대한 돈이 들어갔지만 여전히 매년 심각한 취약점이 수십 개씩 발견됨. 다른 주요 제품도 마찬가지임
    현실적으로 프로그래머가 이보다 훨씬 더 잘하기는 어려워 보이고, 그렇다면 이 한 사람에게 전부 책임을 묻는 건 불공평함
  • 보안 공지가 짧은 걸 보면 작성자는 사건과 관련된 세부사항을 최대한 빨리 공개하려 했던 것 같음
    다만 짧게 썼다고 해서 실수의 크기를 이해하지 못한다는 뜻은 아니라고 봄. 그래도 이런 종류의 후속 세부사항을 다루는 심층 블로그 글은 나중에 나와야 한다고 기대함
  • 이 문장은 말할 수 있는 것 중 가장 덜 나쁜 말이자, 동시에 가장 좋은 말이기도 함
    사과하지 않으면 더 나쁘고, 재발 방지 조치를 하겠다고 하지 않아도 더 나쁨. 지금 당장 모든 조치가 준비되어 있다면 오히려 이상함. 우선 A) 버그를 고치고 B) 수정판을 배포하고 C) 버그와 수정 배포를 알린 뒤 D) 사후 분석을 해야지, 이걸 한데 섞으면 절차가 흐트러진 접근처럼 보임
    모든 버그나 모든 의도치 않은 파일 쓰기를 막을 수 있다고 주장해도 이상함. 파일에 절대 쓰지 않는다고 증명하는 건 불가능함
    좋은 출발점은 실제로 한 것처럼 SSH 로깅을 삭제하고, 파일 접근 여부를 검증할 자동화 방법을 조사하는 것임. macOS 개발에는 생태계 공통 도구보다 훨씬 앞선 도구가 많아서, 접근 허용 경로의 NSArray를 지정하는 1990년대 기술 문서나 Instruments의 내장 dtrace 통합 같은 방법이 있을 수도 있음. 이를 CI에서 돌리고 테스트 커버리지를 확보하면 할 수 있는 최선에 가까움
    “다시는 이런 일이 일어나지 않도록 조치를 취하겠다”를 “절대 100% 영원히 다시는 안 생긴다고 보장할 때까지 조치하겠다”로 읽느냐가 쟁점인 듯함. 젊고 영향받기 쉬운 사람들에게 말하자면, 이 블로그 글은 훌륭하고 여기서 더 잘할 수 있는 건 거의 없음
  • 소프트웨어 엔지니어라면 이런 일은 규모와 상관없이 계속 생김. 결국 실수하게 되어 있음
    할 수 있는 조치는 이 일을 교훈 삼아 해당 경로에 들어갈 때 더 조심하게 만드는 것임
  • 다른 댓글에서 PR에 console.log가 있으면 병합할 수 없게 린터를 쓰는 방식을 말했는데, 나도 정확히 그런 접근을 택할 것 같음
    유효하지 않은 상태가 존재하지 못하게 막는 건 꽤 유용한 원칙임

• 대체로 개인 취향이겠지만, 2025년에 macOS 기본 Terminal 대신 iTerm2를 쓸 강하게 설득력 있는 이유가 있을까?
  추천은 많이 받았지만, 이번 SSH 버그 같은 보안·프라이버시 이슈가 걱정돼 조심스러웠음

  • 내게 핵심 기능은 Edit > Selection Respects Soft Boundaries임. 터미널 안에서 정의된 창, 예를 들어 tmux나 emacs 분할 영역 안의 텍스트를 복사할 수 있게 해주고, iTerm이 파이프 문자 같은 것을 창 경계로 알아차림
    또 하나는 실수로 탭이나 창을 닫아도 몇 초 안에 ⌘z를 누르면 닫지 않았던 것처럼 창이 다시 나타난다는 점임
    그리고 최소 색상 대비도 좋음. 터미널 색상 테마와 실행 중인 프로그램의 색상 테마가 안 좋게 섞여 읽을 수 없게 되면, iTerm이 이를 감지해 자동으로 더 높은 대비의 색으로 덮어쓸 수 있음
    다만 이건 내 핵심 기능일 뿐임. iTerm은 Word처럼 수천 개 기능을 가진 비대한 괴물임. 모두가 전부 필요로 하진 않지만, 어떤 기능이 필요한지에 대해서도 합의가 없음
  • Terminal에 보안 이슈가 전혀 없었는지 물어보려다가 릴리스 노트 페이지를 찾으려 했는데 못 찾았음
    macOS 릴리스 노트 여러 개에서도 terminal로 검색했지만 아무것도 못 찾았음. 이 정보가 어디에 공개되는지 아는 사람이 있나? 공개되지 않는 건가?
    [1] https://developer.apple.com/documentation/macos-release-note...
    [2] https://support.apple.com/en-us/120283
    [3] https://support.apple.com/en-in/109035
    [4] https://support.apple.com/en-us/106337
  • iTerm2로 바꾼 유일한 이유는 SSH로 다른 호스트에 접속할 때 터미널 색상이 바뀌길 원했기 때문임
    회사 머신에 SSH하면 파란색, 집 머신에 SSH하면 보라색으로 바뀌게 하고 싶었음. 기본 터미널에서도 해보려 했지만 세션이 어떻게 끝났는지에 따라 헷갈리는 문제가 있었고, 사람들이 iTerm2가 이걸 해결한다고 추천했음. 적어도 내 경우에는 실제로 해결됨
  • Kitty(https://sw.kovidgoyal.net/kitty)를 몇 년째 주력으로 쓰고 있고 tmux와 함께 쓰면 훌륭함
    https://ghostty.org/도 좋다는 말을 많이 들었지만 아직 확인해보진 못했음
    덧붙이면, 질문을 “대안이 뭐가 있나”로 잘못 읽었음
  • 결국 macOS를 얼마나 오래 써왔고 어떤 자잘한 습관과 특이점을 갖게 됐느냐에 달려 있음
    내게는 네이티브 macOS 전체 화면과 다른 방식의 전체 화면 모드를 쓸 수 있는 것만으로도 가치가 있음. 다만 이걸 중요하게 여기는 사람이 세상에 일곱 명쯤밖에 없을 수도 있음

• iTerm을 비교적 적은 돈으로 개발하는 개발자에게 깊이 공감함. 이미 AI 통합 때문에 필요 이상으로 많은 비판도 받았음
  동시에 지금은 내가 iTerm을 계속 써도 되는지 크게 걱정됨
  HPC 환경에 접속할 때는 짧은 기간만 접근 권한이 있을 수 있고, 사용 후 데이터를 직접 정리해야 하며 데이터 유출이 없을 거라고 기대함. 지난 1년 동안 개인정보 연구 데이터를 다루면서 iTerm의 SSH 통합을 썼다면 곤란해졌을 것임. 관리자에게 로그가 있는지, 내 것인지 확인해달라고 민망한 메일을 보내고 이어서 데이터가 유출됐다고 공개해야 했을 수도 있음
  고급 기능도 일부 쓰지만, 이제는 기본 기능 이상을 써도 되는지 의문이 듦. 그렇다면 차라리 다른 터미널을 써도 될 것 같음. Ghostty를 포함해 iTerm만큼 MacOS에서 네이티브처럼 느껴지는 크로스플랫폼 터미널은 아직 못 찾았음

  • wezterm을 강력히 추천함
  • 지금까지 존재한 긴 시간 동안 이슈가 하나 있었다고 다른 터미널로 바꿀 이유가 있나?
    타이어가 한 번 펑크 났다고 차를 버리는 것과 비슷함. 가진 장점과 기능을 고려하면 iTerm이 여전히 가장 좋은 선택일 수도 있음
  • 연구자라면 안전한 컴퓨팅 환경을 유지하는 건 개인 책임이 아님
    개인이 전체 시스템과 사용하는 모든 소프트웨어의 보안을 직접 검증해야 한다면, 그 조직에는 보안이 없는 것임
    보안 지식이 있는 유능한 시스템 관리자는 SSH로 접속해 만든 파일이 기본적으로 모두가 읽을 수 있는 권한을 갖지 않도록 쉽게 설정할 수 있음. 사용자 파일을 완전히 격리하는 다른 잠금 장치도 둘 수 있고, /tmp/ 같은 전역 쓰기 가능 폴더를 아예 비활성화할 수도 있음
    누군가 보안 취약한 소프트웨어를 썼다고 뭐라 하면, 왜 그들의 시스템이 그렇게 보안에 취약한지 되물어야 함
  • Panic의 Prompt를 씀

• 몇 년 전 iTerm2가 민감한 검색 기록을 설정 파일로 유출하는 문제를 보고했고, 그 문제는 빠르게 수정됐음
  하지만 지금도 공개 dotfiles 저장소에서 검색 기록을 의도치 않게 유출하는 사람들을 찾을 수 있음
  [1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
  [2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...

• “그냥 iTerm2를 쓰지 말라”는 제안은 조금 이해가 안 됨
  이런 유형의 문제는 어떤 프로젝트에서도 생길 수 있고, 도구를 바꾼다고 의미 있는 보호가 되지는 않음. 오히려 이런 사고 이후 보안 관행이 더 강해지는 경우가 많음. 실수한 엔지니어를 해고하겠냐는 오래된 농담에서, 매니저가 “왜 해고하지? 잊지 못할 교훈을 막 배웠는데”라고 답하는 것과 비슷함
  iTerm2의 이력을 보면 치명적인 보안 이슈가 자주 있었던 것 같지는 않고, 같은 실수를 반복할 것 같지도 않음. 반복된다면 그때 다시 평가하면 됨
  macOS Terminal 앱은 더 단순하고 업데이트가 덜 잦아서 낮은 위험처럼 보일 수 있음. 하지만 비공개 소스라 감사를 할 수 없고, 그 자체의 위험도 있음. 결국 모든 도구에는 트레이드오프가 있고, 필요한 기능과 잠재 위험의 균형으로 선택해야 함

  • 개발 관행이 보안 버그 발생률에 영향을 준다고 보나? 그리고 과거 이력이 그 보안 버그 발생률을 반영한다고 보나?
    많은 사람이 이 두 가지를 합리적인 믿음으로 갖고 있음. “모든 프로젝트에는 버그가 있을 수 있다”는 말보다 훨씬 더 미묘한 관점임. 그런 흑백식 관점은 위험 평가에 별 도움이 안 됨

• iTerm2가 점점 너무 복잡하고 비대해졌고, 보안 이슈도 너무 많아 보임
  macOS에서 새 터미널 에뮬레이터를 알아본 지 오래됐지만 이제는 그럴 때가 된 듯함
  GNU Screen도 정체된 것 같으니 이제 tmux로 넘어가는 것도 미뤄둔 일을 해야겠음

  • 최근 Ghostty를 써봤고 이후 iTerm2에서 완전히 넘어왔음. 익숙하면서도 완성도가 높음
  • “너무 복잡하다”와 “비대하다”는 만능 표현이라, 좀 더 구체적으로 풀어볼 필요가 있음
    개인적으로 iTerm2가 둘 중 어느 쪽에도 해당한다고 느끼지 않음
  • iTerm2의 tmux 통합을 많이 쓰는 편임. tmux 창에서 마우스 스크롤이 자연스럽게 동작하게 해줌
    같은 수준의 tmux 지원을 제공하는 다른 터미널은 아직 못 봤음
  • 10.0부터 Terminal.app을 써왔고, 대체해야겠다고 느낀 적이 없음
    다른 앱을 쓰면 일상 사용이 개선될 만큼 Terminal에 부족한 게 뭔가?
  • 아직도 GNU Screen을 쓰나? GNU Screen과 tmux 모두 과거에 보안 이슈가 있었지만 GNU Screen 쪽이 더 심했고, 그래서 나는 갈아탔음
    Zellij는 Rust로 만든 터미널 멀티플렉서라 살펴볼 만함. 특히 키 바인딩을 쉽게 발견할 수 있는 점이 아주 좋음. TUI에서 꿈꾸던 형태에 가까움

• 이건 SSH 통합에만 해당하고, iTerm에서 그냥 "ssh"를 실행한 경우는 아닌가?
  내가 평범한 ssh로 접속한 호스트들에서는 /tmp/framer.txt 파일을 못 찾았음

  • 릴리스 노트를 보면 내장 SSH 통합을 사용했고, 서버에 비교적 최근 버전의 Python이 있을 때만 해당하는 듯함
    후자 조건은 엔터프라이즈 배포판에서도 대체로 맞을 가능성이 큼. 예를 들어 RHEL 9에는 Python 3.9가 기본 설치됨