Beveiligingslek voor remote code execution in terminal-emulator iTerm2 gedicht

Er is een ernstig beveiligingslek in iTerm2 gedicht. Dat is een populaire terminal-emulator voor macOS die veel wordt gebruikt door softwareontwikkelaars. De kwetsbaarheid zou al zeker zeven jaar in het programma hebben gezeten.

De kwetsbaarheid werd ontdekt door het Mozilla Open Source Support-programma, dat het beschreef in een blogpost. Door de beveiligingsfout konden aanvallers in veel gevallen commando's uitvoeren op de computers van gebruikers. Mozilla schrijft dat het beveiligingslek 'enige vorm van gebruikersinteractie of bedriegerij vereist', zoals een phishingaanval. Het lek staat bekend als CVE-2019-9535.

Desondanks zeggen de onderzoekers dat de potentiële impact groot is als iemand de kwetsbaarheid uitbuit. Met de exploit kunnen namelijk commando's worden uitgevoerd die normaal gesproken als veilig beschouwd worden. Zo kunnen gebruikers per ongeluk een kwaadaardige url opvragen via het cURL-commando, of onbedoeld via ssh verbinding maken met een command-and-control-server.

Een update waarin het beveiligingslek is gerepareerd is nu beschikbaar voor alle gebruikers. De fix zit in versie 3.3.6, die tegelijk met de blogpost van Mozilla werd gepubliceerd. Uiteindelijk zal iTerm2 de update prompten aan gebruikers, maar momenteel moet de update handmatig worden uitgevoerd.

Het lek werd ontdekt door onderzoekers van Radically Open Security, dat de audit in opdracht van Mozilla startte. Het Mozilla Open Source Support-programma bestaat sinds 2015 op. In 2016 begon Mozilla met het Secure Open Source Fund, ook wel SOS Fund. Via dat fonds financiert Mozilla de securityaudits van opensourceprojecten. Hiermee hoopt het team achter onder andere Firefox nieuwe security-incidenten als Heartbleed, shellshock en andere branded bugs te voorkomen.

Reacties (14)

Tweede keer dat er in een veelgebruikte open source oplossing langdurig een stevig lek zit. Toont ook maar weer aan dat je je op dat principe niet moet blindstaren.

zou je een auto verkoper die zegt dat je niet onder de motorkap mag kijken net zo vertrouwen als een die dat wel toelaat? bijde motoren kunnen defecten hebben, maar de verkoper die mij onder de motorkap laat kijken vertrouw ik toch meer (ook al heb ik geen verstand van motoren)

Zo is het ook met open & closed source: bijde kunnen fouten bevatten, toch vertrouw ik open source meer omdat ik dan iig kan controleren wat voor code ze op mijn machine uitvoeren

Uiteraard, de ca. 10 miljoen code regels van Linux heb je allemaal doorgenomen en gecontroleerd
Dan heb je nog geen applicaties

Voor een overheid / multinational is dat nog wel te doen. Voor MKB of privé personen blijft het een vertrouwensbasis, open source of niet.

Onjuiste aanname. De miljoen regels code zijn wél door een programma doorlopen op een enorm aantal mogelijke problemen. Dat kan omdat de broncode publiek is. Je kunt dit ook zelf doen voordat je compileert. En je kunt ook zelf dus eenvoudig scannen als je merkt aan je firewall o.i.d. dat er iets lekt waardoor dat dat komt. On top of that kun je code differences doen t.o.v. eerdere releases.

Gaat het om vertrouwen: ja. Vaak wel. Maar de controle is goed te doen. Dus het vertrouwen is ergens op gebaseerd.

Autoanalogie: Je kunt onder je motorkap kijken EN je hebt gedetailleerde documentatie over hoe elke klep en aansluiting gebruikt wordt. Ja - er kan wat in verstopt zitten, maar je kunt dat wel terugvinden. I.t.t. closed source.

https://www.owasp.org/index.php/Source_Code_Analysis_Tools

Onjuiste aanname. De miljoen regels code zijn wél door een programma doorlopen op een enorm aantal mogelijke problemen.

Het jammere is dat je argument al laat zien dat je het zelf nog nooit geprobeerd hebt en het voor jou enkel maar een theoretisch argument is.

Als je het ooit daadwerkelijk zou proberen om een beetje groot OSS programma door een Static Source Code Analyser te halen dan ren je keihard weg. Je zal 10.000'en errors en warnings krijgen.
Een Static Source Code Analysis heeft alleen zin met een specifiek uitzonderingen bestand waarvan jij 100% begrijpt waarom de ontwikkelaar gekozen heeft om d x en y errors/warnings te negeren (als men al Static Code Analysis doet)
Alleen als jij 100% begrijpt waarom die uitzonderingen bestaan dan hoef je geen Static Code Analysis meer te doen, want je weet de uitkomst al.
En de bugs gaan dan of puur zitten in je SCA tool of je uitzonderingen bestand in combinatie met andere regels code.

