Zahy blogja

Szokásos heti FreeBSD Sec Adv-ok

Úgy látszik a FreeBSD népszerűvé vált, hisz mi mást jelenthetne az, hogy immár heti (no jó, kétheti) rendszerességgel látnak napvilágot újabb és újabb biztonsági javítások. Azt mondjuk nem értem, hogy miért mindig egy hullámban több, de nyilván kéthetente egy-egy esetleges rendszer/szolgáltatás kiesést könnyebb magyarázni, mint mondjuk 4-naponta - ebben azért van ráció. (Az meg, hogy közben tovább maradnak támadhatóak a gépek, azt az MS-féle peccs-kedd jól példázza: nem számít.) No lássuk:

Az első az igazi nyalánkság, DOS az sshd-ben. FreeBSD-specifikus, és a kerberizált sshd linkelési problémája.

4 újabb FreeBSD Security Advisory

Kicsit gyanús volt, hogy a legutolsó RC óta kicsit hosszabb idő telik el, mint az várható lenne, aztán az éjszaka folyamán megjött a magyarázat 4 db SA képében.

- rtsold IPv6-os hálózatba konfugurálódás közben egy kihasználható, de elvben nagyon nehezen távoli kódfuttatást is lehetővé tevő hiba a szokásos "hossz-nem-ellenőrzés" miatt.

- routed RIP-et használó hálózatban távolról ki lehet gyilkolni a routed-et, ezzel a routing tábla a továbbiakban nem módosul, majd szépen elérhetetlenné válik az adott router mögötti hálózat

Android App2SD nem értem

Két teló: SGS2 és SGS3Mini. Ugyanúgy gyári 4.1.2 (nem rootolt) van rajtuk. És ennek ellenére a Beállítások / Alkalmazáskezelő / tetszőleges alkalmazás (pl. Adobe Reader)-re ha rányomok, az SGS2-n ott a lehetőség, hogy Áthelyezés SD-kártyára / eszközmemóriába (attól függően, hogy most hol van), de az SGS3M-en ilyen funkció nincs. És ugye most jutott el ez a hulladék odáig, hogy az 1,8 MB-os Wifi analyzert nem tudja frissíteni, mert tele van a "diszkje". WTF????

A teljes reseten kívül vajon van-e peccsek takarítására valami módszer? Keresem, de ez nekem nem világos.

Vége az animgifnek?

