Kritikus hibák a nyílt forrású médialejátszókban

Bug

"Huston, mplayer got some vulns!" írja az exploit szerzője a proof-of-concept kódban. Nézzük el neki, hogy nem tudja leírni Houston városának nevét, hiszen ő hívta fel a figyelmet arra, hogy a múlt héten javított xine-lib akkori hibája érinti az MPlayer-t és a VLC-t is. A hiba a valós idejű adatfolyam protokoll (Real Time Streaming Protocol - RTSP) feldolgozó kódban található. A hiba lehetőséget adhat arra, hogy a rosszindulatú támadó ártó kódot küldjön az áldozat felé speciálisan összeállított RTSP adatfolyamon keresztül.

Az MPlayer és a VLC elmulasztja ellenőrizni a streamid DSP paraméter hosszát. Az ellenőrzés hiánya puffer túlcsorduláshoz vezethet, amelynek következtében a támadó képes lehet tetszőleges memóriaterület felülírására, kód futtatására.

Sem az MPlayer, sem a VLC nem javította még a hibát az eredeti cikk megírásáig. A Heise Security cikke szerint az összes nagyobb nyílt forrású médialejátszó kritikus sebezhetőségekben szenved jelenleg, így érdemes óvatosnak lenni.

Részletek itt.

( denes | 2008. 03. 27., cs – 20:49 )

oszinten szolva, en ugy vagyok vele, hogy orulok ha az mplayer lejatsza amit kell es kozben nem segfault-ol. en nem hiszem, hogy tul nagy kihivas lennes security hole-okat talalni az mplayerben/xine-ban/vlc-ben - de lehet, hogy tevedek. mindenesetre azt az idok kezdete ota megmondtak az mplayer listakon/doksiban, hogy aki root-kent futtatja az mplayert az finoman szolva nagyot teved.

- Use the Source Luke ! -

Nem tudom, hogy minek örülnék kevésbé. Egy távoli root-nak, vagy annak ha valaki "csak" letörölné a ~ könyvtáramat. Mivel az érték a ~ könyvtárban van, azt hiszem, egyik sem lenne jobb a másiknál. Úgyhogy aki azt hiszi, hogy csak a remote root a valami, az "finoman szólva nagyot téved".

--
trey @ gépház

"A támadót sokkal inkább anyagi haszonszerzés, és nem a káröröm vezérli."

Melyik támadót? Tipikusan a script kiddiet nem. Ezt a típust kielégíti annyi is, hogy kis holdudvarának elmeséli az IRC-n (természetesen screenshot-ot mellékel), hogy mekkora májer gyerek volt mert, tudott használni egy más által megírt sploit-ot.

"Ilyen szempontból többet ér a remote root."

Gondolom az ssh és gpg kulcsaim, a leveleim, meg a Mozilla password-jeim smafuk. De itt nem arról van szó, hogy melyik ér többet, hanem arról, hogy nem kell rálegyinteni, "áá, nem root-ként fut, oda se neki".

Nem beszélve arról, hogy egy csomó dolgot a gépen lehet futtatni !root-én is. Gondolok itt a mindenféle botnetre. Legalább annyira gáz.

--
trey @ gépház

Probald ki a KPlayer-t, nekem nagyon kellemes meglepetés volt!

MPlayer -re épül, de a GUI részét egy az egyben cseréli, és tapasztalatom szerint az mplayer gui része az igazán bugos, maga a lejátszó engine nagyon jó.

Kplayer gyors, stabil, (a film bármilyen tekergetése is realtime eredménnyel jár), és mindent megeszik köszönhetően az mplayer -nek.

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.

Aha... És szerinted az mplayer fölé gányolt GUI független egy mplayer-specifikus hibától?
Hogy értsd mekkora hülyeséget írtál: az MPlayernek mint lejátszónak nincs API-ja, a hozzá készült kezelőfelület programok az /usr/bin/mplayer (hogy érthető legyen) programot indítják és baszgatják ál-billentyűzet eseményekkel vagy slave módban (kivétel a gmplayer, de te nem erről írtál). Tehát ha valamin a sima MPlayer elhasal, a csillivilli GUI ezen nem fog segíteni... Amúgy ha lenne API meg libmplayer, akkor se feltétlenül lenne igazad, mert a lejátszást ilyen esetben SEM a kezelőfelület végzi, milyen meglepő...

