iTerm2 công bố bản cập nhật bảo mật nghiêm trọng

(iterm2.com)

2 điểm bởi GN⁺ 2025-01-03 | 2 bình luận | Chia sẻ qua WhatsApp

iTerm2 3.5.11 là bản phát hành được build vào ngày 2/1/2025; khuyến nghị cập nhật ngay do có bản vá bảo mật nghiêm trọng liên quan đến tích hợp SSH
Phạm vi ảnh hưởng gồm người dùng các phiên bản 3.5.6~3.5.10 có dùng tính năng tích hợp SSH và tất cả phiên bản beta sau 3.5.6
Khi lỗi xảy ra, dữ liệu nhập và xuất sẽ được ghi vào /tmp/framer.txt trên host từ xa, và người dùng khác trên cùng host từ xa có thể đọc được tệp này
Điều kiện xảy ra là sử dụng it2ssh hoặc trong profile, Command là "SSH" và "SSH Integration" được chọn; đồng thời trong đường dẫn tìm kiếm mặc định của host từ xa phải có Python 3.7 trở lên
Người dùng cần nâng cấp lên 3.5.11, sau đó xóa /tmp/framer.txt trên các host từ xa bị ảnh hưởng

Phạm vi ảnh hưởng và điều kiện phát sinh

iTerm2 3.5.11 là bản phát hành có chứa bản vá bảo mật nghiêm trọng và được khuyến nghị cập nhật ngay
Các phiên bản có thể bị ảnh hưởng là những phiên bản sau khi sử dụng tính năng tích hợp SSH
- 3.5.6
- 3.5.7
- 3.5.8
- 3.5.9
- 3.5.10
- Tất cả phiên bản beta sau 3.5.6
Lỗi khiến tính năng tích hợp SSH ghi dữ liệu nhập và xuất vào /tmp/framer.txt trên host từ xa
- Tệp này có thể bị người dùng khác trên host từ xa đọc được
Vấn đề xảy ra khi tất cả các điều kiện sau đều đúng
- Sử dụng lệnh it2ssh
- Hoặc trong Settings > Profiles > General, menu bật lên Command được đặt là "SSH", và trong hộp thoại cài đặt SSH, "SSH Integration" được chọn
  - Các thiết lập "Login Shell", "Command", "Custom Command" không nằm trong điều kiện này
- Trên đường dẫn tìm kiếm mặc định của host từ xa có cài Python 3.7 trở lên

Cập nhật và xác minh

Người dùng cần nâng cấp ngay lên iTerm2 3.5.11
Trên các host từ xa bị ảnh hưởng, cần xóa tệp /tmp/framer.txt
Mã ghi tệp log trong tích hợp SSH đã bị xóa và dự kiến sẽ không được phát hành công khai trở lại
Giá trị SHA-256 của tệp zip như sau
- 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
Có thể dùng https://keybase.io/verify để xác minh tệp zip

2 bình luận

xguru 2025-01-03

Thật bất ngờ khi kiểm tra mới thấy phiên bản của mình là 3.4.3. Gần đây tôi cũng ít dùng terminal nên chẳng để ý gì, vì vậy việc cập nhật cũng không được thực hiện thường xuyên.

GN⁺ 2025-01-03

Ý kiến trên Hacker News

Trông giống một trường hợp gỡ lỗi bằng print() lọt vào production
https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...
- Bản thân code không có gì kỳ lạ; cấu trúc của nó chỉ ghi ra file khi chế độ verbose được bật
  Commit tắt chế độ verbose là commit này, ngay trước khi toàn bộ log framer bị xóa: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
  Commit bật chế độ VERBOSE là ở đây: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
  Có lẽ trong lúc triển khai hoặc gỡ lỗi, họ đã đổi thành VERBOSE=1 rồi quên đổi lại VERBOSE=0 trước khi commit
- Trong phát triển TypeScript, chúng tôi biến console.log thành lỗi lint để không thể merge được; thỉnh thoảng khi có nhu cầu chính đáng thì dùng console.info
  Bản thân việc gỡ lỗi bằng print là ổn và có lúc cần dùng, nhưng nên có cơ chế bảo vệ để không vô tình bỏ sót nó. Đây là một lỗi rất dễ mắc
