Siber güvenlik

OpenSSH 10.6 güvenlik nedenleriyle sıkıştırmanın bir bölümünü devre dışı bırakıyor ve bazı kullanıcı adlarını reddediyor

OpenSSH 10.6, oturumun SSH kanalları arasında paylaşılan sıkıştırmadaki LZ77 bileşenini, gizli verileri kurtarmak için kullanılabileceğinin kanıtlanmasının ardından devre dışı bırakıyor. Ayrıca shell komutu enjeksiyonu risklerini azaltmak için komut satırından aktarılan kullanıcı adlarında $ ve \ karakterlerini reddediyor. Bazı otomasyon görevleri, kuantum sonrası anahtarlar ve scp aracıyla ilgili diğer değişikliklerin yanı sıra bundan etkilenebilir.

2026-10-07
4 dk okuma
0 görüntülenme
certi.news Editorial Team
OpenSSH 10.6 güvenlik nedenleriyle sıkıştırmanın bir bölümünü devre dışı bırakıyor ve bazı kullanıcı adlarını reddediyor

OpenSSH 10.6 sürümü, önceki bazı kullanım senaryolarını bozabilecek iki güvenlik değişikliği içeriyor: SSH sıkıştırmasında tekrarlar sözlüğü oluşturmaktan sorumlu LZ77 bileşeninin devre dışı bırakılması ve kullanıcı adlarının komut satırı üzerinden aktarılması sırasında $ ve \ karakterlerini içeren kullanıcı adlarının reddedilmesi. Proje geliştiricileri, bazı ortamların ve araçların değişiklik gerektireceğini bilerek bu kararı aldı.

SSH sıkıştırması neden zayıflatıldı?

Tek bir SSH oturumu etkileşimli bir terminal kanalı, bağlantı noktası yönlendirmesi veya dinamik bir SOCKS vekil sunucusu taşıyabilir. Sıkıştırma etkinleştirildiğinde kanallar tek bir sıkıştırma durumunu paylaşıyordu. Ruhr University Bochum'dan araştırmacılar Fabian Bäumer ve Marcus Brinkmann, bir saldırganın bir kanala seçtiği metni ekleyerek şifrelenmiş trafiği izlemesi ve aynı oturumdaki başka bir kanaldan geçen gizli verileri çıkarsaması olasılığını gösterdi.

Saldırı, daha önce ortaya çıkan dizileri tamamen kodlamak yerine yeniden kullanan LZ77 belleğine dayanıyor. Saldırganın tahmini sırrın bir bölümüyle eşleştiğinde sıkıştırılmış çıktı biraz daha kısa olabilir ve bu da verilerin kurtarılmasına yardımcı olan bir sinyal sağlar. Bu yöntem CRIME ve BREACH saldırı ailesine aittir, ancak belirli bir hazırlık gerektirir: SSH sıkıştırmasının etkin olması, trafiğin bir bölümünü kontrol edebilme ve sırrın saldırganın üzerinde bulunduğu kanalla çok kanallı bir SSH oturumu içinde yer alması.

Daha az gürültülü testlerde araştırmacılar, 26 harften oluşan bir alfabeden sekiz karakterlik bir sırrı 100 deneme üzerinden ortalama 276 tahminle kurtardı. Daha gürültülü, tarayıcı tabanlı bir senaryoda bu sayı yaklaşık 27.600 tahmine yükseldi. Kaynak materyale göre kavram kanıtı modelleri Claude Code kullanılarak oluşturuldu.

Sıkıştırmada pratikte ne değişiyor?

OpenSSH Huffman kodlamasını korudu, ancak hem ssh hem de sshd içinde LZ77 bölümünü devre dışı bıraktı. Bu nedenle sıkıştırma tamamen ortadan kalkmıyor, ancak daha az etkili hâle geliyor. Proje, olağan etkileşimli oturumların çoğunlukla büyük bir fark fark etmeyeceğini, buna karşılık sınırlı kapasitedeki bağlantılar üzerinden büyük miktarda sıkıştırılabilir veri aktaran otomatik görevlerin etkilenebileceğini belirtiyor.

OpenSSH'nin önerisi, sıkıştırmayı uygulama katmanına taşımaktır; burada sıkıştırma genellikle daha verimlidir ve bu tür saldırıya maruz kalmaz. Uygulamada, SSH sıkıştırmasına dayanan otomasyon sistemlerinin sahipleri yükseltme sonrasında aktarım boyutunu ve yürütme süresini ölçmeli, ardından verileri göndermeden önce sıkıştırmanın SSH sıkıştırmasına güvenmekten daha uygun olup olmadığını belirlemelidir.

Kullanıcı adları ve otomasyon yolu

10.6 sürümü, komut satırından aktarılan kullanıcı adlarında $ ve \ karakterlerini reddediyor. Bu değişiklik, ssh "$INPUT_USER@host" gibi bir komut oluşturan ve ardından kullanıcı adını ProxyCommand veya Match exec gibi yönergelere aktarabilen dahili araçları, CI görevlerini ve aracılık hizmetlerini hedefliyor. Bu yönergelerde söz konusu karakterler normal veri olarak değil, shell oluşturmanın bir parçası olarak yorumlanabilir.

Aynı kısıtlama, kullanıcı adı SSH yapılandırma dosyasındaki User yönergesiyle belirtildiğinde geçerli değil. Bu nedenle bu karakterleri içeren meşru hesaplar bu yöntemle kullanılmaya devam edebilir, ancak bunları doğrudan komut satırı üzerinden aktaran betiklerin ve araçların değiştirilmesi gerekebilir. Bu değişiklik, OpenSSH 10.3'teki ilgili bir düzeltmenin ardından geliyor; söz konusu sürümde shell karakterlerinin denetimi, bunların ssh_config içindeki genişletme yoluna ulaşmasına izin verecek kadar geç yapılıyordu.

İş akışını etkileyebilecek ek değişiklikler

  • Kuantum sonrası hibrit imza algoritması ssh-mldsa44-ed25519, deneysel @openssh.com son ekini kaybetti. Bu, önceki uygulamayla oluşturulan anahtarların yeniden oluşturulması veya kaldırılması gerektiği anlamına geliyor.
  • Proje, uzak bir ana bilgisayardan başka bir uzak ana bilgisayara kopyalama için scp -R seçeneğini kullanımdan kaldırmaya hazırlanıyor. Seçenek OpenSSH 10.6'da çalışmaya devam ediyor, ancak bir uyarı yayımlıyor ve gelecekte yok sayılması planlanıyor.

Bu değişiklikler, otomatik kullanım veri sızdırma veya komut enjeksiyonu için bir yol ortaya çıkardığında önceki davranışla uyumluluğun artık mutlak bir öncelik olmadığını gösteriyor. Ancak pratik kısıtlamalar eşit değil: sıkıştırma yoluyla veri sızdırma riski belirli bir oturum ve koşullar gerektirirken, kullanıcı adlarının reddedilmesi harici girdilere dayanan betiklerde hemen ortaya çıkabilir. Bu nedenle operasyon ekiplerinin yükseltmeyi test etmesi, SSH komutlarının oluşturulmasını gözden geçirmesi ve sürümü geniş ölçekte kullanıma almadan önce anahtarları ve kopyalama seçeneklerini doğrulaması gerekiyor.

Haber kaynağı
The New Stack - Software Development
Özgün kaynağı aç ↗
c
Yazar

certi.news Editorial Team

Bu hikâyeyi keşfet

İlgili konular ve varlıklar

Aynı kategoride

Bunlar da ilginizi çekebilir

Tüm haberleri gör