Forum Debian Users Gang

Tydzień się spóźniłeś.

Czy ja wiem, czy tydzień? U was ten skrypt co jest na https://github.com/hannob/bashcheck bez problemu odhacza wszystkie podatności? U mnie 2 z nich w dalszym ciągu są:

$ ./bashcheck
Testing /bin/bash ...
GNU bash, version 4.3.27(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

ethanak napisał(-a):

a ja tak z ciekawości: czym mi grozi ten bug na domowym netbooku?

Jak to czym?

Wystarczy, ze masz np Javę  - wtyczkę do FF (tysiące ludzi ma),
a w standardowym systemie Linux przeglądarka może odpalić polecenie /bin/bash z dowolnymi parametrami.

Oczywiście teraz wszystkie najważniejsze przeglądarki mają jakieś piaskownice, ale wystarczy babol w takiej piaskownicy, i gotowe.
Plugin-container z FF woła o powłokę, a w każdej wersji jest około XX błędów i podatności.

Podobnie z innymi programami, nawet raz pamiętam taką dziurę, kiedy wklejenie kawałka loga do okna rozmowy Pidgina (charakterystyczna sekwencja znaków) powodowała natychmiastowe powieszenie Xserwera.

Nie zagłębiałem się w temat, czy to wina Pidgina, biblioteki Gtk, biblioteki libGL ze steru Nvidii czy Xorga, ale niedługo później i Xorg,
i Pidgin i ster Nvidii miały dosyć poważne aktualizacje bezpieczeństwa.

W domowym kompie za FW ryzyko nie jest koszmarnie wielkie, ale też istnieje, jeśli masz pod nosem jakąś niezidentyfikowaną dziurę w innym programie, która pozwala na zdalny dostęp i odpalenie lokalnie powłoki.

Póki nie sprawdzasz każdej linijki kodu każdego programu w kompie, to zawsze masz przed nosem jakąś liczbę nieodkrytych błędów, które ktoś  może wykorzystać, jeśli ma do nich dostęp.

Pojęcie "system bezpieczny i niebezpieczny" to jest pojęcie dwustanowe, bez stanów pośrednich, nieźle je opisuje angielskie przysłowie
"nie można być częściowo w ciąży", przy czym nie ma systemu, w którym nie ma ryzyka wystąpienia błędów, dlatego kryterium przyjmuje formułę:
"albo się poważnie traktuje i łata błędy bez nieuzasadnionej zwłoki, albo się te błędy w większym lub mniejszym stopniu  ignoruje".


To by było na tyle

___

morfik napisał(-a):

Czy ja wiem, czy tydzień? U was ten skrypt co jest na https://github.com/hannob/bashcheck bez problemu odhacza wszystkie podatności? U mnie 2 z nich w dalszym ciągu są:

Kod:

$ ./bashcheck
Testing /bin/bash ...
GNU bash, version 4.3.27(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

U mnie tylko jedna:

Testing /bin/bash ...
GNU bash, version 4.2.52(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Found non-exploitable CVE-2014-6278 (lcamtuf bug #2)

Chociaż fakt faktem, ostatnimi czasy były w Gentusiu trzy alarmy z Bashem:
http://security.gentoo.org/glsa/glsa-201410-01.xml
http://security.gentoo.org/glsa/glsa-201409-10.xml
http://security.gentoo.org/glsa/glsa-201409-09.xml

Już w pewnym momencie zaczęło to wyglądać komicznie, u mnie:

     

Thu Sep 25 02:30:11 2014 >>> app-shells/bash-4.2_p48
       merge time: 3 minutes and 54 seconds.

     Thu Sep 25 18:34:16 2014 >>> app-shells/bash-4.2_p48-r1
       merge time: 4 minutes and 6 seconds.

     Wed Oct  1 06:08:23 2014 >>> app-shells/bash-4.2_p50
       merge time: 2 minutes and 35 seconds.

     Thu Oct  2 00:31:11 2014 >>> app-shells/bash-4.2_p51
       merge time: 5 minutes and 10 seconds.

     Sun Oct  5 02:12:43 2014 >>> app-shells/bash-4.2_p52
       merge time: 3 minutes and 23 seconds.

Pewnie nie udało się załatać całkowicie Basha dotychczasowymi łatkami,
i trzeba spory kawał kodu przepisać, co musi potrwać.
Któreś Zsh też podobno miało tego babola.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-10-06 17:02:25)

Jacekalex napisał(-a):

Pojęcie "system bezpieczny i niebezpieczny" to jest pojęcie dwustanowe, bez stanów pośrednich, nieźle je opisuje angielskie przysłowie
"nie można być częściowo w ciąży", przy czym nie ma systemu, w którym nie ma ryzyka wystąpienia błędów, dlatego kryterium przyjmuje formułę:
"albo się poważnie traktuje i łata błędy bez nieuzasadnionej zwłoki, albo się te błędy w większym lub mniejszym stopniu  ignoruje".

Tylko w teorii.
W praktyce nie ma 100% bezpiecznych systemów i zawsze jest się tylko „częściowo w ciąży”.
Dlatego niektóre mniej krytyczne błędy są przez jakiś czas zwyczajnie ignorowane bo naprawa ich powoduje kolejne problemy, a 100% i tak nigdy się nie osiągnie.

1087

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:13)

No i wszyscy mamy podatne systemy. W końcu windows jest w czymś lepszy niż linux. xD

Ostatnio edytowany przez morfik (2014-10-06 23:21:20)

M. Zalewski (Icamtuf) zaleca zainstalowanie patcha stworzonego przez inżyniera z Red Hat, Floriana Weiner, ktory opiera się na filtrowaniu zmiennych środowiskowych. Radykalny sposób.

Najnowsza aktualizacja basha w gentoo

winnetou@hordeum-vulgare ~ $ /usr/local/src/bashcheck/bashcheck 
Testing /bin/bash ...
GNU bash, version 4.2.53(1)-release (x86_64-pc-linux-gnu)

Variable function parser pre/suffixed [%%, upstream], bugs not exploitable
Not vulnerable to CVE-2014-6271 (original shellshock)
Not vulnerable to CVE-2014-7169 (taviso bug)
Not vulnerable to CVE-2014-7186 (redir_stack bug)
Test for CVE-2014-7187 not reliable without address sanitizer
Not vulnerable to CVE-2014-6277 (lcamtuf bug #1)
Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)

The most important fix you need is one of the prefix/suffix-patches. Upstream patch number for this is bash042-050 and bash043-027 (patches for older versions also available). This patch was originally created by RedHat developer Florian Weimer and a modified version was applied by Bash developer Chet Ramey.

Once you have this prefix patch all other vulnerabilities are not exploitable. They are still bugs that should be fixed, but there is nothing to worry about.

darius napisał(-a):

Debian Sid aktualizowany przed minuta
....
tez nie daje dobrych nadzieju a obroncy twierdza, ze problem jest rozwiazany.

Debian i inne duże uniwersalne dystrybucje mają jeden problem:
Kilka architektur sprzętowych, do tego wydania, stable, oldstable, testing, sid, do tego jeszcze kFreeBSD na innym jaju, a ludzi i kasy trochę jest, ale nie jest to źródło bez dna.

Dlaczego w Gentoo już są załatane obie dziury, a Debian ma opóźnienie?
W Gentoo Developerzy nie zajmują się paczkologią, tylko przygotowują ebuildy i obrabiają bugzillę, natomiast flagi kompilatora, wersje systemu (testing, stable, experimental), architektura, to już problem pacjenta i społeczności.

Dzięki temu każdy pacjent liźnie trochę developerki na własnym kompie,
i cholernie skutecznie poznaje w ten sposób Linuxa, a Developer nie musi paczkować programu na dwadzieścia rożnych wersji i architektur.

Krótko pisząc, z punktu widzenia developerów system dosyć ekologiczny, punktu użyszkodnika bezpieczny,  stabilny i przewidywalny, chyba, że ktoś jest tak odporny na doświadczenia empiryczne, że Debian też jest za trudny. :DDD

Pozdro
;)

Ostatnio edytowany przez Jacekalex (2014-10-07 12:43:10)

To co z takiego błędu może wyniknąć to też raczej nikt nie wie. Przecie tak samo było z tym pierwszym shellshockiem --  zaczeli experymentować i nagle się syf zrobił. :] Poza tym, ja próbowałem sobie pobrać źródła debianowe i nałożyć na nie te patche upstreamowe, bo z tego co ludzie piszą, to upstream już załatał wszystkie te dziury i patche są gotowe. Tylko co z tego, że pache są, jak w debianie nie idzie ich założyć, bo sypie błędami? xD Na niezdebianizowanych źródłach, te patche wchodzą bez problemu. Dlatego raczej poczekamy jeszcze zanim te ostatnie łaty wejdą do debiana.

Jacekalex napisał(-a):

uzytkownikubunt napisał(-a):

Przecież jest wyraźnie napisane: Found non-exploitable - znaleziono błąd, jednak nie jest on wykorzystywalny do ataku.

W zasadzie tak, ale tylko do czasu, aż ktoś nie wpadnie na pomysł, jak go wykorzystać.

To samo można napisać o każdym z tysięcy pakietów. O każdym programie, każdym systemie operacyjnym etc.
Dla mnie całe zamieszanie z luką w bashu zakończyło się na:

They are still bugs that should be fixed, but there is nothing to worry about.

Widocznie jestem ignorantem ;)