Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Dzien dobry,
Czy juz wszyscy czytali => http://www.technologyreview.com/view/531286/why-the-shellshock-bug-is-worse-than-heartbleed/
Lista bledow jest dostepna tutaj => https://github.com/mubix/shellshocker-pocs
Ostatnio edytowany przez darius (2014-10-08 10:20:05)
Offline
[quote=mati75]Tydzień się spóźniłeś.[/quote]
Uprawiasz niekonstruktywne czepialstwo :D
Niektóre ludzie żyją sobie w innych epokach, niektórzy nie wiedzą, że już jest 2014 i Stalin już nie żyje, inni ciągle myślą, że to jest 1982, to tydzień opóźnienia nie jest u nikogo niczym niezwykłym. :D
[b]@darius[/b]
Bzdury, błąd w Bashu nie jest ważniejszy od hardcorowej dziury w OpenSSL, bo na błąd Basha masz w każdym systemie sporo różnych mechanizmów obronnych, np na "wielkie zagrożenie zdalne" skryptów CGI i Apacha masz SElinuxa czy Apparmora, którymi można zablokować każde podejrzane działanie powłoki pozwalając uruchomić interpreter powłoki tylko w chronionym profilu systemu ACL, a tymczasem na sytuację, kiedy OpenSSL ujawnia klucz prywatny serwera nie było żadnej obrony i choćby jednej kropki czy przecinka w logach.
Także na argument shellshok większe niż heartbleed przypomina się stary [url=http://janbrzechwa.w.interia.pl/stobajek/niepieprzpietrze.html]wierszyk[/url]. :D
To by było na tyle
Ostatnio edytowany przez Jacekalex (2014-10-06 15:36:03)
Offline
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)
Offline
a ja tak z ciekawości: czym mi grozi ten bug na domowym netbooku?
Offline
[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)
Offline
Poczytalem tez ten artykul (przetlumaczycie sobie) http://www.silicon.fr/faille-shellshock-bash-tempete-loin-terminee-97165.html w ktorym jest cytowany nasz rodak [url=http://pl.wikipedia.org/wiki/Michał_Zalewski]Michal Zalewski[/url] (alias Icamtuf) znany odkrywca roznych bledow, ktory 27 i 30 wrzesnia 2014 sygnalizuje dwa powazne (morfik ma dwa i jacekalex jeden)
http://lcamtuf.blogspot.fr/2014/10/bash-bug-how-we-finally-cracked.html
Ostatnio edytowany przez darius (2014-10-06 17:51:28)
Offline
[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.
Offline
[quote=yossarian][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.[/quote]
Nic innego nie napisałem.
Niektóre błędy są łatane dłużej, bo po prostu developerzy poszczególnych aplikacji i systemów nie mają nieskończonej ilości czasu i pieniędzy, żeby zajmować się każdym babolem.
Nawet w szacownych korpo nie da się skutecznie zapewnić bezpiecznego systemu, choć ilość kasy na ten cel w takim np Microsofcie jest taka, jakiej w ekosystemie Linuxa nikt nawet w telewizji nie widział.
Nie mniej jednak, nie jest źle, generalnie i tak mamy dużo bezpieczniejsze systemy, niż M$, Apple czy Android.
Pozdro
;-)
Offline
1087
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:13)
Offline
Testing /bin/bash ... GNU bash, wersja 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)
Offline
[quote=morfik]No i wszyscy mamy podatne systemy. W końcu windows jest w czymś lepszy niż linux. xD[/quote]
Pod tym jednakże warunkiem, że powłoka systemowa Windows nie ma groźniejszych dziur, zazwyczaj ma takich kilka. :D
Przy okazji, nie wiem, kto jeszcze zauważył, ale Gentuś tutaj zdeklasował rywali, ma tylko jedną podatność CVE w Bashu, a Debian i Fedora po dwie.
CVE-2014-6277 w Gentusiu jest już załatane,w innych prezentowanych Linuxach dopiero będzie. xD
Offline
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.
Offline
Lepszy sposób, to założenie, że programy dzielą się na te, co będą wkrótce miały hardcorowe dziury, i na te, co już mają hardcorowe dziury. xD
Tutaj macie taki mały sposób, żeby hardcorowo dziurawy Bash nie był taki straszny:
http://jacekalex.sh.dug.net.pl/apparmor/usr.lib64.firefox.plugin-container.txt
I nie jest zbyt istotne dla systemu, jakie zmienne można zadeklarować w bashu, ważniejsze jest, co realnie można zrobić przy pomocy basha i tych zmiennych. :D
To by było na tyle
;-)
Ostatnio edytowany przez Jacekalex (2014-10-07 00:44:48)
Offline
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)
Offline
Zgadza się, przed chwilką zaktualizowałem:
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)
Ciekawe, co tam w Debianach, Buntach i Fedorach słychać. ;)
Debian Jessie - Bash aktualizowany przed minutą - wersja 4.3-10 (wg dpkg):
Testing /bin/bash ... GNU bash, wersja 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)
Jak na razie, Gentoo <> Debian Jessie 2:0.
Gentuś ma o dwie dziury w Bashu mniej.
Ciekawe, ile zajmie wyrównanie. :D
Ostatnio edytowany przez Jacekalex (2014-10-07 15:25:02)
Offline
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]
Offline
Debian Sid aktualizowany przed minuta
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)
tez nie daje dobrych nadzieju a obroncy twierdza, ze problem jest rozwiazany.
Offline
[quote=darius]Debian Sid aktualizowany przed minuta
....
tez nie daje dobrych nadzieju a obroncy twierdza, ze problem jest rozwiazany.[/quote]
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)
Offline
1089
Ostatnio edytowany przez uzytkownikubunt (2016-12-01 00:59:15)
Offline
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.
Offline
[quote="uzytkownikubunt"]Przecież jest wyraźnie napisane: Found non-exploitable - znaleziono błąd, jednak nie jest on wykorzystywalny do ataku.[/quote]
W zasadzie tak, ale tylko do czasu, aż ktoś nie wpadnie na pomysł, jak go wykorzystać.
W informatyce nie ma rzeczy niemożliwych, są tylko czasem trudniejsze do zrobienia.
A jak wiadomo od czasów starozytnych:
"zdarzają się takie rzeczy na niebie i ziemi, o których nie śniło się największym filozofom"[/quote]
Pisane z pamięci - nie jest to dosłowny cytat, ale sens jest właśnie taki.Ostatnio edytowany przez Jacekalex (2014-10-07 15:23:18)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
[quote=Jacekalex][quote="uzytkownikubunt"]Przecież jest wyraźnie napisane: Found non-exploitable - znaleziono błąd, jednak nie jest on wykorzystywalny do ataku.[/quote]
W zasadzie tak, ale tylko do czasu, aż ktoś nie wpadnie na pomysł, jak go wykorzystać.[/quote]
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.[/quote]
Widocznie jestem ignorantem ;)
Offline
Time (s) | Query |
---|---|
0.00013 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00098 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='18.217.122.218' WHERE u.id=1 |
0.00064 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '18.217.122.218', 1730419494) |
0.00045 | SELECT * FROM punbb_online WHERE logged<1730419194 |
0.00048 | SELECT topic_id FROM punbb_posts WHERE id=277067 |
0.00184 | SELECT id FROM punbb_posts WHERE topic_id=26511 ORDER BY posted |
0.00057 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=26511 AND t.moved_to IS NULL |
0.00015 | SELECT search_for, replace_with FROM punbb_censoring |
0.00142 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=26511 ORDER BY p.id LIMIT 0,25 |
0.00088 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=26511 |
Total query time: 0.00758 s |