Terminallerde kaçış dizisi saldırılarını nasıl önleyebilirim?


29

CVE-2009-4487'nin (günlük dosyalarındaki kaçış dizileri tehlikesiyle ilgili olan) ayrıntılarını okumak biraz şaşırdım.

CVE-2009-4487’den alıntı yapmak için :

nginx 0.7.64, uzaktaki saldırganların, bir pencerenin başlığını değiştirmesine ya da muhtemelen isteğe bağlı komutları çalıştırmasına veya bir terminal emülatörü için bir kaçış dizisi içeren bir HTTP isteği üzerine isteğe bağlı komutlar çalıştırmasına izin vermeden, sterilize etmeden bir günlük dosyasına veri yazar.

Açıkçası, bu gerçekten nginx'te değil, terminal emülatörlerinde bir güvenlik boşluğu ile ilgili.

Tabii, belki de catbir log dosyasını terminale sokmak sadece kazayla olur, ancak log dosyası oluşturmak grepoldukça yaygındır. lessbelki kaçış dizilerini temizler, ama hangi kabuk komutlarının kaçış dizilerini değiştirmediğini kim bilebilir ...

Vernik cevabına katılıyorum :

Genel olarak, terminal-yanıt-kaçmaların bilgeliği düzenli aralıklarla sorgulanmıştır, ancak hala büyük terminal öykünme programlarının hiçbiri, muhtemelen 1970'lerin teknolojisi kullanılmayan uyumsuzluk girişimlerinde bu dizileri atmaya uygun görülmemiştir. [..] Günlük dosyaları yazan herhangi bir programı suçlamak yerine, güvenlik açısından, terminal emülasyon programlarının aptalca şeyler yapmayı bırakması ve böylece bu ve diğer güvenlik sorunlarını bir kez düzeltmesi daha verimli olacaktır. ve herkes için.

Böylece benim sorularım:

Xterm'mi nasıl koruyabilirim, böylece artık komutları çalıştırmak veya kaçış dizileri aracılığıyla dosyaların üzerine yazmak mümkün olmaz?

Bu saldırıya karşı X için hangi terminal emülatörleri güvence altına alınmıştır?