- Thứ này đã tồn tại suốt 3 năm sao?
Việc do lỗi trong tính năng SSH integration mà input và output bị ghi vào file /tmp/framer.txt trên host từ xa, và file đó có thể bị người dùng khác trên host từ xa đọc được, là khá nghiêm trọng
Những file như vậy cũng có thể còn sót lại trên các máy mà trước đây bạn từng SSH vào nhưng nay không còn quyền truy cập
- Điều kiện xảy ra phải thỏa mãn cả hai
  1. Bạn đã dùng lệnh it2ssh, hoặc trong Settings > Profiles > General, menu bật lên Command được đặt là "SSH" và "SSH Integration" được tích chọn. "Login Shell", "Command", "Custom Command" không thuộc trường hợp này
  2. Trên đường dẫn tìm kiếm mặc định của host từ xa phải có cài Python 3.7 trở lên
- Lỗi này có vẻ gần như không xảy ra. Vì đây là một tính năng cực kỳ đặc thù đến mức 99% người ở đây có lẽ chưa từng nghe tới, chứ chưa nói là dùng
  Tuy nhiên, nếu bạn thuộc kiểu người dùng ssh làm lệnh terminal mặc định thay vì bash hay zsh, rất có khả năng bạn cũng đang dùng nhiều tính năng khác thường trong các ứng dụng khác, nên cần chú ý không chỉ iTerm mà cả các bề mặt tấn công khác
Tôi đã dùng iTerm2 rất tốt cho công việc và cá nhân trong thời gian dài, và sẽ tiếp tục dùng cũng như dự định sẽ quyên góp lại như trước đây
Mỗi khi thấy câu kiểu “tôi vô cùng hối tiếc về sai lầm này và sẽ thực hiện các biện pháp để chuyện như vậy không xảy ra nữa”, tôi luôn hơi thở dài
Điều cốt lõi là biện pháp nào, nhưng tôi cũng không chắc phải làm gì để chuyện này không lặp lại. Có thể tạo một công cụ tự động chạy thử mọi tính năng, bắt các system call để kiểm tra xem có mở hay ghi file không, nhưng với ứng dụng GUI thì có vẻ quá khó đến mức có lẽ chẳng ai thử. Những biện pháp nhẹ hơn thì khó khiến tôi tin là chuyện này sẽ không xảy ra nữa
- Việc fuzzing Chrome/Chromium đã tiêu tốn rất nhiều tiền, nhưng mỗi năm vẫn phát hiện hàng chục lỗ hổng nghiêm trọng. Các sản phẩm lớn khác cũng vậy
  Thực tế thì có vẻ khó để lập trình viên làm tốt hơn thế nhiều, và nếu vậy thì đổ hết trách nhiệm lên một người là không công bằng
- Nhìn vào thông báo bảo mật khá ngắn, có vẻ tác giả muốn công bố các chi tiết liên quan đến sự cố càng nhanh càng tốt
  Tuy nhiên, tôi không nghĩ việc viết ngắn có nghĩa là họ không hiểu mức độ nghiêm trọng của sai lầm. Dù vậy, tôi vẫn kỳ vọng sau này sẽ có một bài blog chuyên sâu xử lý các chi tiết hậu kỳ kiểu này
