Meer applicaties gevoelig voor uri-lek

De basistechniek uit de 'cross-browser-bug' die onlangs werd ontdekt, is niet alleen geschikt om Firefox te misbruiken. Ook de messenger Trillian struikelt op de manier waarop Internet Explorer protocol requests naar andere programma's stuurt.

Veiligheidsonderzoekers Nate McFeters, Billy Rios en Raghav Dube beschrijven twee lekken die zij aantroffen in de instant messenger Trillian. De drie laten tevens voorbeeldcode zien. Beide lekken hebben betrekking op de manier hoe Trillian met aim://-uri's omgaat. Aanvallers kunnen een aangepaste uri construeren en deze op een webpagina plaatsen. Wanneer een gebruiker in Internet Explorer de link aanklikt, kan een hacker via het lek van Trillian ongemerkt kwaadaardige code op de pc van het slachtoffer uitvoeren. Op dit moment bestaat er nog geen patch om het lek te dichten. De onderzoekers verwachten dat de exploit ook in andere applicaties gebruikt kan worden, en roepen software-ontwikkelaars op om uiterst voorzichtig te zijn met het verwerken van uri's in applicaties. Mozilla heeft ondertussen niet gewacht op een patch van Microsoft om de uri-bugs in Internet Explorer te dichten; het bedrijf heeft, zoals aangekondigd, zelf een beveiligingsupdate voor Firefox uitgebracht.

Reacties (61)

[DavidAxe]

Ik vind het erg lastig om dit als lek te categoriseren. Lijkt een beetje op het vanaf de command line opstarten van applicaties. Door bepaalde parameters toe te voegen kan een onschuldig programma ook ineens kwaadaardig gebruikt worden.
IE de doorgegeven parameters voor andere programma's laten analyseren is natuurlijk ondoenlijk. Conclusie: deze hele feature vraagt om problemen of de mogelijkheden moeten zwaar uitgekleed worden (zoals per aan te roepen applicatie enkel enkele toegestane parameters toestaan).

[Olaf van der Spek]

Dit gaat om een protocol handler, niet om een normale aanroep. Als je zo'n protocol handler aan je applicatie toevoegt moet je natuurlijk wel om de veiligheid denken.

[i-chat]

klopt een daarom snap ik ook niet dat men dit een IE bug noemt, - als je al kunt spreken van een MS fout - dan is dat meer een designe fout in windows URI registratie dan in IE of elke andere aplicatie, -

