Súlyos, távolról kihasználható sebezhetőség a bash-ban

 ( trey | 2014. szeptember 25., csütörtök - 7:29 )

Súlyos, távolról kihasználható sebezhetőséget fedeztek fel a bash-ban. A HUP fórumból:

MrBee írta:
http://linux.slashdot.org/story/14/09/24/1638207/remote-exploit-vulnerability-found-in-bash

A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

Idézet:
Teszt:

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

Patch elott:

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

Patch utan:

$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Itt pedig disztronkent:

Novel/SuSE
Debian
Ubuntu
Redhat/Fedora
CentOS

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Ubuntu 14.04 LTS-ben már megérkezett a frissítéssel a javítás.

--
trey @ gépház

Ubuntu 12.04.5-be is megérkezett a patch.

==================================================================
Ubuntu 12.04, 14.04, AIX, Windows XP Home, Windows 7 Pro, Win7 Starter

Ööö... Ebben mi a remote? (nem, nem a problémát kérdőjelezem meg, hanem a helyét...)

Ez ettől még nem remote. Nem a bash-ben van a távoli futtatás lehetősége, hanem egy 3rd party dolgon keresztül. Ettől ez még local exploit. Ennyi erővel php-ból meghívva is remote exploit?

Értem amit mondasz. Mindazonáltal a jellegét tekintve ez sokkal súlyosabb annál, hogy akként hivatkozzunk rá, hogy "local vulnerability". A jelen rendelkezésre álló infók szerint indokolt a "távolról kihasználható" szerepeltetése.

--
trey @ gépház

PHP-bol is elvileg hivhatsz olyan wrappert ami a shell-re maszik vissza, ami innentol meg tamadasi faktor.
CGI scriptek hasonloan problemasak.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Nem azt mondtam, hogy nem támadási faktor. Nem is azt, hogy nem kritikus. Annyit mondtam, hogy ez önmagában nem távoli hiba...

Tavoli, max nem bash-ben (mivel az nem halgatozik egyik TCP porton se :)), de ettol meg eleg sok progi van ami tavolrol elerheto, es bash-t hiv. Amugy ha ez nem lenne eleg, localban is eleg erdekes dolgokat lehet ezzel csinalni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Magától nem hallgatózik, de ugye a lehetőség adott rá mondjuk shellben megírt webszerver (vagy bármi más) esetén :-)

Ennyi erobol akkor minden local sebezhetoseg remote is egyben, mert ugye ssh-bol is mukodik.

Szerintem pedig egyszerű a magyarázat.
Lényegében egy változóba elraksz egy stringet, amiről abszolút nem feltételezi senki, hogy annak bármilyen része kérés (mondjuk eval) nélkül végre lesz hajtva. Mivel rengeteg helyen üzemszerűen kerül kívülről untrusted string környezeti változóba, ezért a hatását tekintve nagyon is remote, még akkor is, ha a bash önmagában nem fogad távolról kapcsolatot.
---
Régóta vágyok én, az androidok mezonkincsére már!

Debian wheezyre is kinnt van a frissítés. Rakat szerveremről küldött az unattended-upgrades emailt.

Úgy tűnik én tegnap megkaptam (Debian Wheezy)

Start-Date: 2014-09-24 19:36:59
Commandline: apt-get upgrade
Upgrade: bash:amd64 (4.2+dfsg-0.1, 4.2+dfsg-0.1+deb7u1), libapt-inst1.5:amd64 (0.9.7.9+deb7u4, 0.9.7.9+deb7u5), apt-utils:amd64 (0.9.7.9+deb7u4, 0.9.7.9+deb7u5), apt:amd64 (0.9.7.9+deb7u4, 0.9.7.9+deb7u5), libapt-pkg4.12:amd64 (0.9.7.9+deb7u4, 0.9.7.9+deb7u5)
End-Date: 2014-09-24 19:37:12

A squeeze-lts is megkapta reggelre.

Jessie késett, délután még nem volt, de most már van.
________________________________________
"The vision of Christ that thou dost see
Is my vision’s greatest enemy."

lenny-re nem jön

:-)