- Câu này vừa là điều ít tệ nhất có thể nói, đồng thời cũng là điều tốt nhất có thể nói
  Không xin lỗi thì còn tệ hơn, không nói sẽ thực hiện biện pháp ngăn tái diễn cũng tệ hơn. Nếu ngay lúc này đã chuẩn bị sẵn mọi biện pháp thì lại kỳ lạ. Trước hết phải A) sửa lỗi, B) phát hành bản sửa, C) thông báo về lỗi và bản sửa, rồi D) làm postmortem; nếu trộn tất cả lại với nhau thì trông như một cách tiếp cận quy trình lộn xộn
  Nếu tuyên bố có thể ngăn mọi bug hay mọi lần ghi file ngoài ý muốn thì cũng kỳ lạ. Chứng minh rằng chương trình tuyệt đối không bao giờ ghi file là điều bất khả thi
  Điểm khởi đầu tốt là xóa logging SSH như thực tế họ đã làm, rồi điều tra cách tự động xác minh việc truy cập file. Phát triển trên macOS có nhiều công cụ đi trước rất xa so với công cụ chung của hệ sinh thái, nên có thể có những cách như tài liệu kỹ thuật từ thập niên 1990 cho phép chỉ định NSArray các đường dẫn được phép truy cập, hoặc tích hợp dtrace có sẵn trong Instruments. Chạy những thứ đó trong CI và đảm bảo test coverage thì gần như là điều tốt nhất có thể làm
  Có vẻ điểm tranh luận là liệu có đọc “sẽ thực hiện các biện pháp để chuyện như vậy không xảy ra nữa” thành “sẽ thực hiện biện pháp cho đến khi có thể bảo đảm tuyệt đối 100% mãi mãi không bao giờ xảy ra nữa” hay không. Nói với những người trẻ và dễ bị ảnh hưởng: bài blog này rất tốt, và gần như không còn gì để làm tốt hơn ở đây
- Nếu là kỹ sư phần mềm, những chuyện như thế này sẽ tiếp tục xảy ra bất kể quy mô. Rốt cuộc ai cũng sẽ mắc lỗi
  Biện pháp có thể làm là lấy chuyện này làm bài học để cẩn thận hơn khi đi vào đường dẫn đó
- Một bình luận khác đã nói đến cách dùng linter để không cho merge nếu PR có console.log, và tôi cũng nghĩ mình sẽ chọn chính xác cách tiếp cận đó
  Ngăn không cho trạng thái không hợp lệ tồn tại là một nguyên tắc khá hữu ích
Có lẽ phần lớn là sở thích cá nhân, nhưng vào năm 2025 liệu có lý do nào thật sự thuyết phục để dùng iTerm2 thay cho Terminal mặc định của macOS không?
Tôi được khuyên dùng rất nhiều, nhưng vẫn khá thận trọng vì lo về các vấn đề bảo mật và quyền riêng tư như lỗi SSH lần này
- Với tôi, tính năng cốt lõi là Edit > Selection Respects Soft Boundaries. Nó cho phép sao chép văn bản trong các cửa sổ được định nghĩa bên trong terminal, chẳng hạn như trong vùng chia của tmux hoặc emacs, và iTerm nhận ra những thứ như ký tự pipe là ranh giới cửa sổ
  Một điểm nữa là nếu lỡ đóng nhầm tab hoặc cửa sổ, chỉ cần nhấn ⌘z trong vài giây thì cửa sổ sẽ hiện lại như thể chưa từng bị đóng
  Và độ tương phản màu tối thiểu cũng rất tốt. Khi theme màu của terminal và theme màu của chương trình đang chạy kết hợp tệ đến mức không đọc được, iTerm có thể phát hiện và tự động ghi đè bằng màu có độ tương phản cao hơn
  Tuy nhiên đó chỉ là các tính năng cốt lõi đối với tôi. iTerm là một con quái vật cồng kềnh với hàng nghìn tính năng, giống Word. Không phải ai cũng cần tất cả, nhưng cũng không có sự đồng thuận về việc tính năng nào là cần thiết