4
Birçok kaçış dizisi meşru şeyler yapar (bir xterm'i yeniden adlandırın / yeniden boyutlandırın / etc). Ancak herhangi biri komutları yürüten veya dosyaların üzerine yazılan çıkış dizilerini tanımlayabilir mi?
krubo


Güvenlik SE’ye web tarayıcıdan web’e yapılan yapıştırma kontrolleri ile ilgili benzer bir sorun: Kendimi bu tür bir pano kullanımından nasıl koruyabilirim? tl; dr: 2013/2015 tarihinden sonra piyasaya sürülen xterm / vte tabanlı bir terminal kullanıyorsanız, varsayılan olarak kontrol karakterlerini filtrelendikleri için buna karşı korunursunuz.
maxschlepzig

Yanıtlar:


27

VT100 terminalleri (tüm modern terminal emülatörlerinin bir dereceye kadar öykündüğü) bir dizi problemli komutu destekledi, ancak modern emülatörler veya dağıtımlar daha problemli ve daha az kullanışlı olanları devre dışı bıraktı. İşte potansiyel olarak riskli kaçış dizilerinin kapsamlı olmayan bir listesi ( ekranı yalnızca bir şekilde okunaksız hale getirenleri içermez):

  • Keyfi günlük dosyası , HD Moore tarafından bildirilen rxvt ve Eterm'de komut verir . Bunlar gerçekten büyük hatalar, neyse ki uzun zamandır düzeltildi.
  • Dönüş Terminali Durumu olarak da bilinen answerback komutu ENQ( Ctrl+E) tarafından çağrılır . Bu işlem, kullanıcı yazmış gibi terminale metin ekler. Ancak, bu metin saldırganın kontrolü altında değildir: terminalin kendi adıdır, genellikle xtermveya benzeri bir şeydir screen. Sistemimde (Debian squeeze), xterm varsayılan olarak boş dizgeyi döndürür (bu answerbackStringkaynak tarafından kontrol edilir ).
  • Aygıt Özellikleri Gönder komutları ESC [ cve arkadaşları. Terminal ESC [ … c( yalnızca rakamları ve yalnızca ASCII noktalama işaretlerini içerebilir) ile yanıt verir . Bu, çoğunlukla eski olan ama belki eski uygulamalar tarafından kullanılan bazı terminal yeteneklerini sorgulamanın bir yoludur. Yine terminalin cevabı kullanıcı girişinden ayırt edilemez, fakat saldırganın kontrolü altında değil. Kontrol dizisi bir işlev tuşu gibi görünebilir, ancak yalnızca kullanıcı olağandışı bir yapılandırmaya sahipse (karşılaştığım normal ayarların hiçbiri terminal yanıtının öneki olan geçerli bir işlev tuşu çıkış dizisine sahip değildir).
  • Çeşitli cihaz kontrol fonksiyonları (DCS, başlangıçtan itibaren kaçar ESC P).
    • DECUDKTipik bir terminal emülatöründe (kullanıcı tanımlı anahtarları ayarla) ne gibi zararlar verilebileceğini bilmiyorum .
    • DECRQSS(İstek Durumu Dizesi), terminalin bir kaçış dizisi ile yanıt verdiği, ancak bu kez başlayan bir başka komuttur \eP; \ePgeçerli bir anahtar ( Alt+ Shift+ P) olduğundan bu sorunlu olabilir .
    • Xterm iki deneysel özelliğe daha sahiptir: ESC P + p …ve ESC P + q …, termcap dizgilerini almak ve ayarlamak için. Açıklamadan, bu en azından fonksiyon tuşlarının etkisini değiştirmek için kullanılabilir.
  • Birkaç durum raporu komutu: ESC [ … n(Cihaz Durum Raporu). Terminal bir kaçış dizisi ile cevap verir. Bu kaçış dizilerinin çoğu, işlev kaçış dizilerinin işlevine karşılık gelmez. Bir sorunlu görünüyor: rapor , rakam dizilerinin bulunduğu ve olduğu ESC [ 6 nbiçimiyle ilgili ve bu bazı değiştiricilere benzeyebilir .ESC [ x ; y RxyF3
  • Pencere manipülasyon komutları ESC [ … t.
    • Bunlardan bazıları, xterm penceresinin yeniden boyutlandırılmasını, simgeleştirilmesini vb.
    • Bunlardan bazıları terminalin bir kaçış dizisiyle yanıt vermesine neden olur. Bu kaçış dizilerinin çoğu ancak iki tehlikeli komut bulunmaktadır, düşük risk bak: cevapları ESC [ 2 0 tve ESC [ 2 1 tsırasıyla terminali pencerenin simgesi etiketini ve başlığı ve saldırgan bu seçebilirsiniz.
    • En azından Debian'ın altında, xterm bu komutları varsayılan olarak yok sayar; allowWindowOpskaynağı ayarlayarak veya seçici olarak disallowedWindowOpskaynak aracılığıyla etkinleştirilebilirler . Ubuntu 10.04 altındaki Gnome terminali, varsayılan olarak başlık cevaplarını bile uygular. Diğer terminalleri veya sürümleri kontrol etmedim.
  • Terminal başlığını veya simge adını ayarlama komutları. Xterm ve diğer birçok X terminalinde bunlar . Ekran altında kaçış dizisi . Bu emirlerden duyduğum endişeyi abartılı buluyorum. Bir miktar yaramazlık olmasına rağmen, herhangi bir web sayfasının aynı sorunu var. Sadece unvanına dayalı olan ve sınıfına göre olmayan bir pencerede hareket etmek, size güvenilmeyen bir taraf tarafından size verilen bir dosyayı açmak, bir kabuk betiğinde değişken bir genişleme yapmaktan veya burun üzerine kuduz bir köpek yazmaktan kaynaklanıyor. - ısırılırsan şikayet etme.ESC ] digit ; title ESC \ESC k title ESC \

Varnish'in cevabını önemsiz buluyorum. Suçu değiştirmeye çalışıyor ya da güvenlik nazi modundaymış gibi hissediyor (herhangi bir güvenlik sorunu, orijinal olsun ya da olmasın, bir özelliği karartmaya haklı çıkarıyor).

Genel olarak, terminal-yanıt-kaçmaların bilgeliği düzenli aralıklarla sorgulanmıştır, ancak hala büyük terminal öykünme programlarının hiçbiri, muhtemelen 1970'lerin teknolojisi kullanılmayan uyumsuzluk girişimlerinde bu dizileri atmaya uygun görülmemiştir. (…)
Günlük dosyaları yazan herhangi bir programı suçlamak yerine, güvenlik açısından, terminal emülasyon programlarının aptalca şeyler yapmayı bırakması ve böylece bir kez daha bu ve diğer güvenlik sorunlarını çözmesi daha verimli olacaktır. hepsi için.

Yanıtların çoğu yararlı özelliklerdir: bir uygulamanın imleç konumu ve pencere boyutu gibi şeyleri bilmesi gerekir. Pencere başlığını ayarlamak da çok yararlıdır. Tamamen ioctlbunlar için yapılan aramalara güvenmek mümkün olacaktı , ancak bu, bu ioctlçağrıları yapmak ve bunları dosya tanımlayıcılardan geçen unix tarzı bir metne çevirmek için ek kod ve araçlar gerektiriyordu . Bu arayüzleri değiştirmek, şimdi, çok az fayda için çok fazla iş olacaktır.

Metin dosyalarının kontrol karakterleri gibi yazdırılmayan karakterler içermemesi gerekir. Günlük dosyalarının genellikle metin dosyaları olması beklenir. Günlük dosyaları kontrol karakterleri içermemelidir.

Bir dosyanın kaçış dizileri içerebileceğinden endişe ediyorsanız, dosyayı bir düzenleyicide açın veya veya seçeneği lessolmadan birlikte görüntüleyin ya da gözden geçirin .-r-Rcat -v


2
“Tamamen ioctl çağrılarına güvenmek mümkün olacaktır” dedi. Peki ya uygulama ile terminal arasında gerçekten seri kablo varsa?
mmv-ru

5

Bu o kadar basit değil; xtermPek çok insan, unvanı istemin bir parçası olarak vb . ayarlamak için ve çok iyi nedenlerden dolayı ( shutdownyanlış terminal penceresinden yanlış makineye sahip olan herkesin size söyleyebileceği gibi!) söyleyecek kodları vardır . Bu nedenle doğru şekilde sabitleme, güvenlik bağlamları getirmeyi ve böylece mermiler ile terminal emülatörleri ve muhtemelen insanların nokta dosyaları arasındaki etkileşimi ciddi şekilde karmaşıklaştırmayı içerir. Ya da bir terminalde gösterilebilecek her şeyi temizlemenin düşük kira çözümüyle gidebilirsiniz; bu büyük ölçüde kontrol karakterlerinden kaçmayı azaltıyor, ki bu da muhtemelen sadece göze çarpmaları için yapılması gerekenlerdi (çünkü bir günlük dosyasında kabuk kodunu enjekte etmeye çalışan birini gösterebilirler).

(Bir yana, punycode aynı tür problemlerin daha şiddetli bir örneğidir - ve yine de resmi bir standart haline getirilmiştir. Bazen güvenlik, birinin kontrolünün dışındaki güvensiz tasarımları hafifletmek için ortaya çıkar.)


1
Bir x terimi, kaçış dizileriyle başlığın değiştirilmesine izin verebilir, ancak dosyaların üzerine yazılmasına ve rastgele komutların kaçış dizileri ile yürütülmesine izin vermeyebilir . Bu ileriye doğru bir adım olur, değil mi?
maxschlepzig

1
Bunu yapmanın doğrudan yolları yıllardır devre dışı bırakılmıştır. En azından ek bir adım (her ne kadar kullanıcının yeniden programlanmış bir fonksiyon tuşunu çağırmasını sağlamak için sosyal mühendislik saldırısı) gerektirse de, dolaylı yollar hala devam etmektedir. Ancak başlık çubuğu, muhtemelen kullanıcıyı, yanlış bir yerde bir şeyi yapmakla karıştıran bir saldırının bir parçası olarak CVE'de özel olarak çağrıldı. En büyük modern endişe, kabuğa keyfi metinler göndermek için programlanabilecek bir şey ve saldırganın terminal emülatörünün ne yapabileceğini
öğrenmesini sağlayan cevaplar

... ama bu, hız Varnish neredeyse kesinlikle hala yazılımın en az taşındığı büyük ticari ortamlarda kullanılıyor ve yapılan uygun değişiklikleri elde etmek için diş çekmekten çok daha fazlasını gerektiriyor.
geekosaur
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.