• 27-09-2014, 18:06:59
    #28
    sekozzi adlı üyeden alıntı: mesajı görüntüle
    hangi linux dağıtımını kullanmaktasınız.
    CentOS 6.5 x64 Final
  • 27-09-2014, 19:17:18
    #29
    hknm adlı üyeden alıntı: mesajı görüntüle
    O konu şuan itibari ile kilitlendi. Kilitlenme sebebini yazmaya gerek yok. Bur konuda bari tartişmadan devam edin arkadaslar takip etmek için.
  • 27-09-2014, 19:51:12
    #30
    mecburum adlı üyeden alıntı: mesajı görüntüle
    centoslarda bazen yum update işe yaramıyor elle yapmak daha garanti.

    ssh de vulnerable görürseniz tehlikedesiniz.
    env x='() { :;}; echo vulnerable' bash -c "echo patched"
    id karşısında değer görürseniz tehlikedesiniz.
    rm -f echo && env -i X='() { (a)=>\' bash -c 'echo id'; cat echo
    fixlemek için sırayla aşağıdaki kodları ssh de girin. for daki tırnaklara dikkat.

    mkdir src
    cd src
    wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
    #download all patches
    for i in $(seq -f "%03g" 0 26); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
    tar zxvf bash-4.3.tar.gz
    cd bash-4.3
    #apply all patches
    for i in $(seq -f "%03g" 0 26);do patch -p0 < ../bash43-$i; done
    #build and install
    ./configure && make && make install
    cd ..
    cd ..
    rm -rf src
    reboot etmeyi unutmayın.
    verdiğiniz kodlarda patched ve id yazıyor sadece CentOS-6.5 ve bash verisyonu bash-4.1.2-15.el6_5.2.x86_64
  • 27-09-2014, 20:03:42
    #31
    NURAH adlı üyeden alıntı: mesajı görüntüle
    O konu şuan itibari ile kilitlendi. Kilitlenme sebebini yazmaya gerek yok. Bur konuda bari tartişmadan devam edin arkadaslar takip etmek için.
    sanırım ben sebep oldum o konuda. kusura bakmayın.

    belgin adlı üyeden alıntı: mesajı görüntüle
    Şuradan da test edebilirsiniz.

    http://shellshock.brandonpotter.com/

    SSH erişimi bulunmayan hosting ve reseller sahipleri buradan test edebilir, açık sunucuda mevcutsa sunucu sahibini güncelleme konusunda haberdar edebilirler.
    bu adreste sadece gördüğüm kadarı ile web taraflı bir check işlemi var. sadece bunlar yeterli değildir. aşağıda nedenini anlatacağım.

    ancak uzanma fırsatı buldum detaylı yazıyım konuyu. umarım birilerine yardımcı olabilirim.

    arkadaşlar ilgili açık 4 gün önce ortaya çıktı. CVE-2014-6271 id kaydı oluşturuldu ve fix yayınlandı. ancak bu fix yeterli değildi ve konunun devamı olarak CVE-2014-7169 oluşturuldu. Yani şu aşamada yapılan fix yeterli bir işlem değil gibi görünüyor.

    durumun vehametine gelirsek; sadece bash kabuğu olarak değil, bash kabuğuna erişimi olan her program her servis bu durumda bir açık demek. mesela postfix, mesela ssh mesela cgi wrapper'lar gibi.

    yukarıdaki site neden web taraflı olarak kontrol ediyor onu açıklayalım.

    açık local bir açık yani sunucu içinde bir açık. sizin sunucunuza erişemeyen herhangi biri bu açığı kullanamaz demek bu. bu nedenle dışarıya açılan ve bu açığı barındıran herhangi bir servis bu açığı local olmaktan çıkarıp remote hale dönüştürür. bu ne demek, sizin sunucunuza hiçbir şekilde girmeden uzaktan yapacağını rahatlıkla yapar. yukarıdaki site de bu nedenle genellikle php wrapper'ları bu açıdan test etmiş. ama yeterli bir durum değil çünkü aynı şekilde postfix de aynı durumda veya ssh da.

    bu forum başlığında çoğunlukla hosting firmaları ya da eşe dosta hosting sağlayan bireysel kişiler mevcut ve sonuçta binlerce kişiye ftp, kontrol paneli erişimi veriliyor. remote yani uzaktan olmasına gerek kalmaz. binlerce yok temasında yok kendisinde yok eklentisinde açık olan wordpress site var. yani aslında iyi ya da kötü niyetli binlerce insan sunucularımızda zaten fink atıyor

    test aşamasına gelirsek; bash için daha önce yayınlanmış değişik fix'lere göre farklı sonuçlarla karşılaşılabilmektedir. ama sonuçta ingilizce bilenler için bu test'ler ve sonuçları konusunda;

    https://access.redhat.com/articles/1200223

    test için ayrıca redhat'ın yayınladığı bir test script'i varmış. onu bulabilirsem ekleyecem.

    geçici olduğu söylenen fix'leri yüklemek basit, özel derleme yapmanıza gerek yok. yum update apt-get upgrade pkg_add vs vs

    bi de tüy dikmek lazım di mi

    bu da benden expert mode'lara gelsin

    http://kb.vmware.com/kb/2090817
    http://kb.vmware.com/kb/2090740
  • 27-09-2014, 20:13:29
    #32
    Kurumsal PLUS
    PcMaKeR adlı üyeden alıntı: mesajı görüntüle
    Arkadaşlar iki gün önce güvenlik açığı bulundu bash shell de.

    Ben iki centos üç freebsd sunucumu güncelledim.

    Centos için: yum clean all && yum update bash

    Freebsd için(eğer kullanıyorsanız): pkg upgrade bash

    Yada: portmaster bash

    Ubuntu Server için : apt–get update && apt–get upgrade
    Yada: apt–get update && apt-get install --only-upgrade bash

    İle güncelleyebilirsiniz.

    Açık ciddi bir açık riske girmeyin...

    https://www.centosblog.com/criticica...ux-server-now/


    http://stackoverflow.com/questions/2...hell-shock-bug
    Hocam bilgilendirme için çok çok teşekkürler hem sunucum için hemde kişisel bilgisayarım için(ikiside ubuntu) sırasıyla apt-get update, apt-get upgrade komutlarını verdim herşey tamam heralde ? Başka yapmamız gereken birşey var mı ?
  • 27-09-2014, 20:20:15
    #33
    Kimlik doğrulama veya yönetimden onay bekliyor.
    Güncellemeyi yaptım.shell olayı yeni bitti yeni bişeyle uğraşmak istemiyorum.
  • 27-09-2014, 21:01:32
    #34
    evileye98 adlı üyeden alıntı: mesajı görüntüle
    Hocam bilgilendirme için çok çok teşekkürler hem sunucum için hemde kişisel bilgisayarım için(ikiside ubuntu) sırasıyla apt-get update, apt-get upgrade komutlarını verdim herşey tamam heralde ? Başka yapmamız gereken birşey var mı ?
    yok dostum, bende kubuntu kullanıyorum notebookta güncelledi dediklerim ile

    --R10.NET; Flood Engellendi -->-> Yeni yazılan mesaj 21:01:32 -->-> Daha önceki mesaj 20:54:28 --

    @foo; mükemmelsin, r10+ böyle cevaplara yakışıyor. diğer konudaki tartışmayı okudum da bash script ile site yapmayı okuyunca kapattım sayfayı.

    kabuk adı üzerinde. Anlamadığım openssl açığı çok basit bir kod bloğundan oluşuyordu ve çok uzun süreden beri olan bir açıkmış. bu zımbırtıda böyle. basit hatalar feci sonuçlar çıkartıyor ama.

    destek verdiğim firmalar daha duymamış açıkları şuana kadar toplamda 9 server güncelledim. daha bilmeyen çoktur diye tahmin ediyorum.
  • 27-09-2014, 21:05:23
    #35
    foo adlı üyeden alıntı: mesajı görüntüle
    sanırım ben sebep oldum o konuda. kusura bakmayın.



    bu adreste sadece gördüğüm kadarı ile web taraflı bir check işlemi var. sadece bunlar yeterli değildir. aşağıda nedenini anlatacağım.

    ancak uzanma fırsatı buldum detaylı yazıyım konuyu. umarım birilerine yardımcı olabilirim.

    arkadaşlar ilgili açık 4 gün önce ortaya çıktı. CVE-2014-6271 id kaydı oluşturuldu ve fix yayınlandı. ancak bu fix yeterli değildi ve konunun devamı olarak CVE-2014-7169 oluşturuldu. Yani şu aşamada yapılan fix yeterli bir işlem değil gibi görünüyor.

    durumun vehametine gelirsek; sadece bash kabuğu olarak değil, bash kabuğuna erişimi olan her program her servis bu durumda bir açık demek. mesela postfix, mesela ssh mesela cgi wrapper'lar gibi.

    yukarıdaki site neden web taraflı olarak kontrol ediyor onu açıklayalım.

    açık local bir açık yani sunucu içinde bir açık. sizin sunucunuza erişemeyen herhangi biri bu açığı kullanamaz demek bu. bu nedenle dışarıya açılan ve bu açığı barındıran herhangi bir servis bu açığı local olmaktan çıkarıp remote hale dönüştürür. bu ne demek, sizin sunucunuza hiçbir şekilde girmeden uzaktan yapacağını rahatlıkla yapar. yukarıdaki site de bu nedenle genellikle php wrapper'ları bu açıdan test etmiş. ama yeterli bir durum değil çünkü aynı şekilde postfix de aynı durumda veya ssh da.

    bu forum başlığında çoğunlukla hosting firmaları ya da eşe dosta hosting sağlayan bireysel kişiler mevcut ve sonuçta binlerce kişiye ftp, kontrol paneli erişimi veriliyor. remote yani uzaktan olmasına gerek kalmaz. binlerce yok temasında yok kendisinde yok eklentisinde açık olan wordpress site var. yani aslında iyi ya da kötü niyetli binlerce insan sunucularımızda zaten fink atıyor

    test aşamasına gelirsek; bash için daha önce yayınlanmış değişik fix'lere göre farklı sonuçlarla karşılaşılabilmektedir. ama sonuçta ingilizce bilenler için bu test'ler ve sonuçları konusunda;

    https://access.redhat.com/articles/1200223

    test için ayrıca redhat'ın yayınladığı bir test script'i varmış. onu bulabilirsem ekleyecem.

    geçici olduğu söylenen fix'leri yüklemek basit, özel derleme yapmanıza gerek yok. yum update apt-get upgrade pkg_add vs vs

    bi de tüy dikmek lazım di mi

    bu da benden expert mode'lara gelsin

    http://kb.vmware.com/kb/2090817
    http://kb.vmware.com/kb/2090740
    vSphere ESXi Hypervisor
    ESXi 5.0 - 5.5 is not affected as it uses the Ash shell (through busybox), which is not affected by the vulnerability reported for the Bash shell.

    Şu cümleyi okuyunca bir rahatlama gelmedi desem yalan olur
  • 27-09-2014, 21:49:16
    #36
    Axerhosting adlı üyeden alıntı: mesajı görüntüle
    vSphere ESXi Hypervisor
    ESXi 5.0 - 5.5 is not affected as it uses the Ash shell (through busybox), which is not affected by the vulnerability reported for the Bash shell.

    Şu cümleyi okuyunca bir rahatlama gelmedi desem yalan olur
    Ama itiraf et önce baya bi heyecan yaptın. Burdan belirteyim de üstüme kalmasın. Esxi veya vsphere tarafında bi sıkıntı yok.

    Dediğim gibi vmware tarafı biraz daha pro kullananlar için geçerli. Vcloud gibi. Mesela bizdeki vcenter server appliance gibi.