- Tôi định hỏi liệu Terminal có từng hoàn toàn không có vấn đề bảo mật nào không, rồi thử tìm trang ghi chú phát hành nhưng không tìm thấy
  Tôi cũng tìm terminal trong nhiều ghi chú phát hành macOS nhưng không thấy gì. Có ai biết thông tin này được công bố ở đâu không? Hay là không được công bố?
  [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
- Lý do duy nhất tôi chuyển sang iTerm2 là vì muốn màu terminal thay đổi khi SSH vào host khác
  Tôi muốn khi SSH vào máy công ty thì đổi sang màu xanh dương, còn SSH vào máy ở nhà thì đổi sang màu tím. Tôi đã thử làm với terminal mặc định, nhưng có vấn đề gây nhầm lẫn tùy theo phiên kết thúc như thế nào, và mọi người khuyên rằng iTerm2 giải quyết được chuyện này. Ít nhất trong trường hợp của tôi thì đúng là đã giải quyết được
- Tôi đã dùng Kitty(https://sw.kovidgoyal.net/kitty) làm chính trong vài năm và nó rất tuyệt khi dùng cùng tmux
  Tôi cũng nghe nhiều người nói https://ghostty.org/ tốt, nhưng chưa kịp kiểm tra
  Nói thêm là tôi đã đọc nhầm câu hỏi thành “có lựa chọn thay thế nào”
- Cuối cùng thì còn tùy bạn đã dùng macOS bao lâu và đã hình thành những thói quen vụn vặt cùng các điểm đặc thù nào
  Với tôi, chỉ riêng việc có thể dùng một chế độ toàn màn hình khác với toàn màn hình native của macOS cũng đã đáng giá. Dù có lẽ trên đời chỉ có khoảng bảy người coi điều này là quan trọng
Tôi rất đồng cảm với lập trình viên đang phát triển iTerm với số tiền tương đối ít. Anh ấy đã nhận nhiều chỉ trích hơn mức cần thiết vì tích hợp AI rồi
Đồng thời hiện giờ tôi rất lo không biết mình có nên tiếp tục dùng iTerm hay không
Khi truy cập môi trường HPC, có thể tôi chỉ có quyền truy cập trong thời gian ngắn, phải tự dọn dữ liệu sau khi dùng, và kỳ vọng sẽ không có rò rỉ dữ liệu. Nếu trong một năm qua tôi dùng tích hợp SSH của iTerm khi xử lý dữ liệu nghiên cứu cá nhân thì đã rất rắc rối. Có lẽ tôi đã phải gửi một email ngượng ngùng cho quản trị viên nhờ kiểm tra xem có log không, có phải của tôi không, rồi sau đó phải công khai rằng dữ liệu đã bị rò rỉ
Tôi cũng dùng một số tính năng nâng cao, nhưng giờ tự hỏi liệu có nên dùng gì vượt quá chức năng cơ bản nữa không. Nếu vậy thì có lẽ tôi nên dùng terminal khác. Tôi vẫn chưa tìm được terminal đa nền tảng nào, kể cả Ghostty, có cảm giác native trên MacOS như iTerm
- Rất khuyên dùng wezterm
- Chỉ vì trong suốt thời gian tồn tại khá dài của nó có một vấn đề mà đã có lý do để đổi sang terminal khác sao?
  Nó giống như bỏ cả chiếc xe chỉ vì lốp bị thủng một lần. Xét các ưu điểm và tính năng đang có, iTerm có thể vẫn là lựa chọn tốt nhất
- Nếu là nhà nghiên cứu, việc duy trì môi trường tính toán an toàn không phải là trách nhiệm cá nhân
  Nếu cá nhân phải tự xác minh bảo mật của toàn bộ hệ thống và mọi phần mềm mình dùng, thì tổ chức đó không có bảo mật
  Một quản trị viên hệ thống có năng lực và hiểu biết về bảo mật có thể dễ dàng cấu hình để các tệp được tạo khi truy cập qua SSH không mặc định có quyền cho mọi người đọc. Họ cũng có thể đặt các cơ chế khóa khác để cách ly hoàn toàn tệp người dùng, và thậm chí vô hiệu hóa hẳn các thư mục có thể ghi toàn cục như /tmp/
  Nếu ai đó trách bạn vì đã dùng phần mềm có lỗ hổng bảo mật, bạn nên hỏi ngược lại tại sao hệ thống của họ lại dễ bị tổn thương về bảo mật như vậy
- Tôi dùng Prompt của Panic
Vài năm trước tôi đã báo cáo vấn đề iTerm2 làm rò rỉ lịch sử tìm kiếm nhạy cảm vào tệp cấu hình, và vấn đề đó được sửa nhanh chóng
Nhưng đến giờ vẫn có thể tìm thấy những người vô tình làm rò rỉ lịch sử tìm kiếm trong các kho dotfiles công khai
[1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
[2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...
Đề xuất “đơn giản là đừng dùng iTerm2” thì hơi khó hiểu
Vấn đề kiểu này có thể xảy ra ở bất kỳ dự án nào, và đổi công cụ cũng không mang lại sự bảo vệ có ý nghĩa. Ngược lại, sau những sự cố như thế này, thực hành bảo mật thường còn được siết chặt hơn. Nó giống câu chuyện đùa cũ về việc có sa thải kỹ sư mắc lỗi hay không, khi người quản lý đáp: “Sao lại sa thải? Người đó vừa học được một bài học không thể quên mà”
Nhìn vào lịch sử của iTerm2, có vẻ không thường xuyên có các vấn đề bảo mật nghiêm trọng, và cũng không có vẻ sẽ lặp lại cùng sai lầm. Nếu lặp lại thì khi đó đánh giá lại cũng chưa muộn
Ứng dụng Terminal của macOS đơn giản hơn và ít cập nhật hơn, nên có thể trông như rủi ro thấp hơn. Nhưng vì là mã nguồn đóng nên không thể kiểm toán, và bản thân điều đó cũng có rủi ro. Rốt cuộc công cụ nào cũng có đánh đổi, và nên chọn dựa trên sự cân bằng giữa tính năng cần thiết và rủi ro tiềm ẩn
- Bạn có cho rằng thực hành phát triển ảnh hưởng đến tỷ lệ phát sinh lỗi bảo mật không? Và bạn có cho rằng lịch sử trong quá khứ phản ánh tỷ lệ phát sinh lỗi bảo mật đó không?
  Nhiều người xem cả hai điều này là niềm tin hợp lý. Đây là một góc nhìn tinh tế hơn nhiều so với câu “dự án nào cũng có thể có bug”. Cách nhìn trắng đen như vậy không giúp ích nhiều cho việc đánh giá rủi ro
iTerm2 ngày càng quá phức tạp và cồng kềnh, và có vẻ cũng có quá nhiều vấn đề bảo mật
Đã lâu rồi tôi không tìm terminal emulator mới trên macOS, nhưng có vẻ giờ là lúc nên làm vậy
GNU Screen cũng có vẻ đã chững lại, nên có lẽ cũng phải làm việc đã trì hoãn là chuyển sang tmux
- Gần đây tôi đã thử Ghostty và sau đó đã chuyển hẳn khỏi iTerm2. Nó vừa quen thuộc vừa có độ hoàn thiện cao
- “Quá phức tạp” và “cồng kềnh” là những cách nói vạn năng, nên cần diễn giải cụ thể hơn một chút
  Cá nhân tôi không cảm thấy iTerm2 thuộc bên nào trong hai mô tả đó
- Tôi dùng khá nhiều phần tích hợp tmux của iTerm2. Nó giúp cuộn chuột trong cửa sổ tmux hoạt động tự nhiên
  Tôi vẫn chưa thấy terminal nào khác cung cấp mức hỗ trợ tmux tương đương
- Tôi đã dùng Terminal.app từ bản 10.0 và chưa bao giờ cảm thấy cần thay thế
  Terminal còn thiếu gì đến mức dùng ứng dụng khác sẽ cải thiện việc sử dụng hằng ngày?
- Vẫn còn dùng GNU Screen à? Cả GNU Screen lẫn tmux trước đây đều từng có vấn đề bảo mật, nhưng phía GNU Screen nghiêm trọng hơn, nên tôi đã chuyển
  Zellij là terminal multiplexer viết bằng Rust nên đáng để xem qua. Đặc biệt điểm có thể dễ dàng khám phá các key binding là rất hay. Nó gần với dạng TUI mà tôi từng mong muốn
Cái này chỉ áp dụng cho phần tích hợp SSH, chứ không phải trường hợp chỉ chạy "ssh" trong iTerm đúng không?
Trên các host tôi kết nối bằng ssh thông thường, tôi không tìm thấy file /tmp/framer.txt
- Nhìn release notes thì có vẻ chỉ áp dụng khi dùng tích hợp SSH tích hợp sẵn, và khi server có phiên bản Python tương đối mới
  Điều kiện sau nhiều khả năng cũng đúng với các bản phân phối doanh nghiệp nói chung. Ví dụ RHEL 9 cài sẵn Python 3.9 theo mặc định