Legnagyobb sajnálatomra etch-re se jön.
Sajnos van egy lecserélésre váró szerver a céges parkban, csak valahol elakadt a projekt. Ez a hiba viszont érinti azt is. :(
Meg van egy lenny is még, amit meg php okból kifolyólag nem lehet automatikusan frissíteni.

Én Etch-re ma fordítottam ez alapján, hogy frissítsem a 3.1.17-es basht 3.1.18-ra :
http://superuser.com/questions/816958/how-do-i-build-bash-to-patch-against-shellshock-and-test-it-before-installing-it
De közben fel kellett telepítenem egy pár dolgot, amit hiányolt a telepítés közben, nem elég csak a gcc (bár itt sokaknak biztos nem újdonság itt, csak én vagyok kezdő :) ).
Az a lényeg, hogy a telepítésnél a configure paramétereként, nem a fickó által megadott elérési utat kell megadni, hanem a / -t . Arra viszont pont jó a /tmp/... hogy meglesd rendben lefordult-e és még fut is.

A telepítés után annyit vettem észre, hogy vannak putty alatt tördelési gondok, ha nem elég széles az ablak.

Nos a 3. fordítás után rájöttem, hogy ez csak az első patchet tartalmazza, ettől az új csekkerrel még létre jön a fájl!
Ez tehát csak félkész!
MOD:
Utólag megtaláltam egy fejlesztői blogot, és kézzel meghakkoltam a forrást.
http://www.openwall.com/lists/oss-security/2014/09/26/1
Itt minden verzióhoz meg van a leírás.
Az első patchsorozatot persze előtte érdemes belepakolni, mert azok sok dologba belenyúlnak.

Mondjuk a bash oldalán nem írták (vagy nem tűnt fel), meg ha jól rémlik a 18-as patch-ban sem (igaz csak a 3.1-es utolsó patch-át néztem), hogy csak félkész.

Én is megpatkoltam a 19-essel.
Ez akkor még experimentál? Csak rákukkanttott a fejlesztő a beküldött patch javaslatra és azt mondta, hmm, tényleg, erre nem is gondoltam, és nesztek akkor? Vagy nem jól értettem?
Na mindegy, ha gubanc van, akkor megvan még a lefordított 18-as és még a 17-es is. Legrosszabb esetben egy live cd-ről bootolva visszarakom :D

Valóban jött frissítés, ámde:

Retrieving bug reports... Done
Parsing Found/Fixed information... Done
grave bugs of bash (4.2+dfsg-0.1 -> 4.2+dfsg-0.1+deb7u1)
#762760 - bash: still vulnerable to environment exploits
Merged with: 762761
Summary:
bash(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...]

------------------------

Nálam is frissült reggel.


openSUSE-2014-559 - bash: security and bugfix update

