iTerm2 kritik güvenlik güncellemesini duyurdu

 (iterm2.com)
2 puan yazan GN⁺ 2025-01-03 | 2 yorum | WhatsApp'ta paylaş
  • iTerm2 3.5.11, 2 Ocak 2025’te derlenen bir sürüm ve SSH entegrasyonuyla ilgili kritik bir güvenlik düzeltmesi nedeniyle hemen güncellenmesi öneriliyor
  • Etki alanı, SSH entegrasyonu özelliğini kullanan 3.5.6~3.5.10 sürümleri ile 3.5.6 sonrasındaki tüm beta sürümlerinin kullanıcılarını kapsıyor
  • Hata oluştuğunda giriş ve çıkışlar uzak ana makinedeki /tmp/framer.txt dosyasına kaydediliyor ve aynı uzak ana makinedeki diğer kullanıcılar bu dosyayı okuyabiliyor
  • Koşullar, it2ssh kullanılması veya profilde Command ayarının "SSH" olması ve "SSH Integration" seçeneğinin seçilmiş olması; ayrıca uzak ana makinenin varsayılan arama yolunda Python 3.7 veya üstü bulunması
  • Kullanıcılar 3.5.11’e yükselttikten sonra etkilenen uzak ana makinelerde /tmp/framer.txt dosyasını silmeli

Etki alanı ve oluşma koşulları

  • iTerm2 3.5.11, kritik bir güvenlik düzeltmesi içeren bir sürüm ve hemen güncellenmesi öneriliyor
  • Etkilenebilecek sürümler, SSH entegrasyonu özelliğini kullanan şu sürümler:
    • 3.5.6
    • 3.5.7
    • 3.5.8
    • 3.5.9
    • 3.5.10
    • 3.5.6 sonrasındaki tüm beta sürümleri
  • Hata, SSH entegrasyonu özelliğinde giriş ve çıkışların uzak ana makinedeki /tmp/framer.txt dosyasına yazılmasına neden oluyor
    • Bu dosya, uzak ana makinedeki diğer kullanıcılar tarafından okunabiliyor olabilir
  • Sorun, aşağıdaki koşulların tümü doğru olduğunda ortaya çıkıyor
    • it2ssh komutu kullanılıyor
    • veya Settings > Profiles > General içinde Command açılır menüsü "SSH" olarak ayarlanmış ve SSH ayarları iletişim kutusunda "SSH Integration" seçilmiş
      • "Login Shell", "Command", "Custom Command" ayarları bu koşula dahil değil
    • Uzak ana makinenin varsayılan arama yolunda Python 3.7 veya üstü kurulu

Güncelleme ve doğrulama

  • Kullanıcılar hemen iTerm2 3.5.11 sürümüne yükseltmeli
  • Etkilenen uzak ana makinelerde /tmp/framer.txt dosyası silinmeli
  • SSH entegrasyonunda log dosyası yazan kod kaldırıldı ve yeniden herkese açık bir sürümde yayınlanmayacak
  • zip dosyasının SHA-256 değeri şöyle:
    • 655e32b4a9466104f1b0d8847e852515bc332bdf434801762e01b9625caa43e2
  • zip dosyasını doğrulamak için https://keybase.io/verify kullanılabilir

İlgili okumalar

2 yorum

 
xguru 2025-01-03

Şaşırıp kontrol ettim de sürümüm 3.4.3 çıktı. Son zamanlarda terminali çok kullanmadığım için de ilgilenmedim, bu yüzden güncellemeler de pek düzenli yapılmıyor.
 