Een SCA tool blind ergens overheen gooien is net zoiets als een spellingscontrole over een dik boek heengooien, hij vind allerlei "fouten" omdat er nieuwe woorden zijn bedacht, of de woorden zijn simpelweg niet in de spellingscontrole toegevoegd, of het zijn simpelweg verzonnen woorden.
En dan kan je de spellingscontrole toevoegingen van de auteur overnemen, alleen dan weet je nog niet of die toevoegingen allemaal wel correct zijn, je weet alleen dat je daarmee door de spellingscontrole komt.

Bij mijn website gebruik ik code scans om obfuscated code te vinden en een aantal constructies die gevaarlijk/malware lijken. Daarnaast is er de malware-scan met duizenden patronen die als lek zijn bestempeld. Ook daarvan krijg ik automatisch een melding als dat gevonden wordt. Handig bijv. om de leverancier te controleren of hij geen oude lekkende code van het web copy-paste. Heerlijk, open source.

Ik snap dat het geen Linux is, jouw genoemde problemen zijn helaas echt, maar open source maakt het leven wel betrouwbaarder. SCA tools zijn echt niet heilig, maar voor sommige projecten is het een prima middel.

Daarom gaat zijn auto analogie ook best goed op. Je mag onder de motorkap kijken, maar als er iets mis is met de motor zelf, ga je dat niet zo maar zien. Dus net zo goed als die miljoenen codes nalopen.
Het gaat meer om het idee. Kwaadwillende kunnen niet zo maar iets engs er in kwijt omdat men het kan zien. Wil niet beteken dan iedereen de code door gaat zitten spitten natuurlijk. Maar het is zeker wel transparanter.

zou je een auto verkoper die zegt dat je niet onder de motorkap mag kijken net zo vertrouwen als een die dat wel toelaat? bijde motoren kunnen defecten hebben, maar de verkoper die mij onder de motorkap laat kijken vertrouw ik toch meer (ook al heb ik geen verstand van motoren)

Zo is het ook met open & closed source: bijde kunnen fouten bevatten, toch vertrouw ik open source meer omdat ik dan iig kan controleren wat voor code ze op mijn machine uitvoeren

Onder de motorkap vergelijken met OSS is net zoiets als zeggen dat OSS hetzelfde is als 10 miljoen regels code op 1 a4'tje uitprinten en dat iemand laten lezen.
Het wordt pas vergelijkbaar als je de motor eruit mag halen en die mag nakijken op elk onderdeel etc.

En dat laatste mag bij geen van 2'en.

De zoveelste keer... maar dat heeft niets te maken met opensource, eerder met de mate waarin code-audits en ander beveiligingsonderzoek gedaan wordt.

Wees maar gerust dat in closed source software ook lang lopende bugs zitten, zeker als je kijkt naar de minder grote softwarehuizen. Maar zelfs bij de grote zijn er wel die er wat van kunnen (Adobe anyone?)

Ik werd net geprompt om iTerm te updaten, dus dat "uiteindelijk" is al "nu"... Update was verder triviaal (buiten dat ik mijn sessies verloor natuurlijk).

Mozilla schrijft dat het beveiligingslek 'enige vorm van gebruikersinteractie of bedriegerij vereist', zoals een phishingaanval.

Ik denk dat de ‘gemiddelde’ iTerm gebruiker niet zo snel daar in trapt. Maargoed, alsnog fijn dat het gepatched is.

Mozilla schrijft dat het beveiligingslek 'enige vorm van gebruikersinteractie of bedriegerij vereist', zoals een phishingaanval.

Ik denk dat de ‘gemiddelde’ iTerm gebruiker niet zo snel daar in trapt. Maargoed, alsnog fijn dat het gepatched is.

Slechts het verbinden naar een server is al voldoende als ik dit zo zie in de video. Ik neem aan dat daar het stukje phishing in zit. Nu beheer ik zelf het liefst alles via de terminal dus als een 'fake' hostingpartij een ssh ingang biedt log ik daar altijd op in. Best bizar lek dat ze op dat moment al code execution voor elkaar hebben op je PC. In mijn ogen behoorlijk kritiek.

Ze zouden ook gebruik kunnen maken van tik fout.
Van zoiets hadden we ergens in 2010 last. Toen krijg je op zo'n beetje alle .ml een ssh sessie.

Een remote terminal is natuurlijk (altijd) een trusted applicatie die je (soms) untrusted data voedert. Dat maakt het een prima attack surface.