bash was updated to fix a critical security issue, a minor security issue and bugs:
In some circumstances, the shell would evaluate shellcode in environment variables passed at startup time. This allowed code execution by local or remote attackers who could pass environment variables to bash scripts. (CVE-2014-6271)
Fixed a temporary file misuse in _rl_tropen (bnc#868822) Even if used only by developers to debug readline library do not open temporary files from public location without O_EXCL (CVE-2014-2524)
Additional bugfixes: 
- Backported corrected german error message for a failing getpwd (bnc#895475)
- Add bash upstream patch 47 to fix a problem where the function
that shortens pathnames for $PS1 according to the value of $PROMPT_DIRTRIM uses memcpy on potentially-overlapping regions of memory, when it should use memmove. The result is garbled pathnames in prompt strings.
- Add bash upstream patch 46 to fix a problem introduced by patch
32 a problem with "$@" and arrays expanding empty positional parameters or array elements when using substring expansion, pattern substitution, or case modfication. The empty parameters or array elements are removed instead of expanding to empty strings ("").
- Add bash-4.2-strcpy.patch from upstream mailing list to patch
collection tar ball to avoid when using \w in the prompt and changing the directory outside of HOME the a strcpy work on overlapping memory areas.
Hivatkozások:
868822 (bugzilla) : VUL-1: CVE-2014-2524: bash,readline: temporary file misuse in _rl_tropen
895475 (bugzilla) : locale de_DE.utf8 has wrong translations
896776 (bugzilla) : VUL-0: CVE-2014-6271: bash: unexpected code execution with environment variables
CVE-2014-6271 (cve) : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271
CVE-2014-2524 (cve) : http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2524


openSUSE 13.1 x86_64.

Bash, alkoss, gyarapíts: s a haza fényre derűl!

Az AIX-nél az IBM-re várhatunk még pár hónapot, de úgy tűnik, az egyik legjobb 3party packager, Michael Perzl már frissített:

bash-4.3-7.aix5.1.ppc.rpm 24-Sep-2014 23:30
bash_64-4.3-7.aix5.1.ppc.rpm 24-Sep-2014 23:34

És valóban, ez már a patchelt verzió.

Csak szolok, hogy ez a patch se up-to-date meg tudtommal, szoval lehet meg kell varni a kovetkezo verziot.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

A fentit legalábbis javítja.

Na kis összefoglaló, hogy mi is ez, miért is van, és hogy az első kiadott javítás miért nem ideális:
http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Update:

http://www.perzl.org/aix/index.php?n=Main.Bash

AIX-re kijött a második patch is perzl.org -on

IBM is kiadta a javitast: http://www-01.ibm.com/support/docview.wss?uid=isg3T1021272 (Az AIX Toolbox link meg nem frissult)
-> ftp://ftp.software.ibm.com/aix/freeSoftware/aixtoolbox/RPMS/ppc/bash/bash-4.2-2.aix6.1.ppc.rpm
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

dupla
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Rémlik, hogy nemrég frissült a bash Mint 17 alatt is.


Linux Mint 17 Cinnamon 64-bit

Tavis Ormandy szerint a hiba frissítés után is megvan: https://twitter.com/taviso/status/514887394294652929

Kipróbáltam Linux Mint 17-en, frissítés után, a hiba továbbra is fennáll.

-------------------------
Trust is a weakness...

nálam nem, igaz, nem is Mint :)

Az eredeti, fenti példa működik-e?

Frissítésig működött, aztán ugyanaz már nem. Ormandy "megoldása" viszont továbbra is legjobb esetben information leak, legrosszabban unathorized access.

-------------------------
Trust is a weakness...

Igen, en is ebbol indultam ki.
Viszont most kicsit en is elbizonytalanodtam az OSS trhread-et olvasva:
Itt jelentettek: http://seclists.org/oss-sec/2014/q3/671 (Wed, 24 Sep 2014 23:27:09 +0200)
Itt viszont mar patchet dobtak ra: http://seclists.org/oss-sec/2014/q3/690 (Wed, 24 Sep 2014 23:01:34 -0400)

Na most ha jol szamolom, akkor a patch elerheto lett 5,5 oraval a report utan.
Az perlz.org-os AIX csomag (ftp://www.oss4aix.org/compatible/aix61/bash-4.3-7.aix5.1.ppc.rpm) meg 24/09/2014 23:30:00-kor lett kitolva, de TZ az nincs megjelolve, szoval barmelyik verzio elofordulhat.
Reprodukalni viszont nekem se sikerult ezzel a verzioval a twitteres hibat.

____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Érdekelne, hogy Red Haten műxik-e frissítés után Ormandy találmánya. Nekem valami azt súgja, hogy a dash-shel is gondok vannak, ami a Linux Mint alapértelmezett shellje:

sh4d0w@wife ~ $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test
sh4d0w@wife ~ $ env x='() { (a)=<\' bash -c "cat /etc/issue";
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
bash: /etc/issue: Permission denied
sh4d0w@wife ~ $ env x='() { (a)=<\' sh -c "cat /etc/issue";
Linux Mint 17 Qiana \n \l
sh4d0w@wife ~ $ which sh
/bin/sh
sh4d0w@wife ~ $ ls /bin/sh
lrwxrwxrwx 1 root root 4 jún 11 17:54 /bin/sh -> dash
sh4d0w@wife ~ $ ls /bin/dash
-rwxr-xr-x 1 root root 121272 febr 19 2014 /bin/dash

MOD: szóval, úgy tűnik, a bash javított kiadása a jelenleg ismert hibákra nem érzékeny, viszont a dash igen.

MOD2: dash sérülékenység megerősítve:

sh4d0w@wife ~ $ env x='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
bash: x: line 1: syntax error near unexpected token `='
bash: x: line 1: `'
bash: error importing function definition for `x'
still vulnerable :(
sh4d0w@wife ~ $ env x='() { (a)=>\' sh -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("
echo vuln
still vulnerable :(

-------------------------
Trust is a weakness...

VPS-emen (CentOS,x86) ma frissult a bash (bash-4.1.2-15.el6_5.1.i686); ez meg sebezheto az utobbi modon:
$ rm echo 2>/dev/null; env X='() { (a)=>\' sh -c "echo cat /etc/issue" 2>/dev/null; cat echo
CentOS release 6.5 (Final)
Kernel \r on an \m
$ ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Sep 25 17:18 /bin/sh -> bash
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ugye a bash és dash tesztek előtt mind a kétszer kitörölted az "echo" nevű fájlt? Csak mert a második teszt simán lehet fals potitív :-P
Szerk, bocs sh4d0w808-nak ment volna.

RHEL-re rakd fel az újabb (mai, bash-3.2-33.el5_11.4.x86_64.rpm, bash-4.1.2-15.el6_5.2.x86_64.rpm, satöbbi) frissítést, azzal már nem megy a

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

sem.

Valami rendes ember megmondaná, hogy mit kellene látnom, ha jó, és mit akkor, ha rossz?

$ env X='() { (a)=>\' sh -c "echo date"; cat echo
date
cat: echo: No such file or directory

szerintem nálad jó

------------------------------------------
"Nincs ez el**szva, csak másra lesz jó!"

Köszi -- ez azért lehet, mert én még az első patch-et sem töltöttem be... (talán kibírok egy-két napot, mire kialakul egy konszenzusos állapot)

az sh nálad micsoda? próbáld ki "bash -c" -vel a közepén. Az, hogy nálad nem hibás egy régebbi bash, míg másütt igen, az kevésbé valószinű, pláne, hogy például a cygwin-ben is ott figyel a hiba.

Szerintem meg pont nem. Ha jó lenne, nem futna le az echo parancs, ami a shell hívása után szerepel.

-------------------------
Trust is a weakness...

az sh nálad mire mutat pontosan? bash/dash/zsh/etc ?
Illetve probald meg pls ezzel a paranccsal leellenorizni:
$ rm echo 2>/dev/null;env X='() { (a)=>\' sh -c "echo date"; ls -l echo;cat echo

Ha a file letrejon, akkor sebezheto.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Az NSA adott mar ki nyilatkozatott, hogy ennek a bug-nak a letezeserol sem tudtak? :D

Routert, telefont ez nem érinti?

Ha ilyesmi eszközök linux-szerűek is, jellemzően busybox = ash van bennük, amibe ilyen szofisztikált funkciók (szó szerint) talán sohasem voltak.

Az init hal meg utoljára! :)

Azért lcamtuf értekezését elolvasva, megint az jött le nekem, hogy a fszé' kellett a bash fejlesztőinek megerőszakolni a rendszert ezzel az ökörséggel, hogy exportálható fv, aminek az implementálása egy jól sikerült - és amúgy k nagy inkompatibilitást jelentő - hack segítségével történik. Mer ugye ha nem találják ki ezt az ökörséget, hogy az exportálható fv igazából egy exportált változó, aminek úgy kezdődik a tartalma, hogy "() {" - de már bocsánat, miért is nem rakhatok bele a változóimba akármekkora marhaságot? Oszt majd a *programom* csinál vele amit akar. (De nem a shell.)

(Ha félreértem, akkor nyugodtan FIXME.)

Anélkül, hogy pontosan érteném a részleteket, kialakult egy olyan érzésem, hogy a 'még mit lehetne beletennia programba, hogy még kúlosabb legyen' eszméje vett erőt a derék fejlesztőkön...

[nem is szólva arról, hogy a jámbor userek, akik rászoknak a nemszabványos bővítményekre, mennyire kellemetlenül fogják érezni magukat, ha valami mást kell majd használni... például mert a biztonsági felelős azt mondja, hogy na jó, most akkor átmenetileg visszalépünk a bash2-re (vagy ksh-ra, ha szigorúbb)]

Nekem is megfordult a fejemben a ksh használata. De amit eddig találtak, azt meg is peccseltem.

"A probléma azért különösen súlyos, mert a Bash (ami a Bourne again shell rövidítése) a nyílt forráskódú Apache webszervernek is része, márpedig Apachet elég sok webszájt használ."

:)

http://444.hu/2014/09/25/tobb-szazmillio-gepet-fenyeget-a-halalos-bug-a-shellshock/

--
L

Ettől a cikktől egy enber meghalt, ketten könnyebben megsérültek.

na ezt kiprobalom, koszi
--
A legértékesebb idő a pillanat amelyben élsz.
https://sites.google.com/site/jupiter2005ster/

Es Debianon tegnap este kijott a frissites frissitese...

-------- Továbbított üzenet --------
Tárgy: [SECURITY] [DSA 3035-1] bash security update
Újraküldés dátuma: Thu, 25 Sep 2014 21:19:03 +0000
Újraküldés feladója:

Dátum: Thu, 25 Sep 2014 21:18:46 +0000
Feladó: Salvatore Bonaccorso
Válaszcím:

Címzett:

-------------------------------------------------------------------------
Debian Security Advisory DSA-3035-1

http://www.debian.org/security/ Salvatore Bonaccorso
September 25, 2014 http://www.debian.org/security/faq
-------------------------------------------------------------------------

Package : bash
CVE ID : CVE-2014-7169
Debian Bug : 762760 762761

Tavis Ormandy discovered that the patch applied to fix CVE-2014-6271
released in DSA-3032-1 for bash, the GNU Bourne-Again Shell, was
incomplete and could still allow some characters to be injected into
another environment (CVE-2014-7169). With this update prefix and suffix
for environment variable names which contain shell functions are added
as hardening measure.

Additionally two out-of-bounds array accesses in the bash parser are
fixed which were revealed in Red Hat's internal analysis for these
issues and also independently reported by Todd Sabin.

For the stable distribution (wheezy), these problems have been fixed in
version 4.2+dfsg-0.1+deb7u3.

We recommend that you upgrade your bash packages.

Further information about Debian Security Advisories, how to apply
these updates to your system and frequently asked questions can be
found at: https://www.debian.org/security/

Mailing list:

--
To UNSUBSCRIBE, email to

with a subject of "unsubscribe". Trouble? Contact

Archive: https://lists.debian.org/E1XXGR4-00012y-7y@master.debian.org

--
http://www.micros~1

Ubuntu 14.04-en is megérkezett.

--
trey @ gépház

Akkor dolgozhatnak tovább a következőn...:
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-7169

:-D

Az Apple is dolgozik a javításon.

--
trey @ gépház

A StackExchange-n leírják hogyan old meg magad, kár, hogy nem igazán segít.

Ave, Saabi.

Chet Ramey, the maintainer of bash, said in a post to Twitter that he had notified Apple of the vulnerability several times before it was made public, "and sent a patch they can apply. Several messages." So it's not certain why Apple hasn't already packaged that fix for release, other than Mac OS X uses version 3.2.51.(1) of GNU bash, released in 2007; the current GNU release of the shell is bash 4.3. However, the current version is released under the GNU Public License version 3 (GPLv3). Apple has avoided bundling GPLv3-licensed software because of its stricter license terms, even dropping the open-source Windows networking service Samba from OS X server in 2011 because Samba had shifted to a GPLv3 license. Therefore, although patches for the vulnerability have now been pushed out for most open-source operating systems, Apple executives may feel they have to have their own developers make modifications to the bash code."

http://arstechnica.com/security/2014/09/apple-working-on-shellshock-fix-says-most-users-not-at-risk/

--
trey @ gépház

Az "oldd meg magad" tanács nem old meg semmit :)

mondom: _HOGYAN_ old meg magad. Most nézem, hogy a gnu.org-on megjelent a patch a 3.2-es bash-hoz, tehát aki nem akar az Apple-ra várni, az lecserélheti maga a basht megfelelőle. Aki persze csak sírni szeret, meg ujjal mutogatni, az tegye ezt, ha neki jól esik.

Ave, Saabi.

Sziasztok!

Bocsi, de ebben hol van, hogy az X változót a Bash dolgozza fel?
A '-c' jelenti az új sort?

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

Kipróbáltam és patch után már nekem se írta ki, hogy 'vulnerable'

RTFM. man env ; man bash
Az env a paramétereként kapott változóértékadásokkal bővített (esetleg szűkített - lásd -u opció) környezetben futtatja a szintén paramétereként kapott parancsot. (Ami fenti példában azt jelenti, hogy csinál egy X nevű környezeti változót, és úgy futtatja a shellt.

A bash pedig -c opció esetén a paraméterként kapott parancsot futtatja.

A nagyobb baj, hogy fenti teszt már az első patch után jónak jelzi a bash-t, míg a sokkal gusztustalanabb teszt szerint lehet, hogy még mindig hibás. Próbáld ki a másik tesztet is:

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

Amennyiben sok hibaüzenet után az utolsó sorban majdnem a pontos dátumot látod, és lett egy echo nevű fájlod, akkor még mindig hibás bash van a rendszeredben.

A gusztustalanabb esetre: CVE-2014-7169, és újabb javítás - RHEL-nél ma reggel már erre is kint volt a javítás.

És az egészre a NetBSD-sek megtalálták az elméletileg tökéletes megoldást: bash fordítási időben letiltható a csába ez az egész exportált shell-függvény-marhaság. (FreeBSD-portsba ma este bele is került.) Részletesebben itt.

Régi gépre, régi RPM alapú OS-el kizárólag tűzoltásként kicsomagoltam egy .deb bash-static-ot. Jó nagy, de ha valakinek még nem érkezett frissítés, ez a megoldás jól jöhet.
http://launchpadlibrarian.net/185514036/bash-static_4.3-7ubuntu1.1_i386.deb

---
JMP $EA31

[ ...és már 10 éve regisztrált HUP felhasználó :) ]

(Innen.)

env ls='() { echo vulnerable; }' bash -c ls

Csak hogy egy szép példáját lássuk az értelmetlenül megtervezett, majd még értelmetlenebbül kivitelezett fícsöritisz-nek.
(Van ember, aki használ exportált shell-függvényt? Nem gondolta még, hogy át kellene alakítania a kódját? Bakker, a Korn-shell-ben is vannak durva dolgok, pl. az autoload function, de vizsgakérdésen kívül nagy eséllyel a kutya nem használja őket. Pedig vannak szép nagy cégek is, akik Korn-shell-t használnak.)

Továbbgondoltam ezt az egészet. A bash valamelyik fejlesztője kitalálta azt, hogy ha egy környezeti változó a "() {" karakterekkel kezdődik, akkor azt shell-függvénynek veszi. Gratulálok. Eredménye:

x='() { alma;}'
export x

műveletnek *nem* az lesz az eredménye, hogy az alshellben lesz egy x nevű változóm egy hülye értékkel, hanem lesz egy x nevű parancsom (ami amúgy az alma utasítást futtatja le). Hát kösz, egészen új utak nyílnak a rendszer (és a kollégák) megőrjítésének irányába.

Viszont azt már rég tudjuk, hogy környezeti változót nem szabad untrusted inputból elnevezni, mert ezzel számos módon vissza lehet élni, ebben sok meglepetés nincs.

Persze én se használtam még ezt a fícsört az életbe, tényleg csak potenciális gotcha.

Ez igaz, csak míg régebben a dolog úgy nézett ki, hogy ha egy szkript elejére odatetted azt, hogy

PATH=/bin:/usr/bin
export PATH

akkor nyugodtan hivatkozhattál az ls, find, sed és grep parancsokra simán elérési útvonal nélkül. Viszont ezzel a baromsággal, hogy exportált fv, gyakorlatilag elvesztetted ezt a lehetőséget. (Pont az volt a jó az alias-ban és a shell-függvényben, hogy abban a shellben élt, amelyikben létrehozták. Ráadásul ezzel az agyament megvalósítással sikerült elérni, hogy gyakorlatilag nem lehet úgy megírni egy parancsfájlt, hogy a legcsekélyebb esély legyen az átláthatóságra, hisz minden rohadt "parancs" használatát meg kell előzzön vagy egy "unset parancs" (ezzel megszüntetjük az esetleg megörökölt változót), vagy a shell "builtin", esetleg "command" parancsa, ezzel próbálva meg biztosítani azt, hogy nem az ilyen felüldefiniálások legyenek használatban. (Hány ember ír úgy shell-szkriptet, hogy ezekről a lehetőségekről semmit nem tud?) És akkor most jön a trükk:

$ unset='() { echo nem jo;}' ; export unset
$ command='() { echo nem jo;}' ; export command
$ builtin='() { echo nem jo;}' ; export builtin
$ bash
bash$ unset
nem jo
bash$ command
nem jo
bash$ builtin
nem jo
bash$

Kész meghaltam, nem tudom ezt a faszságot kiküszöbölni. Illetve a shell saját parancsait nem tudom használni (hisz bármelyik felül lehet definiálva), a külső parancsait legalább elérési útvonallal megadva használhatnám. Hát köszi.

Nem is tudtam, hogy a bash egy funkcionális nyelv. :)

Van másik!

https://access.redhat.com/security/cve/CVE-2014-7186
https://bugzilla.redhat.com/show_bug.cgi?id=1146791

https://access.redhat.com/security/cve/CVE-2014-7187
https://bugzilla.redhat.com/show_bug.cgi?id=1146804

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Bevallom, azt hittem, hogy a 4.3.27-tel nyugvópontra jutott a történet, de most úgy látom, hogy három új patch is van...

bash43-028              01-Oct-2014 13:29   68K  
bash43-029              02-Oct-2014 22:14  1.8K  
bash43-030              05-Oct-2014 19:01   62K  

Kezdtem frászt kapni, de FreeBSD-re 6-án megérkezett. Mindenesetre kezd agyrémmé válni a dolog :-(