Azt írja az újság, hogy helyette majd GIFV lesz. És mi a helyzet az Animated PNG-vel, vagy az MNG-vel? (Ja, nekem a bemutatókép O/A valahogy nem akar animálódni :-( . FF és Chromium alatt igen.)
Ja, és a "gyorsan megtelnek tőle a szerverek" az olyan szép ...

Shell bug, de most zsh

Úgy érzem, a környezet kezelésének leprogramozása nem minden nehézség nélküli. Legalábbis ha abból indulok ki, hogy a shelshock kapcsán korábban David Korn is írt egy levelet, hogy javított valamit a ksh93-ban, most meg ezt olvasom:
====
zsh update to 5.0.7

Note from upstream release note:

Note in particular there is a security fix to disallow evaluation of the initial values of integer variables imported from the environment (they are instead treated as literal numbers). That could allow local privilege escalation, under some specific and atypical conditions where zsh is being invoked in privilege elevation contexts when the environment has not been properly sanitized, such as when zsh is invoked by sudo on systems where "env_reset" has been disabled.
====
Nehéz élet a programozó élet.

Új VMware verzió a láthatáron?

Mostanában nem nagyon követem őket, de mivel megjött az esedékes: "most vegyél akciósan VMware Workstation 10-et, és akciós áron - izé ingyenesen - kapod majd meg a 11-et" levelük, ebből arra a következtetésre jutottam, hogy hamarosan új szerver verzió megjelenése várható. Legalábbis az elmúlt néhány év tapasztalata az, hogy ezek ilyen sorrendben követik egymást. Csak azt nem szoktam tudni az ilyen levelek alapján eldönteni, hogy mi lesz a verziószáma. (5.0, 5.1, 5.5 -> ebből nekem mondjuk 7.13 teljesen logikus következtetésnek tűnik. No jó, nem.)

Átvitel 2.

Majd 4 éve egyszer már eltűnődtem rajta, hogy mi a francért nem használnak annyian Transmission-t mint várnám. Ma pont ugyanezen okokból a fordítottján csodálkoztam el. Amíg jött a TBBT s08e04, az volt a meglepő, hogy a kb 60 peer több mint a fele mellett azt láttam, hogy Transmission akárhányas. Gondoltam, akkor legyen egy korrekt "mérés", egy adott pillanatban számoljuk meg, hogy hányan vannak és hányan használnak közülük Transmission-t. Erre a legjobb eszköz szerintem a tpipe. No de valamilyen érthetetlen okból nem volt telepítve. Aztán nem sikerült a telepítése. Aztán nem találtam a portok között. És a végén kiderült, hogy nincs is megportolva FreeBSD-re. Forrás itt. Gyors Makefile kukkolás, gcc-mint-CC kikommentelés, mehet a make all. Elhasal a linkelésnél. Fejvakarás, első kisérletként -O4 átállít -O3-ra, majd másodikra egy huszáros vágással kézzel lefordítom (végül is egy cc -o tpipe tpipe.c még megy). Jöhet a "mérés":

transmission-remote -t 1 -ip | tpipe 'fgrep -c -e Transmission -e Client > /dev/tty' | wc -l

És a meglepetés, kb a negyede (ebben a pillanatban 7 a 28-ból - illetve a fejléc - ez a Client sor, amit a wc is számol - miatt 6 a 27-ből). Igaz, közben már lejött, így aztán nem pont azt mértem, amit akartam. Nyilván azért tűnt el sok peer, mert ők Transmissiont használnak, és már bőven seedelenek. (Most meg 9 a 34-ből.)

Shellshock már megint

Látszólagos nem-érintettség okán nem nagyon követem az eseményeket, de pár szóban már összefoglaltam a véleményemet itt. Ellenben ezt láttam tegnap a freshports.org -on:

www/rt42 < 4.2.8 is vulnerable to shellshock related exploits through its SMIME integration.

Meg ezt:
rt42: RT is an industrial-grade ticketing system written in Perl

Azaz első ránézésre bejött az, hogy látszólag rohadtul nem bash-hoz kötődő szoftverben van rés a bashbug kapcsán. Visszatérve eredeti véleményemhez (argumentum ad nauseam) : "Ceterum censeo bash delendam."

A Shellshock margójára

Ahogy újabb és újabb infókat csipegetek fel, úgy fogom egyre jobban a fejemet. Pár apróság, amitől a hajam égnek áll:

- a bash (a javítás előtt) engedélyezte olyan shell-függvény létrehozását, aminek a nevében / szerepel, pl egy peccseletlen bash-ban ez megtehető:

bash$ function /bin/ls { echo jaj ;}
bash$ type /bin/ls
/bin/ls is a function
/bin/ls ()
{
echo jaj
}
bash$ /bin/ls
jaj
bash$ exit

Ez már önmagában agyrém.

- ugye ami igazán szép, hogy kitalálták az exportálható shell-függvény című agybajt. Mivel a környezet UNIX/Linux alatt csak változók (izé=ecet) átadására volt felkészítve, zseniális trükköt használtak agyszüleményük megvalósítására. Ha egy függvényt az "export -f fname" paranccsal exportáltak, akkor tulajdonképpen átkonvertálták változó értékadásnak, és azt a változót aztán exportálták. És hogy a dolog működjön, kellett egy második pont is. Ha a bash találkozott egy olyan környezeti változóval, aminek az értéke a "() {" karakterekkel kezdődött (így néz ki ugye egy shell függvény kezdete), akkor úgy döntött, hogy az ott egy ilyen exportált függvény, amit azon nyomban definiálni kellett - azaz létrehozta (visszakonvertálta) a változóból a parancsot. És persze amikor ez megtörtént, akkor ugyebár lefuttatott egy (vagy több) parancsot. Itt ráadásul elég trehány is volt a drága programozó úr/hölgy, kb leszarta, hogy a shell fv végét a záró kapcsos zárójel elég jól jelzi, ami utána van, annak nem nagyon kéne bármiféle értelmet tulajdonítani. (Ezt jól mutatta a legismertebb teszt.) Természetesen környezeti változó létrehozására elég sok lehetőség adódik, de az, hogy azt a "cél-alkalmazáson" kívül esetleg más saját hatáskörben megcsócsálja, arra az egyszeri ember max a dokumentált dolgokig szokott gondolni. Ez a fenti borzalom viszont nem volt dokumentálva (no jó, én nem találtam, persze ha valaki olvasta, nyugodtan dobhat egy linket).

Sötét hírek

- Már megint a fél város járhatatlan (mármint ahol én vagyok). Szerencse, hogy nem akartam menni sehova - igaz, az asszony igen.
- Most olvasom, hogy sikerült 4 db focimeccs kedvéért százmilliárdos focipályaépítési lehetőséget nyerni. Basszátok meg mindannyian, akik nem fogjátok fel, hogy nem erre a bohóckodásra kell ezeket a milliárdokat elszórni.

FreeBSD lokális repó használata

Van pár olyan szoftver a ports-ban, ami bináris csomagból nem érhető el (pl. licencprobléma miatt), ehhez jöhet jól. (Nálam pl. lame, meg a faac, stb.)

A parancsokat gyakorlatilag mind root-jogal kell futtatni, speciális beállítások esetén kb a make all az egyetlen, amit lehet normál felhasználóként (ezt jelzi a prompt)

Előkészítés, lokális csomag előállítása és megfelelő helyre rakása:

# mkdir -p /usr/ports/packages/All
# cd /usr/ports/audio/lame
# make all package
# mv work/pkg/lame-3.99.5_1.txz /usr/ports/packages/All/
# make clean

(Van olyan gépem???? amin van PACKAGES make-változó - /usr/ports/packages értékkel -, ekkor eleve megfelelő helyre került a csomag, és van olyan, ahol nincs ez a változó, ekkor kell a mv.)

pkg 1.3.7

Emlékeztető:

A hét végén esedékes csomagfrissítésnél erre érdemes lesz odafigyelni, ha nem akarok magamnak egy vagon tök fölösleges csomagletöltést. Ma még tudom, szombaton/vasárnap már nem fogok rá emlékezni.

Jav: FreeBSD Security Advisory-k

Élő TCP-kapcsolaton keresztüli esetleges információszivárgás, remote DOS (crash előidézése).
Szép.
(Noha azt írják, szenzitív adatok kinyerése extrém nehéz, azért érdeklődéssel várom, hány órán belül mutatják be a sajtó képviselőinek az ezt nagy valószínűséggel megvalósító kódot.)
Ja bocsánat, lassan esnek be az e-mailek, jött még kettő. Valamiért szeretik ezeket az SA-kat tömegesen piacra dobni.
Tehát:
devfs szabályok nem jutnak érvényre Jail-ben
és még egy kis vicces OpenSSL hiba, ha jól látok ki a reggeli csipa mögül, adatokat lehet csempészni egy SSL/TLS kapcsolatba (vattafakk???)

14.04 + DLNA

Ebéd után az egyik gépemre érdeklődésképpen felraktam az új LTS-t. A felrakás nem volt nagy durranás, de azért a vezető Linux desktoptól nem vártam volna, hogy még mindig nem tud gyárilag DLNA kliens lenni.
Van itt kérem Rhythmbox és Totem, de nincs fenn a dlna-plugin. Megjelent valami gnome-music, ami állítólag tud, csak épp nyoma nincs, hogy hogyan lehetne vele észrevetetni a szervert. A netes tanácsok alapján lett fenn coherence, de sem a RB, sem a Totem a plugin odamásolása és a coherence kézi indítása után nem látja. Állítólag a VLC is tudja már, de ő se lát semmit, ami emlékeztetne egy kicsit is az elérhető zenéimre.