GoldenLine
Zaloguj się
Smaug T.

Smaug T.

Temat: [bash] CVE-2014-6271: remote code execution

http://seclists.org/oss-sec/2014/q3/650
Link do wypowiedziLink
Łukasz T.

Łukasz T. administrator
systemów, Grupa
Interia.pl

Temat: [bash] CVE-2014-6271: remote code execution

Połatane, dziękować.
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Twórcom skryptów CGI w bash'u podskoczyło ciśnienie ;)
Link do wypowiedziLink
Adam Rolok

Adam Rolok Technical Account
Manager

Temat: [bash] CVE-2014-6271: remote code execution

Dziękuję za info, bezpiecznik też czuwa: http://niebezpiecznik.pl/post/dziura-w-bashu/

Piękna podatność, pomysł z wykorzystaniem serwera DHCP do wstrzyknięcia na maszyny klienckie backdoor'a wyśmienity. Pewnie jeszcze przez długi czas lista podatnych maszyn będzie całkiem spora. Jest tak zawsze w przypadku systemów *nix'owych wykorzystywanych w domach przez nowicjuszy, gdzie nikt nie dba o aktualizację.

Co do serwerów, czasu jest niewiele. Poza tym pojawiają się już poprawki (auto update) w popularnych dystrybucjach.

Czekam na moduł do Metasploita.
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Napisali też o tym na dobrych programach. Najbardziej się uśmiałem z komentarzy pod artykułem, niektórzy siedzą przy aktualizacjach i klikają w panice "sprawdź" ;))) haha ;)

Osobiście często skrypty w ksh pisałem, taki typowo Solaris'owy. W Ubuntu domyślnie jest bash. Czasem przerabianie skryptów z ksh na bash potrafi dokuczyć ;)
Link do wypowiedziLink
Smaug T.

Smaug T.

Temat: [bash] CVE-2014-6271: remote code execution

Dariusz L.:
Osobiście często skrypty w ksh pisałem, taki typowo Solaris'owy. W Ubuntu domyślnie jest bash. Czasem przerabianie skryptów z ksh na bash potrafi dokuczyć ;)

Dlatego warto pisać skrypty w Almquist Shell, który jest bardzo blisko IEEE Std 1003.1 i z tego powodu dobrze portowalny pomiędzy shellami z rodziny Bourne. Jest to defaultowy shell na FreeBSD, NetBSD i Androidzie. Na Debianie znany jako dash(1).

Chociaż osobiście bardzo lubię bash(1), choćby z powodu takich rzeczy jak:



zork $ echo {1..100}

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100
Ten post został edytowany przez Autora dnia 25.09.14 o godzinie 16:14
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Andrzej K.:
Chociaż osobiście bardzo lubię bash(1)
Najlepej jak się człowiek przyzwyczi do bash i różnych skrótów, a później się loguje na maszynie Solaris'owej z ksh, albo wchodzi się do vi i nagle krzaki wyskakują w najmniej oczekiwanym momencie ;) hehe ;)
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Andrzej K.:
Dlatego warto pisać skrypty w Almquist Shell
Nie zawsze jest akurat wybór. Czasem człowiek loguje się na konto, gdzie domyślnym shell'em jest csh ;) i też facepalm ;)

EDIT:
Andrzej K.:
Almquist Shell, który jest bardzo blisko IEEE Std 1003.1 i z tego powodu dobrze portowalny pomiędzy shellami z rodziny Bourne.

Niestety dash też ma problem z:


print "\n"

Jak w skrypcie ksh masz dużo takich kwiatków to przy przeróbce na bash'a najszybciej zamienić to na: 


echo -e "\n"

Tylko trzeba to robić pojedynczo żeby nie machnąć przy okazji print'y zagnieżdżone w awk'u ;)Ten post został edytowany przez Autora dnia 25.09.14 o godzinie 17:44
Link do wypowiedziLink
Maciej G.

Maciej G. Projektant /
Programista, Famor
S.A.

Temat: [bash] CVE-2014-6271: remote code execution

Dariusz L.:
Andrzej K.:
Chociaż osobiście bardzo lubię bash(1)
Najlepej jak się człowiek przyzwyczi do bash i różnych skrótów, a później się loguje na maszynie Solaris'owej z ksh, albo wchodzi się do vi i nagle krzaki wyskakują w najmniej oczekiwanym momencie ;) hehe ;)

IMHO:
ksh -o vi

lub

ksh -o emacs

i po kłopocie. A vi to standard i jest na każdym Unix'e/Linuksie (nie jestem wrogiem nano BTW) więc warto znać tak, czy siak :)
Link do wypowiedziLink
Smaug T.

Smaug T.

Temat: [bash] CVE-2014-6271: remote code execution

Dariusz L.:
Andrzej K.:
Dlatego warto pisać skrypty w Almquist Shell
Nie zawsze jest akurat wybór. Czasem człowiek loguje się na konto, gdzie domyślnym shell'em jest csh ;) i też facepalm ;)

EDIT:
Andrzej K.:
Almquist Shell, który jest bardzo blisko IEEE Std 1003.1 i z tego powodu dobrze portowalny pomiędzy shellami z rodziny Bourne.

Niestety dash też ma problem z:


print "\n"





zork $ print

-bash: print: command not found


Print występuje tylko w Korn Shellu. Zgodnie z FAQ:



Q12.	Why does have print since echo already exists is is widely used?

A12.	The behavior of echo varies from system to system.

	The POSIX standard does not define the behavior of echo when

	the first argument beings with a - or when any argument

	contains a \ character.  This makes echo pretty useless for

	use in portable scripts.


A wracając do wątku to nie wszystko zostało połatane do końca i szykują się nowe patche...
Link do wypowiedziLink
Adrian Czerniak

Adrian Czerniak Administrator
Systemów Uniksowych

Temat: [bash] CVE-2014-6271: remote code execution

Nawet się już pojawiły.
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Andrzej K.:


Q12.	Why does have print since echo already exists is is widely used?

A12.	The behavior of echo varies from system to system.

	The POSIX standard does not define the behavior of echo when

	the first argument beings with a - or when any argument

	contains a \ character.  This makes echo pretty useless for

	use in portable scripts.
Ale też jak ktoś dużo koduje pod Solaris'em i w C/C++ to łatwiej mu się patrzy na print niż echo ;) Z printf nie ma takiego problemu, ale czasem nie potrzeba aż się bawić w taką skomplikowaną składnię i chce się jedynie nową linię wrzucić.
Andrzej K.:
A wracając do wątku to nie wszystko zostało połatane do końca i szykują się nowe patche...
Nie ma systemu w 100% bezpiecznego, ale ewentualne luki jest ciężko w praktyce wykorzystać na takim poziomie żeby mieć root'a. A to że skrypty CGI nie są bezpieczne to już było wiadomo 10 lat temu.
Link do wypowiedziLink
Smaug T.

Smaug T.

Temat: [bash] CVE-2014-6271: remote code execution

Bash to taka puszka Pandory...

http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unof...
Link do wypowiedziLink

konto usunięte

Temat: [bash] CVE-2014-6271: remote code execution

Andrzej K.:
Bash to taka puszka Pandory...
http://lcamtuf.blogspot.de/2014/09/bash-bug-apply-unof...
Ale wiesz Andrzej, większe znaczenie ma jak skrypt jest napisany, albo proces chodzący w tle. Można mieć jedynie nadzieję, że po załataniu "luk" (czy też możliwości jakie daje shell) da się jeszcze skrypty pisać ;)
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

porownaj directories on rem...




Wyślij zaproszenie do
Anuluj