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

Bug

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

http://linux.slashdot.org/story/14/09/24/1638207/remote-exploit-vulnera…

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.

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

( trey | 2014. 09. 25., cs – 08:30 )

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

--
trey @ gépház

( GoRien | 2014. 09. 25., cs – 08:54 )

Ubuntu 12.04.5-be is megérkezett a patch.

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

( iron v | 2014. 09. 25., cs – 09:13 )

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

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!"..

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!"..

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!

( ncc1701 | 2014. 09. 25., cs – 09:15 )

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

É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-agai…
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/?/...]

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

( WG | 2014. 09. 25., cs – 09:23 )

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.

( uid_6846 | 2014. 09. 25., cs – 13:55 )

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

( LGee | 2014. 09. 25., cs – 13:59 )

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!"..

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-impa…
____________________________________
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!"..

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/ba…
____________________________________
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!"..

( Turion | 2014. 09. 25., cs – 14:05 )

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

Linux Mint 17 Cinnamon 64-bit

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!"..

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!"..

( Smiley | 2014. 09. 25., cs – 20:14 )

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

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)]

( Celtic v | 2014. 09. 26., p – 07:14 )

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: debian-security-announce@lists.debian.org
Dátum: Thu, 25 Sep 2014 21:18:46 +0000
Feladó: Salvatore Bonaccorso
Válaszcím: debian-security@lists.debian.org
Címzett: debian-security-announce@lists.debian.org

-------------------------------------------------------------------------
Debian Security Advisory DSA-3035-1 security@debian.org
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: debian-security-announce@lists.debian.org

--
To UNSUBSCRIBE, email to debian-security-announce-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org
Archive: https://lists.debian.org/E1XXGR4-00012y-7y@master.debian.org

--
http://www.micros~1

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…

--
trey @ gépház

( xc0m v | 2014. 09. 26., p – 11:46 )

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.

( Zahy v | 2014. 09. 26., p – 18:58 )

(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.

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.

( BaT | 2014. 09. 26., p – 19:28 )

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