GN⁺ 2025-01-03
Hacker News yorumları

  • Üretime print() ile debug konmuş bir vaka gibi görünüyor
    https://github.com/gnachman/iTerm2/commit/63ec2bb0b95078a97a...
    https://github.com/gnachman/iTerm2/blame/5db0f74bf647f6d53ea...

    • Kodun kendisi tuhaf değil; yalnızca verbose modu açıkken dosyaya yazan bir yapı
      verbose modunu kapatan commit, tüm framer loglarını kaldırmadan hemen önceki şu commit: https://github.com/gnachman/iTerm2/commit/014ba7ec40fc790f65...
      VERBOSE modunu açan commit ise bu: https://github.com/gnachman/iTerm2/commit/5db0f74bf647f6d53e...
      Muhtemelen uygulama ya da debug sırasında VERBOSE=1 yapıp commit’ten önce VERBOSE=0’a geri döndürmeyi unuttu
    • TypeScript geliştirmede console.log’u lint hatası yapıp merge edilemez hale getirdik; ara sıra meşru bir ihtiyaç olduğunda console.info kullanıyoruz
      print ile debug yapmanın kendisi sorun değil ve gerekli olduğu zamanlar var; ama yanlışlıkla geride bırakılmaması için koruma koymak iyi olur. Gerçekten çok kolay yapılan bir hata
    • Bu 3 yıldır mı duruyordu?

  • SSH integration özelliğindeki bir bug yüzünden giriş ve çıkışın uzak host’taki /tmp/framer.txt dosyasına kaydedilmesi ve bu dosyanın uzak host’taki diğer kullanıcılar tarafından okunabilmesi oldukça ciddi
    Eskiden SSH ile bağlanılan ama artık erişim hakkı olmayan makinelerde de böyle dosyalar kalmış olabilir

    • Bunun olması için iki koşulun da sağlanması gerekiyor
      1. it2ssh komutu kullanılmış olmalı ya da Settings > Profiles > General altında Command açılır menüsü "SSH" olarak ayarlanmış ve "SSH Integration" işaretlenmiş olmalı. "Login Shell", "Command", "Custom Command" buna dahil değil
      2. Uzak host’un varsayılan arama yolunda Python 3.7 veya üzeri kurulu olmalı
    • Bu bug muhtemelen çok nadir tetiklenir. Çünkü buradakilerin %99’unun adını bile duymadığı, kullanmadığı çok özel bir özellik
      Yine de bash veya zsh yerine varsayılan terminal komutu olarak ssh kullanan biriyseniz, başka uygulamalarda da birçok sıra dışı özellik kullanıyor olma ihtimaliniz yüksek; bu yüzden yalnızca iTerm’i değil, diğer saldırı yüzeylerini de dikkate almalısınız

  • iTerm2’yi uzun süredir iş ve kişisel kullanım için memnuniyetle kullanıyorum; kullanmaya devam edeceğim ve eskiden yaptığım gibi tekrar bağış yapmayı düşünüyorum

  • “Bu hatadan derin pişmanlık duyuyoruz ve bunun bir daha yaşanmaması için önlemler alacağız” gibi cümleleri görünce her zaman biraz iç geçiriyorum
    Asıl mesele hangi önlemler olduğu; böyle bir şeyin tekrar yaşanmaması için ne yapılması gerektiğini de pek bilmiyorum. Tüm özellikleri çalıştırıp sistem çağrılarını yakalayarak dosya açıp yazmadığını kontrol eden otomatik bir araç yapılabilir belki, ama GUI uygulamalarında bu o kadar zor görünüyor ki denemeye bile kalkışılmayacak gibi. Bundan daha hafif önlemlerle tekrar olmayacağını garanti etmek zor geliyor

    • Chrome/Chromium fuzzing’ine muazzam para harcandı ama hâlâ her yıl onlarca ciddi açık bulunuyor. Diğer büyük ürünlerde de durum aynı
      Gerçekçi olarak programcıların bundan çok daha iyisini yapması zor görünüyor; o halde tüm sorumluluğu bu tek kişiye yüklemek adil değil
    • Güvenlik duyurusunun kısa olmasına bakılırsa yazar, olayla ilgili ayrıntıları mümkün olduğunca hızlı açıklamak istemiş gibi
      Ancak kısa yazılmış olması, hatanın büyüklüğünü anlamadığı anlamına gelmez bence. Yine de bu tür takip ayrıntılarını ele alan derinlemesine bir blog yazısının daha sonra gelmesini beklerim
    • Bu cümle söylenebilecek en az kötü şey ve aynı zamanda en iyi şey
      Özür dilemese daha kötü olurdu; tekrarını önlemek için önlem alacağını söylemese de daha kötü olurdu. Şu anda tüm önlemler hazır olsaydı bu daha da tuhaf olurdu. Önce A) bug’ı düzeltmek, B) düzeltmeyi yayınlamak, C) bug’ı ve düzeltme sürümünü duyurmak, ardından D) post-mortem yapmak gerekir; bunları birbirine karıştırmak süreci dağınık bir yaklaşım gibi gösterir
      Tüm bug’ları ya da tüm istenmeyen dosya yazmalarını engelleyebileceğini iddia etmek de tuhaf olur. Dosyaya asla yazılmadığını kanıtlamak imkânsız
      İyi bir başlangıç noktası, gerçekten yaptıkları gibi SSH loglamasını silmek ve dosya erişimini doğrulayacak otomasyon yöntemlerini araştırmak. macOS geliştirmede, ekosistemin ortak araçlarının çok ilerisinde birçok araç var; erişime izin verilen yolların NSArray’ini belirtmeye dair 1990’lardan kalma teknik dokümanlar ya da Instruments’ın yerleşik dtrace entegrasyonu gibi yöntemler olabilir. Bunu CI’da çalıştırıp test kapsamı sağlamak, yapılabileceklerin en iyisine yakın olur
      Tartışma noktası, “bunun bir daha yaşanmaması için önlemler alacağız” ifadesini “%100 kesinlikle ve sonsuza kadar bir daha olmayacağını garanti edene kadar önlem alacağız” diye okuyup okumamak gibi görünüyor. Genç ve kolay etkilenen insanlara söylemek gerekirse, bu blog yazısı gayet iyi ve burada daha iyi yapılabilecek pek bir şey yok
    • Yazılım mühendisiyseniz, ölçek ne olursa olsun böyle şeyler yaşanmaya devam eder. Sonunda hata yaparsınız
      Alınabilecek önlem, bu olaydan ders çıkarıp o yola girerken daha dikkatli olmayı sağlamaktır
    • Başka bir yorumda, PR’da console.log varsa merge edilememesi için linter kullanmaktan bahsedilmişti; ben de tam olarak böyle bir yaklaşım seçerdim
      Geçersiz bir durumun var olmasını engellemek oldukça faydalı bir ilke

  • Büyük ölçüde kişisel tercih meselesi olabilir ama 2025’te macOS’un varsayılan Terminal’i yerine iTerm2 kullanmak için gerçekten güçlü ve ikna edici bir neden var mı?
    Çok önerildi ama bu SSH hatası gibi güvenlik ve gizlilik sorunları beni endişelendirdiği için temkinliydim

    • Benim için kilit özellik Edit > Selection Respects Soft Boundaries. Terminal içinde tanımlı pencerelerde, örneğin tmux ya da emacs bölmelerindeki metni kopyalamayı sağlıyor; iTerm de pipe karakteri gibi şeyleri pencere sınırı olarak fark ediyor
      Bir diğeri de yanlışlıkla bir sekmeyi ya da pencereyi kapatsam bile birkaç saniye içinde ⌘z’ye basınca pencerenin hiç kapatılmamış gibi geri gelmesi
      Ayrıca minimum renk kontrastı da iyi. Terminal renk temasıyla çalışan programın renk teması kötü biçimde karışıp okunamaz hâle geldiğinde, iTerm bunu algılayıp otomatik olarak daha yüksek kontrastlı renklerle üzerine yazabiliyor
      Ama bunlar sadece benim kilit özelliklerim. iTerm, Word gibi binlerce özelliği olan şişkin bir canavar. Herkesin hepsine ihtiyacı yok ama hangi özelliklere ihtiyaç olduğu konusunda da bir uzlaşı yok
    • Terminal’de hiç güvenlik sorunu olup olmadığını soracaktım; sürüm notları sayfasını bulmaya çalıştım ama bulamadım
      Birkaç macOS sürüm notunda da terminal diye aradım ama hiçbir şey bulamadım. Bu bilginin nerede yayımlandığını bilen var mı? Yoksa yayımlanmıyor mu?
      [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’ye geçmemin tek nedeni, SSH ile başka bir host’a bağlandığımda terminal renginin değişmesini istememdi
      Şirket makinesine SSH yapınca mavi, ev makinesine SSH yapınca mor olmasını istiyordum. Varsayılan Terminal’de de denemiştim ama oturumun nasıl bittiğine göre kafa karıştıran bir sorun vardı; insanlar iTerm2’nin bunu çözdüğünü söyledi. En azından benim durumumda gerçekten çözdü
    • Kitty’yi (https://sw.kovidgoyal.net/kitty) birkaç yıldır ana terminalim olarak kullanıyorum ve tmux ile birlikte harika çalışıyor
      https://ghostty.org/ için de çok iyi şeyler duydum ama henüz deneme fırsatım olmadı
      Bu arada, soruyu yanlışlıkla “alternatifler neler” diye okumuşum
    • Sonuçta macOS’u ne kadar uzun süredir kullandığınıza ve hangi ufak alışkanlıklar ile tuhaflıklara sahip olduğunuza bağlı
      Benim için yerel macOS tam ekranından farklı bir tam ekran modunu kullanabilmek bile değerli. Gerçi dünyada bunu önemseyen yaklaşık yedi kişi olabilir

  • iTerm’i görece az parayla geliştiren geliştiriciyle derinden empati kuruyorum. Yapay zeka entegrasyonu yüzünden zaten gereğinden fazla eleştiri aldı
    Aynı zamanda şu an iTerm’i kullanmaya devam edip edemeyeceğim konusunda ciddi biçimde endişeliyim
    HPC ortamlarına bağlanırken erişim yetkim sadece kısa süreli olabilir, kullanım sonrası verileri bizzat temizlemem gerekebilir ve veri sızıntısı olmayacağı beklentisi vardır. Geçen yıl boyunca kişisel veri içeren araştırma verileriyle çalışırken iTerm’in SSH entegrasyonunu kullansaydım zor durumda kalırdım. Yöneticilere log olup olmadığını ve bana ait olup olmadığını kontrol etmelerini isteyen mahcup bir e-posta göndermek, ardından da verinin sızdığını açıklamak zorunda kalabilirdim
    Bazı gelişmiş özellikleri de kullanıyorum ama artık temel işlevlerin ötesini kullanmanın doğru olup olmadığını sorguluyorum. Öyleyse başka bir terminal kullanmak daha iyi olabilir. Ghostty dahil, MacOS’ta iTerm kadar yerel hissettiren bir çapraz platform terminali henüz bulamadım

    • wezterm’i şiddetle tavsiye ederim
    • Bunca uzun süredir var olup da tek bir sorun yaşandı diye başka bir terminale geçmek için neden var mı?
      Bir lastik bir kez patladı diye arabayı çöpe atmaya benziyor. Sahip olduğu avantajlar ve özellikler düşünüldüğünde iTerm hâlâ en iyi seçenek olabilir
    • Bir araştırmacıysanız güvenli bir bilişim ortamını sürdürmek kişisel sorumluluk değildir
      Bir kişinin tüm sistemin ve kullandığı tüm yazılımların güvenliğini bizzat doğrulaması gerekiyorsa, o kurumda güvenlik yok demektir
      Güvenlik bilgisi olan yetkin bir sistem yöneticisi, SSH ile bağlanıp oluşturulan dosyaların varsayılan olarak herkes tarafından okunabilir yetkilere sahip olmamasını kolayca ayarlayabilir. Kullanıcı dosyalarını tamamen izole eden başka kilitler de koyabilir ve /tmp/ gibi küresel olarak yazılabilir klasörleri tamamen devre dışı bırakabilir
      Biri güvenlik açığı olan bir yazılım kullandınız diye sizi eleştirirse, onların sisteminin neden bu kadar güvenliğe açık olduğunu sormalısınız
    • Panic’in Prompt’unu kullanıyorum

  • Birkaç yıl önce iTerm2’nin hassas arama geçmişini ayar dosyasına sızdırması sorununu bildirmiştim ve bu sorun hızlıca düzeltilmişti
    Ama bugün bile herkese açık dotfiles depolarında arama geçmişini istemeden sızdıran insanlar bulmak mümkün
    [1]: https://gitlab.com/gnachman/iterm2/-/issues/8491
    [2]: https://github.com/search?q=NoSyncSearchHistory+path%3A*.pli...

  • “iTerm2’yi hiç kullanmayın” önerisini pek anlayamıyorum
    Bu tür sorunlar herhangi bir projede ortaya çıkabilir; aracı değiştirmek anlamlı bir koruma sağlamaz. Hatta böyle olaylardan sonra güvenlik uygulamalarının daha da güçlendiği sık görülür. Hata yapan mühendisi kovup kovmayacağına dair eski şakada, yöneticinin “Neden kovayım? Az önce unutamayacağı bir ders aldı” diye cevap vermesine benzer
    iTerm2’nin geçmişine bakınca kritik güvenlik sorunlarının sık yaşandığı izlenimi vermiyor; aynı hatayı tekrarlayacak gibi de görünmüyor. Tekrarlanırsa o zaman yeniden değerlendiririz
    macOS Terminal uygulaması daha basit ve daha seyrek güncellendiği için daha düşük riskli görünebilir. Ama kapalı kaynak olduğu için denetlenemez ve bunun da kendi riski vardır. Sonuçta her araçta ödünleşimler var; seçim, ihtiyaç duyulan özelliklerle olası riskler arasındaki dengeye göre yapılmalı

    • Geliştirme pratiklerinin güvenlik hatası oranını etkilediğini düşünüyor musunuz? Peki geçmiş sicilin bu güvenlik hatası oranını yansıttığını düşünüyor musunuz?
      Pek çok kişi bu iki inanca makul şekilde sahip. “Her projede hata olabilir” demekten çok daha nüanslı bir bakış açısı. Böyle siyah-beyaz bir yaklaşım risk değerlendirmesinde pek işe yaramaz

  • iTerm2 giderek fazla karmaşık ve şişkin hale geldi; güvenlik sorunları da fazla gibi görünüyor
    macOS’te yeni bir terminal emülatörü bakmayalı uzun zaman oldu ama artık zamanı gelmiş gibi
    GNU Screen de durmuş gibi göründüğünden artık tmux’a geçmeyi ertelediğim işi yapmalıyım

    • Yakın zamanda Ghostty’yi denedim ve sonrasında iTerm2’den tamamen geçtim. Tanıdık geliyor, aynı zamanda da olgun bir ürün hissi veriyor
    • “Fazla karmaşık” ve “şişkin” her derde deva ifadeler; biraz daha somutlaştırmak gerekir
      Şahsen iTerm2’nin bu ikisinden birine girdiğini düşünmüyorum
    • iTerm2’nin tmux entegrasyonunu çok kullanıyorum. tmux penceresinde fareyle kaydırmanın doğal çalışmasını sağlıyor
      Aynı düzeyde tmux desteği sunan başka bir terminal henüz görmedim
    • 10.0’dan beri Terminal.app kullanıyorum ve değiştirmem gerektiğini hiç hissetmedim
      Başka bir uygulama kullanınca günlük kullanımı iyileştirecek şekilde Terminal’de eksik olan ne var?
    • Hâlâ GNU Screen mi kullanıyorsunuz? Hem GNU Screen’in hem de tmux’ın geçmişte güvenlik sorunları oldu ama GNU Screen tarafı daha ciddiydi; ben de bu yüzden geçtim
      Zellij, Rust ile yazılmış bir terminal çoklayıcısı; göz atmaya değer. Özellikle tuş kısayollarının kolay keşfedilebilmesi çok iyi. TUI’de hayalini kurduğum şeye yakın

  • Bu yalnızca SSH entegrasyonu için geçerli, iTerm’de yalnızca "ssh" çalıştırılan durum için değil mi?
    Normal ssh ile bağlandığım host’larda /tmp/framer.txt dosyasını bulamadım

    • Sürüm notlarına bakılırsa yerleşik SSH entegrasyonu kullanıldığında ve sunucuda görece yeni bir Python sürümü olduğunda geçerli gibi görünüyor
      İkinci koşulun kurumsal dağıtımlarda da çoğunlukla sağlanması muhtemel. Örneğin RHEL 9’da Python 3.9 varsayılan olarak kurulu geliyor