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)

[quote=ethanak]a ja tak z ciekawości: czym mi grozi ten bug na domowym netbooku?[/quote]
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

___


[quote=morfik]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)

[/quote]
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)

[quote=Jacekalex]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".[/quote]
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.

[b]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.[/b][/quote]