oszinten szolva, en ugy vagyok vele, hogy orulok ha az mplayer lejatsza amit kell es kozben nem segfault-ol.

vö

Probald ki a KPlayer-t, nekem nagyon kellemes meglepetés volt!
MPlayer -re épül, de a GUI részét egy az egyben cseréli, és tapasztalatom szerint az mplayer gui része az igazán bugos, maga a lejátszó engine nagyon jó.

(nem a gui bugos, és tipp hogy Gyuszkon kívül senki meg se elmítette hogy az lenne)

Rögtön az első hozzászólás már offtopic volt (segfaultol az mplayer), válaszoltál rá, hogy KPlayer frontenddel jóvan stabilabb, próbálja ki azt.
Egyetlen szóval sem utaltam a biztonsági hibára, amelyről a cikk szól. Bár halkan megjegyezném, hogy mindezt bárki kitalálhatta volna ha nem állna rá csípőből a keze az offolásra/helyreigazítási mániára/flame -re.
Mert ha így lett volna, csak az első post, és az én postom lenne off.

http://gyuszk.homelinux.org

-- There is never time to do it right, but always time to do it over.

"Rögtön az első hozzászólás már offtopic volt (segfaultol az mplayer)"

nem offtopic, mivel sok segfault (ha nem is mind) valoszinuleg kihasznalhato biztonsagi res.
amugy nem hasznalok GUI-t, de a gyari tenyleg nem a legjobb (mar gyakorlatilag nem is tartjak karban evek ota), es abszolut elhiszem, hogy a KPlayer viszont jo frontend.

- Use the Source Luke ! -

( w4rp v | 2008. 03. 27., cs – 22:02 )

Mplayerhq-n az utolsó 4 hír buffer/stack overlow vulnerability bejelentés.. szóval nem hiszem, hogy ez túl meglepő volna :)
Ha valaki túléli, hogy csak offline lát mozgóképet, letilthatja forditásnál (mint a korábbi CDDB-sebezhetőséget, akármit)

( arpi_esp v | 2008. 03. 27., cs – 23:46 )

Emlekeztetnek mindenkit arra a tenyre, hogy az mplayerben a kezdetek ota a sebesseg volt az elsodleges szempont, es nem a stability (securityrol meg nem is volt szo sose). Akik nem ma kezdtek, meg emlekezhetnek, hogy kb a 0.20-ig az mpeg lejatszas ugy volt stabilizalva, hogy egy sighandler mindig automatikusan ujrainditotta a lejatszast segfaultkor, persze onnan ahol elszallt :)
Egyszeruen ha beepitettuk volna az osszes szukseges ellenorzest (vagy 10 fele if() minden egyes bitre) a codecekbe, akkor min. 30-40%-al lassabb lett volna a dekodolas, ami azt eredmenyezte volna, hogy a celeron 300 koruli gepeken nemhogya dvd lejatszas, de meg a divx se ment volna.
Azota annyi valtozott, hogy az ffmpeg/libavcodec tartalmazza ezeket az ellenorzeseket, lehet is osszehasonlitani a libmp3 vs ffmp3, vagy a libmpeg2 vs ffmpeg12 codecek sebesseget... igaz, a mai cpu-kon mar nem nagyon szamit a sebesseg.

Persze ez nem mentseg a halozati retegben levo overflow hibakra, de azt azert jo latni, hogy hiaba lenne secure a haloztai reteg, ha a codecekben siman lehet szazaval talalni ilyen hibakat, tehat sz@rt sem erne az egesz. Epp ezert sz@rik is ra minden fejleszto...

A mostani xine hibajavitasrol meg annyit, hogy igazan szolhattak volna a xine-osok a tobbi fejlesztonek, hogy javitsak a hibat... mi is szoltunk nekik mindig ha olyan kodban volt bug amit tolunk vettek at (es igy oket is erinti), es meg joval publikalas elott.

A'rpi