Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Firefox 30.0 (Linux): RCE?
10-07-2014, 13:55 door Anoniem, 6 reacties
Eind juni (zie https://www.security.nl/posting/393341/Onderzoeker+ontdekt+20-jaar+oude+bug+in+Mars+Rover) werd bekend dat o.a. MPlayer2 gebruik maakt van een lekke implementatie van het Lempel-Ziv-Oberhumer (LZO) compressiealgoritme.
Vandaag verscheen op Full Disclosure (http://seclists.org/fulldisclosure/2014/Jul/36) een verwijzing naar een filmpje dat een RCE (Remote Code Execution) exploit laat zien in de actuele Firefox 30.0 versie (in elk geval onder Linux), naar verluidt als gevolg van de daarin aanwezige MPlayer2 code (voor zover ik weet komt deze niet voor in de Windows versie van Firefox).
Filmpje: https://www.youtube.com/watch?v=BcCDETzk4zc
http://www.openwall.com/lists/oss-security/2014/06/26/22 vermeldt CVE-2014-4609 en dat naast Firefox ook Iceweasel, Opera, Chromium, en Konqueror op Linux kwetsbaar zouden zijn.
Vandaag verscheen op Full Disclosure (http://seclists.org/fulldisclosure/2014/Jul/36) een verwijzing naar een filmpje dat een RCE (Remote Code Execution) exploit laat zien in de actuele Firefox 30.0 versie (in elk geval onder Linux), naar verluidt als gevolg van de daarin aanwezige MPlayer2 code (voor zover ik weet komt deze niet voor in de Windows versie van Firefox).
Filmpje: https://www.youtube.com/watch?v=BcCDETzk4zc
http://www.openwall.com/lists/oss-security/2014/06/26/22 vermeldt CVE-2014-4609 en dat naast Firefox ook Iceweasel, Opera, Chromium, en Konqueror op Linux kwetsbaar zouden zijn.
Reacties (6)
...naar verluidt als gevolg van de daarin aanwezige MPlayer2 code...
Volgens je laatste link zit het probleem in libav, een library die in heel wat software gebruikt wordt. In Debian heeft Iceweasel (Firefox zoals die in Debian gedistribueerd wordt) geen rechtstreekse afhankelijkheid daarmee. Je installeert afzonderlijk mediaspeler-plugins naar keuze. Een concreet voorbeeld:* Je installeert gecko-mediaplayer
* Die is afhankelijk van gnome-mplayer
* Die is weer afhankelijk van mplayer óf mplayer2 (beide voldoen)
En grappig genoeg zijn er geen *harde* afhankelijkheden tussen mplayer/mplayer2 en libavutil, er zijn alleen pakketten die *gesuggereerd* worden die weer van libavutil afhankelijk zijn. Ik heb het pakketbeheer een gesimuleerde verwijdering van libavutil49 t/m libavutil53 laten doen. Er zou heel wat software verwijderd worden, maar mplayer, mplayer2 of iceweasel zitten daar niet bij, in alle mogelijke afhankelijkheidsketens tussen die pakketten en de verschillende libavutil-versies die op mijn systeem beschikbaar zijn zitten pakketten die op mijn systeem niet geïnstalleerd zijn.
Al de pakketten die kwetsbaar worden genoemd zijn dus niet zozeer zelf kwetsbaar, ze zijn kwetsbaar als ze via een keten van afhankelijkheden een bepaalde library gebruiken, en of dat gebeurt kan van systeem tot systeem verschillen. Omdat het pakketsysteem zo modulair van opbouw is in Linuxdistributies zal met een upgrade van het kwetsbare pakket de kwetsbaarheid in alle software die het direct of indirect gebruikt in één klap opgelost zijn.
Door Anoniem om 16:08: Vergeet vooral je vraag niet te stellen...
Uhm mijn bijdrage (ik ben de TS) was bedoeld als waarschuwing. Je hebt gelijk dat het onderwerp als vraag gelezen kan worden :)Door Anoniem om 15:56:En grappig genoeg zijn er geen *harde* afhankelijkheden tussen mplayer/mplayer2 en libavutil, er zijn alleen pakketten die *gesuggereerd* worden die weer van libavutil afhankelijk zijn. Ik heb het pakketbeheer een gesimuleerde verwijdering van libavutil49 t/m libavutil53 laten doen. Er zou heel wat software verwijderd worden, maar mplayer, mplayer2 of iceweasel zitten daar niet bij, in alle mogelijke afhankelijkheidsketens tussen die pakketten en de verschillende libavutil-versies die op mijn systeem beschikbaar zijn zitten pakketten die op mijn systeem niet geïnstalleerd zijn.
Dan toch een vraag, zou die kwetsbare LZO code statisch gelinked in mplayer/mplayer2 aanwezig kunnen zijn? Zo ja dan klopt het volgende niet wat je schrijft: Al de pakketten die kwetsbaar worden genoemd zijn dus niet zozeer zelf kwetsbaar, ze zijn kwetsbaar als ze via een keten van afhankelijkheden een bepaalde library gebruiken, en of dat gebeurt kan van systeem tot systeem verschillen. Omdat het pakketsysteem zo modulair van opbouw is in Linuxdistributies zal met een upgrade van het kwetsbare pakket de kwetsbaarheid in alle software die het direct of indirect gebruikt in één klap opgelost zijn.
Door Anoniem:Dan toch een vraag, zou die kwetsbare LZO code statisch gelinked in mplayer/mplayer2 aanwezig kunnen zijn?
Goed punt. Even iets verder gekeken dan mijn neus lang is (libav is onderdeel van ffmpeg):http://www.mplayer2.org/differences/
MPlayer required an embedded copy of FFmpeg to compile. This caused a maintenance burden as changes in FFmpeg fairly often broke the compilation of MPlayer. While it could link against shared FFmpeg libraries it would still use some code from the embedded tree instead, and also depended on internal FFmpeg symbols that are not part of the public API, thus making any dynamic-linked binaries liable to break when FFmpeg libraries are updated. MPlayer2 does not depend on embedded FFmpeg library copies and uses FFmpeg only through its public API. This eases maintenance and makes dynamic-linked binaries safe.
Jakkes, dat is niet alleen statisch gelinkt, mplayer heeft een eigen kopie ingebed omdat het van interne symbolen afhankelijk is. Die afhankelijkheid is in mplayer2 verholpen, maar waarom vond ik geen keiharde afhankelijkheid met het pakket libavutil[xx]? Ah, de versie uit de mutlimedia-repository heeft de afhankelijkheid niet en die uit 'core' debian' wel. Kennelijk linkt de eerste wel dingen statisch en de tweede niet. En dat haalt mijn eerdere conclusies onderuit. Bedankt voor het stellen van de juiste vraag!MPlayer required an embedded copy of FFmpeg to compile. This caused a maintenance burden as changes in FFmpeg fairly often broke the compilation of MPlayer. While it could link against shared FFmpeg libraries it would still use some code from the embedded tree instead, and also depended on internal FFmpeg symbols that are not part of the public API, thus making any dynamic-linked binaries liable to break when FFmpeg libraries are updated. MPlayer2 does not depend on embedded FFmpeg library copies and uses FFmpeg only through its public API. This eases maintenance and makes dynamic-linked binaries safe.
Meer details in http://www.theregister.co.uk/2014/07/11/firefox_lzo_rce/: wat ik daaruit opmaak is dat de exploit getoond in het filmpje gebruik maakt van de LZO bug in gecko-mediaplayer, die kennelijk door sommige Linux distro's standaard in Firefox (en mogelijk andere browsers) wordt meegeleverd:
Firefox zelf zou in sommige versies ook kwetsbaar zijn voor een RCE aanval (lz4 compressed bookmark) maar in een dusdanig beperkt aantal gevallen dat publicatie niet de moeite waard zou zijn:
@Anoniem 14:10: tnx voor jouw uitzoekwerk!
TS
By Darren Pauli, 11 Jul 2014 : Bailey's demo of the Mplayer2 plugin shows a vulnerability that can trigger remote code execution (RCE) by way of a Nyan Cat image reel displayed on an updated version of FireFox version 30.
It was revealed the vulnerability could trigger an integer overflow vulnerability that caused a denial of service or buffer overflow resulting in remote code execution under specific conditions.
"This is not a Firefox attack," Bailey said.
"I said [in a blog] I would be releasing an Mplayer2 app, and pointed at gecko-mediaplayer being straight-up vulnerable."
"My concern is that these apps/plugins are installed by default on some distributions of Linux."
It was revealed the vulnerability could trigger an integer overflow vulnerability that caused a denial of service or buffer overflow resulting in remote code execution under specific conditions.
"This is not a Firefox attack," Bailey said.
"I said [in a blog] I would be releasing an Mplayer2 app, and pointed at gecko-mediaplayer being straight-up vulnerable."
"My concern is that these apps/plugins are installed by default on some distributions of Linux."
Firefox zelf zou in sommige versies ook kwetsbaar zijn voor een RCE aanval (lz4 compressed bookmark) maar in een dusdanig beperkt aantal gevallen dat publicatie niet de moeite waard zou zijn:
By Darren Pauli, 11 Jul 2014: Firefox itself is vulnerable to RCE but only in very constrained cases using certain browser versions which limited the attack enough that Bailey would not bother releasing his lz4 compressed bookmark boy-in the browser demonstration.
@Anoniem 14:10: tnx voor jouw uitzoekwerk!
TS
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.