Vraag:
"wie kan er via firefox eens op zoek gaan naar de trilian versie om te zien of het klikken op de link in firefox andere resultaten laat zien als in IE ....
Ik verwacht dat de zelfde exploit dan ook mogelijk is, (tenzei Firefox geen uri ondersteunt?) (en het daarmee dus aantoont dat 't niet IE's fout is maar die van de URI implementatie...

[roy-t]

En inderdaad het is zooo simpel om even te controleren op onveilige code in je command line input! Je moet toch ook kijken wat je commandline geeft.

firefoxurl://www.tweakers.net wordt geanalyzeerd en daar wordt uigehaald
->surf naar www.tweakers.net

als er dan firefoxurl://format C: staat dan is dit geen geldige website, dus negeren die input.

[Webgnome]

En toch wordt er weer gesuggereerd in het stukje dat het om een internet explorer fout zou gaan. Als applicaties die deze technologie gebruiken, nou gewoon netjes input valideren is het probleem zo uit de wereld.

[Little Penguin]

Dat ben ik niet met je eens, zo moeilijk is het namelijk niet om dit vanuit Internetexplorer aan te passen.

Als ik een URI handler registreer voor laten we zeggen tweaker:// dan kan IE wel degelijk voor een goede afhandeling zorgen. Het enige dat IE hoeft te doen is het escapen van de quotes in de invoer.

Dus als tweaker:// via de URI-handler tweakers.exe -uri aanroept dan moet IE mijns inziens het volgende doen:

tweakers://userprofile/littlepenguin" -iets moet dan door IE als volgt aangeleverd worden: tweakers.exe -uri "tweakers://userprofile/littlepenguin"" -iets"^[1] en niet zoals nu gebeurt tweakers.exe -uri tweakers://userprofile/littlepenguin" -iets.

Maar goed, blijkbaar vind een deel van de programmeurs in Redmond wat anders - hoewel de auteurs van Outlook er dus van uitgaan dat optie [1] de juiste is...

[Reactie gewijzigd door Little Penguin op 8 augustus 2024 01:15]

[.oisyn]

Escapen lost geen drol op, Windows werkt niet met losse parameters voor applicaties, je hebt gewoon 1 commandline. Als je meerdere argumenten wilt hebben, dan zul je dat als applicatie zelf moeten parsen. Welnu, hij kan quotes gaan zitten escapen zodat jij als app snapt wat bij de uri hoort en wat niet, maar dat is nogal arbitrair. Jij gaat ervanuit dat het scapen van quotes helpt, maar dat betekent dat alle applicaties alsnog aangepast moeten worden, omdat er niet zoiets bestaat als het op een standaard manier escapen van quotes in command lines. De applicaties die dus nu custom code bevatten om de commandline op te delen in aparte parameters en daarbij rekening houden met quotes, zullen niet ineens correct gaan werken omdat ze de notie van een geescapte quote helemaal niet snappen. Jou gesuggereerde "fix" voor IE lost dus geen zak op.

Maar, je kan er ook gewoon voor zorgen dat, als je je tweaker:// tegenkomt op de commandline, je er blind vanuit gaat dat de rest van de commandline ook gewoon bij die URI hoort. Ben je meteen van al het gezeik af. Een extra "-iets" in de URI stoppen heeft dan geen zin, want hij wordt gewoon bij de URI gerekend en niet als extra command line optie.

[Reactie gewijzigd door .oisyn op 8 augustus 2024 01:15]

[iNCQRiT]

Volgens mij werkt Windows wel met aparte argumenten. Een voorbeeld is een C of C++ main methode, dat is de methode die dus wordt aangeroepen als een programma wordt opgestart.

int main( int argc, const char* argv[] ){}

Hierbij wordt een constante string array (oftwel een rij van letterrijen) mee gegeven, wat de commandline arguments zijn. In c# is het misschien nog duidelijker:

static void Main(string[] args){}

Windows werkt dus wel degelijk met losse parameters.

[.oisyn]

Oh, dus omdat een C of C++ entry point is gedefinieerd zoals de standaard dat voorschrijft, impliceert dat windows ook zo werkt? Ik hoop dat je zelf ook wel realiseert dat die argumentatie kant nog wal slaat

De gangbare entry point van een win32 applicatie is gedefinieerd als volgt:
int __stdcall WinMain(HINSTANCE hInstance, HINSTANCE, LPSTR cmdLine, int cmdShow);

Juist, die cmdLine is dus een enkele string die de command-line aangeeft. Bovendien is er een win32 API functie om de commandline op te vragen, namelijk GetCommandLine().

Het feit dat de standaard C en C++ main() een lijst van argumenten verwacht, is omdat ISO C en ISO C++ dat nou eenmaal zo voorschrijven. De C runtime, waarmee je linkt als je een applicatie in C of C++ maakt, zorgt er echter voor dat de commandline wordt geparsed, en als losse argumenten naar je main() worden gestuurd. Lees deze pagina maar eens, daar staat uitgelegd hoe dat parsen in z'n werk gaat. Je kunt de parsing ook zelf doen, door de _setargv() functie te implementeren.

Elke applicatie dat meerdere argumenten verwacht, heeft dus eigen command line parsing code meegelinkt, om van een enkele string meerdere argumenten te maken.

[Reactie gewijzigd door .oisyn op 8 augustus 2024 01:15]

[iNCQRiT]

Je hebt helemaal gelijk. Ik ging te kort door de bocht en ik ben blij dat je het even hebt uitgelegd.

Wellicht hebben developers van firefox en trillian hier geen rekening mee gehouden, en dat was nou net het punt wat jij noemde.

[Verwijderd]

http://www.microsoft.com/...ntcmds_shelloverview.mspx

[iNCQRiT]

Het gaat er volgens mij niet om of Internet Explorer het kan. Het probleem is dat als je dit toevoegd, dan betekend het dat je een bepaalde functionaliteit weghaald omdat het potentieel onveilig is (bij programma's die zelf slecht zijn geprogrammeerd).

Ik vind niet dat bepaalde functionaliteit weg moet worden gehaald omdat bijvoorbeeld Firefox of AIM slecht is geprogrammeerd.

[Little Penguin]

Het probleem is dat als je dit toevoegd, dan betekend(sic) het dat je een bepaalde functionaliteit weghaald omdat het potentieel onveilig is

Verklaar je nader?

Welke functionaliteit wordt er dan precies verwijderd? De mogelijkheid om een exploit (parameter injection) niet meer uit te voeren?

Dat lijkt me onwenselijke functionaliteit en dus mag ze dan verwijderd worden...

[iNCQRiT]

De functionaliteit om elke "rij met letters"/string mee te geven, die je nu inderdaad kunt exploiteren, doordat andere programma's hier niet goed mee omgaan.

Ik geef toe dat het waarschijnlijk in de praktijk niet zo ernstig is maar het is volgens mij principieël fout.

[Verwijderd]

Dus meerdere programma's doen het allemaal fout? Wat opvalt aan dit probleem is dat die programma's één gemeenschappelijke deler hebben voor deze bug, namelijk Internet Explorer. Of zou MS weer eens andere visie hebben op het exporteren van data...?

[Reactie gewijzigd door Verwijderd op 8 augustus 2024 01:15]

[SuperDre]

Alle andere browsers hebben ook last van deze bug..

[chrisO]

En als jij op stap gaat en je de deur van je huis open laat staan en je komt thuis en je 40inch plasma tv is gestolen, dan geef je ook de schuld aan de politie...want die moet toch diefstal voorkomen/tegengaan. in de eerste plaats ben je zelf verantwoordelijk voor de veiligheid van je eigen spullen...en dus in mijn ogen moet een programma ook niet veronderstellen dat data verkregen vanuit een ander programma als veilig beschouwd kan worden. Waarom zou je anders uberhaubt nog een thuis een firewall nodig hebben...die heeft je internet provider immers ook....

[Jiriki]

Volgens mij geven de mensen hierboven de schuld aan de open deur, en jij aan de plasma tv

Voor er data doorgegeven wordt, zou het netjes zijn om deze te controleren. Dus eigenlijk lijkt dit probleem op het bouwen van de Erasmus brug, iedereen denkt dat de ander wel controleert of het allemaal klopt.

[i-chat]

en waarop zou jij dat wille controleren dan, denk je nu echt dat een IE DEV inzicht in wat de trilian gasten als wenselijke data beschouwen, - ja dat kun je krijgen ja, misschien moete alle IE dev lid worden van minstend 100 mailing lists per persoon om te weten welke URI er allemaal op de wereld bestaan en welke data die wel en niet wille hebben...

[dcm360]

en waarop zou jij dat wille controleren dan, denk je nu echt dat een IE DEV inzicht in wat de trilian gasten als wenselijke data beschouwen, - ja dat kun je krijgen ja, misschien moete alle IE dev lid worden van minstend 100 mailing lists per persoon om te weten welke URI er allemaal op de wereld bestaan en welke data die wel en niet wille hebben...

Dat is simpel, gewoon op standaard regels van een URI, want dan kan er niet veel mee misgaan. Jiriki bedoelt er waarschijnlijk dan ook mee dat je controleert of het om 'valide' data gaat en niet om nuttig te gebruiken data.

[crisp]

Ik denk dat je het beter kan vergelijken met een samenleving waar er helemaal geen politie is. Als er dan uiteindelijk veel ingebroken blijkt te worden is het geen slecht idee om eens iets aan orde-handhaving te gaan doen

Maar goed, analogieën lopen vaak spaak

[Verwijderd]

Mozilla heeft ondertussen niet gewacht op een patch van Microsoft om de uri-bugs in Internet Explorer te dichten; het bedrijf heeft, zoals aangekondigd, zelf een beveiligingsupdate voor Firefox uitgebracht.

Geweldig dat een community bestaande uit o.a. vrijwilligers sneller reageert dan een bedrijf met honderden miljarden op de bank!

Een mooi voorbeeld dat open-source werkt

[soczol]

Mijn inziens heeft dit weinig met 'open-source' te maken.

Dit probleem is natuurlijk makkelijker op te lossen in de applicatie die aangeroepen wordt (firefox, bijv.), dan in de applicatie die het hele geheel aanroept (internet explorer).

Als Microsoft het een en ander aanpast zodat de aanroep encoded wordt doorgegeven of iets in die richting, dan kan je er haast zeker van zijn dat dit weer de compatibiliteit met een bestaand programma breekt.

Microsoft heeft vast ook bedrijven als klant waarbij het catastrofaal zou zijn als er door een aanpassing van deze methode applicaties of bijvoorbeeld een intranet opeens niet meer blijkt te werken.

Het feit blijft natuurlijk - zoals al door vele anderen aangegeven - dat een applicatie de invoer nooit mag vertrouwen. Men is blijkbaar erg laks geweest met het controleren van de invoer. Tot voor kort was dit geen probleem, maar nu het nieuws eenmaal bekend is zullen er natuurlijk meer pogingen worden gedaan om deze 'bug' uit te buiten.

[Verwijderd]

Helaas vermoed ik ook dat de financiele belangen belangrijker zijn dan goede code schrijven.

[i-chat]

er wordt nogal vaak gezegt dat alleen het escapen van quotes hier DE oplossing is, en op zich ben ik 't na het lezen van die argumenten daar ook wel mee eens, maar toch is het geen IE bug, - Firefox heeft zijn problemen nu opgelost en zo hoort 't ook,

misschien zou 't toch wel vriendelijk zijn als ie bij de volgende patch ook eff die strings escapet

[Verwijderd]

Ik ben (v/f)er(v/f)ent opensource aanhanger, maar wou toch even kwijt dat de Mozilla stichting nou niet bepaalt arm is

[SuperDre]

Alleen het probleem lag bij FireFox en niet bij IE, die doet gewoon wat er verwacht wordt en kan niet al die uri's zelf controleren, want dat betekend dat IE dus alles moet weten ook van programma's die nog niet gemaakt zijn... Trouwens Overige browsers hebben precies hetzelfde probleem..

[ATS]

Het lijkt me dat bijzonder weinig mensen vatbaar zullen zijn voor dit specifieke geval. Iemand die Trillian installeert in plaats van het standaard MSN, installeert vast ook Firefox in plaats van IE.

[iNCQRiT]

Hoe kom je hier bij? Ik kan me best voorstellen dat je trillian installeert omdat je ook graag andere messengers wilt gebruiken, en dat het liefst in 1 programma wil hebben.

Waarom zou je dan ook meteen firefox installeren, ik zie het verband niet.

[dcm360]

En dan kom je bij een webdesigner die zijn/haar pagina's graag in zoveel mogelijk browsers test. Dat als je een programma installeert hoeft lang niet altijd te betekenen dat die regelmatig wordt gebruikt.

[m0nkey]

Volgens Webwereld is Yahoo-chat ook gevoelig voor die AIM uri.

Waarom wordt ik nou weer weggemod? Alsof het oninteressant is dat meerdere programma's gevoelig zijn voor deze lek.

[Reactie gewijzigd door m0nkey op 8 augustus 2024 01:15]

[soczol]

Volgens mij heb je de tekst zelf niet helemaal goed gelezen. Ze hebben het over 2 verschillende lekken.

Trillian heeft het URI-'lek' als er gebruik wordt gemaakt van AIM. Yahoo Messenger heeft een bufferoverflow in het adresboek:

Het lek in Yahoo Messenger [..] is in feite een kwetsbaarheid in de bufferoverflow die kan worden misbruikt door een speciaal aangemaakte invoer in het adresboek, waardoor de chatdienst kan crashen.

en

Trillian is het slachtoffer van twee kritieke lekken die betrekking hebben op de manier waarop Trillian omgaat met AIM uri's (uniform resource identifier).

Tevens is het reageren op moderaties niet gewenst - als een score onjuist is wordt 'ie vanzelf wel weer rechtgezet, en anders is er altijd nog het mismoderatie topic.

[Reactie gewijzigd door soczol op 8 augustus 2024 01:15]

[Verwijderd]

Nog een spinn-off van deze (oorspronkelijke) bug is:
http://www.heise-security.co.uk/news/92725

[eghie]

Tijdelijk oplossings is de URI handlers uit het register tijdelijk verwijderen, totdat er een patch is.

[Verwijderd]

Niet allemaal hoop ik.
Er zijn ook talloze URI handlers die dagelijk worden gebruikt zoals
ftp:
maito:
http:
https:
telnet:

[Verwijderd]

Je hoeft gebruiker niet eens te laten klikken, een asp.redirect (op IIS server) zou hetzelfde bij het inladen van de pagina al doen.

[geez]

Net als de vorige post over deze bug, betreffende Firefox & Internet Explorer wil men graag de schuld bij 1 partij leggen. Imho moeten alle genoemde programma's, Internet Explorer, Firefox, en Trillian de protocol request checken, of deze nou ontvangen of verstuurd word. Een ontvangend programma moet er niet klakkeloos vanuit gaan dat de ontvangen data goed is, net als een versturend programma er niet klakkeloos vanuit moet gaan dat het ontvangende programma daar maar voor moet zorgen.

[Reactie gewijzigd door geez op 8 augustus 2024 01:15]

[berend_engelbrecht]

M$ kennende zullen ze glashard blijven beweren ...

En daar hebben ze dan gelijk in ook . Het zit zo: de uri handler is een open protocol en de aanroeper kan per definitie niet weten wat de aangeroepen applicatie al dan niet als parameters accepteert.

Als je een interface openstelt in je applicatie is het je eigen verantwoordelijkheid, je plicht om de parameters te valideren. Hoe opener het interface, hoe meer aandacht je hieraan dient te besteden. De aangeroepen applicatie is verantwoordelijk voor de syntax van de doorgegeven parameters -die mogen ze in dit protocol zelf vrijelijk bepalen, the sky is the limit- en is dan ook als enige verantwoordelijk voor de syntax check.

Elke veronderstelling over de syntax ("check" in jouw woorden) door de aanroeper is in principe onjuist en kan een toekomstige uitbreiding van een aangeroepen applicatie of stomweg een aan Microsoft onbekende applicatie met z'n eigen uri handler breken. Die firma kan dan terecht naar de rechter lopen en claimen dat Microsoft hun het werken onmogelijk maakt door beperkingen in z'n open protocol in te bouwen. Het is dus niet alleen technisch maar ook juridisch onjuist als de aanroeper hier veronderstellingen gaat doen.

[Reactie gewijzigd door berend_engelbrecht op 8 augustus 2024 01:15]

[crisp]

Zo zwart-wit is het imo niet; ik denk dat het meer een hiaat van het protocol is dat je niet kan aangeven of en hoe er gechecked dient te worden op parameters en of substitutie parameters eventueel escaped dienen te worden.
Nog mooier zou zijn als je ook zou kunnen aangeven in welke situaties een dergelijk protocol gebruikt mag worden en in welke niet (niet door IE bijvoorbeeld).

Als eerste zou Microsoft de documentatie kunnen voorzien van een waarschuwing, of eventueel kunnen doorverwijzen naar alternatieve manieren om datgene te bewerkstelligen waarvoor nu vaak de uri handler wordt gebruikt cq misbruikt

[_js_]

Het blijft grappig om te zien hoe al die anti-microsoft naar manieren blijven zoeken om Microsoft de schuld te geven voor dit probleem.

Tip: die waarschuwing staat er al heel lang bij (langer dan firefox bestaat)
http://msdn2.microsoft.com/en-us/library/aa767914.aspx

Er staat bij dat de URL geunescaped wordt aangeleverd, en er staat bij dat er misbruik van kan worden gemaakt. Dat een hobbyistje die deze functie in firefox implementeert niet even de moeite neemt om de handleiding te lezen is inherent aan open source programming, waar een officiële handleiding wel het laatste is waar men aan denkt, liever eerst iets in elkaar hacken, en later maar kijken of er problemen zijn lijkt de standaard werkwijze te zijn.

[crisp]

Ik geef Microsoft niet de schuld maar geef enkel aan dat ze zelf ook dingen kunnen doen om interoperability te verbeteren en zodoende kunnen meedragen aan algemene veiligheid.

Overigens kan ik me niet herinneren vorige week die waarschuwing gezien te hebben, of ik moet een ander document over url protocols gelezen hebben op msdn. De gecachede versie van 14/07 laat iig geen waarschuwing zien.

Je laatste ongefundeerde flame zal ik maar negeren...

[sopsop]

IE heeft een fout. IE heeft nergens last van.

Firefox en de andere apps hebben ook een fout, en ze hebben er last van.

IE moet zijn fout herstellen, maar Firefox en de andere apps moeten een kritieke fout herstellen (waarbij FF dat al heeft gedaan).

De manier van aanleveren zoals IE dat doet kan in principe ook worden gebruikt door andere apps, die dan nog steeds kritieke fouten opleveren in FF (en de andere apps).