Hackers verpakken malware in afbeelding

Beveiligingsonderzoekers zullen op de Black Hat-bijeenkomst software tonen die kan worden ingezet om persoonlijke gegevens van websitebezoekers te verzamelen. Ze vermomden een java-bestand als afbeelding.

De onderzoekers van beveiligingsbedrijf Ngssoftware en de beveiligingsafdeling van Ernst & Young zullen hun zogenoemde 'Gifar'-bestand tonen op de laatste dag van de Black Hat-beveiligingsconferentie, die van 2 tot 7 augustus in Las Vegas wordt gehouden. De naam 'Gifar' is gebaseerd op het duale karakter van het bestand: de webserver behandelt de malware als een afbeeldingsbestand in gif-formaat, terwijl de Java-virtual machine van de gebruiker het bestand als een uitvoerbare java-applicatie of .jar-bestand herkent. De gebruiker ziet alleen een afbeelding.

Wanneer kwaadwillenden een gifar-bestand op een site plaatsen, kunnen zij bezoekers van andere sites, bijvoorbeeld een sociale netwerksite waar gebruikers moeten inloggen, middels fictieve profielen naar de gifar-malware lokken. De Java-vm van de bezoeker zal het archiefbestand openen en de code uitvoeren. Met die code kunnen vervolgens de inloggevens van bijvoorbeeld Hyves, Myspace of Facebook gestolen worden, omdat de .jar-code met de rechten van de bezoeker kan communiceren met de website waar die vandaan kwam. Het filteren van hybride bestanden zou een goede beveiliging kunnen vormen; daarom zou alleen een lokkertje op de netwerksite geplaatst worden, terwijl het kwaadaardige bestand op een server zonder contentfiltering wordt gehost.

Een meer algemene oplossing zou een update van Suns Java-software kunnen zijn, en de beide Blackhat-deelnemers hopen dan ook op een snelle oplossing voor dit specifieke probleem. Volgens Nathan McFeters en John Heasman, de makers van het hybride bestand, is een patch voor Java echter niet voldoende: de 'gifar-methode' is slechts een van de manieren om van de kwetsbaarheid van webtoepassingen gebruik te maken. Volgens Jeremiah Grossman, de cto van White Hat Security, moeten browsers op een fundamenteel andere wijze met beveiliging omgaan. Overigens zullen McFeters en Heasman, om misbruik te voorkomen, de details van hun gifar-software niet openbaar maken.

Reacties (68)

[Falcon]

Wat ik nooit helemaal snap is waarom deze meeting bestaat. Want je wilt toch ook als beveiligingsbedrijf juist geheim houden in hoeverre jouw kennis is dan tegen over de crackers die er zijn?

Dit soort meetings zouden in mijn ogen nooit al te groot gehouden moeten worden. Want dit is natuurlijk een super informatiebron voor crackers.

[Webdoc]

Het is een afweging - of je houdt dingen zo geheim mogelijk, maar dan zullen je uitvindingen op het gebied van malware detectie en afweer niet voor veel mensen bekend zijn (zowel onder daders als slachtoffers) of je maakt het wel allemaal erg open, en dan weten beide partijen juist WEL alles. Je kan bedenken dat oplossing 2 waarschijnlijk per saldo beter is - de crackers moeten weer met nieuwe evilheden op de proppen komen want "iedereen" weet al hoe de oude moeten worden voorkomen/verholpen. Op deze manier blijft het een kat-en-muis-spel maar is de kans het grootst dat men er in slaagt een zo groot mogelijk aantal beheerders/security personeel op de hoogte te houden van gevaren.

Als je op de geheime tour gaat dan zal je geheid zien dat zo nu en dan een dik bedrijf die nergens van wist slachtoffer wordt van iets wat stiekem al een paar maanden geleden is ontdekt en verholpen...

[Verwijderd]

Security by obscurity is geen security. Dus moet dit soort info juist WEL wereldkundig gemaakt worden. Common practice is dan toch ook, eerst de ontwikkelaar van het product met het lek op de hoogte stellen. Tijd geven om een patch beschikbaar te stellen, vervolgens wereldkundig maken zodat iedereen op de hoogte is.

[Tukk]

Juist dit soort zaken moeten openbaar gemaakt worden. Nu is iedereen bekend met het probleem, kan iedereen er rekening mee houden en wordt er ook sneller voor een oplossing gezorgd.

Linux-sources zijn toch ook openbaar, alle fouten kan je zo bekijken. Juist daarom is de software minder foutgevoelig...

edit:
Beetje spuit 12 zo, ik tk niet snel genoeg

[Reactie gewijzigd door Tukk op 28 juli 2024 16:11]

[Blokker_1999]

een recente studie toont evenwel aan dat open source niet noodzakelijk minder foutengevoelig of overzichtelijker is. Wel bied het als voordeel dat de oorzaak van een fout vaak sneller gevonden en gepatched word.

[Verwijderd]

Een ander onderzoek dat ik alweer een behoorlijke tijd geleden heb gelezen wees uit dat in meer algemene zin het ontsluiten van beveiligingsproblemen (dus niet alleen in de PC) uiteindelijk in zo'n beetje 100% van de gevallen tot minder problemen leidt. Kennelijk is het verantwoordelijkheidsgevoel van de massa groter dan sommige paranoide leiders graag denken. Leiders komen uberhaupt niet graag met slecht nieuws naar buiten, bang voor hun persoonlijke reputatie. Dat is "de logica van de macht" , (Mauk Mulder)

[eerdepeer]

Dit is toch ook weer volop reclame voor ze...

[freaky]

Wat hebbie liever verhaal:

Criminelen met vuurwapens, politie/burgers met vuurwapens.

of

Criminelen met vuurwapens, en een stel doetjes dat staat te wachten tot ze doodgeschoten worden.

Ikke de 1ste... veel security clubs de 1ste. Veel vendors de laatste, met 1 uitbreiding. Ze houden de politie/burgers het liefst onwetend over het feit dat die criminelen vuurwapens hebben. Dan zijn ze tenminste niet bang terwijl ze wachten op dat schot. Ze weten immers niet waar ze op wachten.

[PPie]

Helaas werkt het niet zo. In de USA (waar je op doelt), blijkt dat als de mensen vuurwapens hebben, deze niet gebruikt worden om criminele activiteiten te voorkomen.
Of men kan er niet bij, of men durft niet, etc.

Aan de andere kant:
- Omdat mensen vuurwapens hebben, worden ruzies opeens beslist met een vuurwapen
- Het aantal overvallen/geweld/aanranding is hoger.
- Je krijgt een wapenwetloop.
- Is het aantal zelfdodingen hoger, omdat het zo eenvoudig gaat.
- ZIjn er veel kinderen/partners die (onbedoeld) met een vuurwapen spelen en hiermee zichzelf of anderen verwonden/doden.

In de achterstandswijken in de USA is de levensverwachting van zwarte mannen lager dan mannen uit derdewereld landen! Een groot deel hiervan komt door vuurwapens.

[Tyrian]

Dit soort problemen kunnen makkelijk voorkomen worden als softwaremakers een bestand enkel zouden classeren op bestandsextensie. (.gif > image etc.) Helaas is de trend tegenwoordig meer om in het bestand zelf te gaan kijken of het misschien uitgevoerd kan worden / of dat er bepaalde headers in staan.

[nhbergboer]

Dit is een onderwerp waar al veel discussie over is geweest, maar in dit geval zou een beslissing op MIME type beter zijn:

Immers: de webserver herkent de afbeelding als gif, en stuurt hem dus naar de client als MIME type "image/gif". Als de client daar naar zou luisteren (ongeacht de extensie), dan zou het probleem opgelost zijn.

[crisp]

Klopt, maar daarover is de discussie nog niet afgerond. Menig webserver in de wereld staat nog verkeerd ingesteld en stuurt plaatjes, HTML-bestanden en dergelijke nog vrolijk allemaal met een text/plain MIME type. Dat is de reden dat webbrowsers op een gegeven moment content-sniffing zijn gaan doen.

Waar het fout gaat is op het moment dat content-sniffing geprefereerd wordt boven een duidelijke (en correcte) MIME type. Zo zou een image/x directive nooit mogen resulteren in een sniffed executable type of een text type (zoals HTML met embedded javascript). Dat laatste gaat bijvoorbeeld nog fout in Internet Explorer waar een getweaked (maar valide) GIF bestand dat met een verkeerde MIME type wordt verzonden (bijvoorbeeld als deze werd voorzien van een .jpg bestandsextensie en geupload naar een server die niet de bestands-signature checked tegen die extensie) door IE kan worden gezien als een HTML bestand (zie: nieuws: XSS-exploit door Microsoft betiteld als 'by design').

De oplossing is tweeërlei: serverside zouden user-submitted bestanden beter gechecked moeten worden op hun digitale 'signature', waarbij enkel het checken van de eerste bytes in het bestand waarschijnlijk niet meer voldoende is, en aan de andere kant zouden webbrowsers Content-Type als authoritive moeten behandelen (conform de specificaties). IE8's proprietary authoritive header is een tijdelijke workaround (iig om IE te laten luisteren) maar ook geen uiteindelijke oplossing; integendeel: het maakt het probleem eigenlijk alleen maar erger op de langere termijn.

On the bright side heeft Microsoft nu eindelijk wel besloten om 'upsniffing' (bijvoorbeeld image/x bestanden op basis van content-sniffing behandelen als text/x of application/x) in IE8 aan banden te leggen.

[flowerp]

stuurt plaatjes, HTML-bestanden en dergelijke nog vrolijk allemaal met een text/plain MIME type. Dat is de reden dat webbrowsers op een gegeven moment content-sniffing zijn gaan doen.

Precies. Dit laat weer eens zien dat losjes omgaan met fouten eigenlijk een groter probleem is dan gewoon keihard een foutmelding geven en er mee kappen. Men denk dat het doorgaan bij fouten gebruiksvriendelijk is (de gebruikers vinden fouten immer alleen maar lastig), maar keer op keer kom je dan toch uiteindelijk in de problemen.

Als de browsers van gebruikers van een bepaalde website een plaatje niet laten zien, reken maar dat de website beheerder ik weet niet hoe snel die headers goed gaat zetten. Nu test ie echter ff z'n site in IE en misschien nog ff in Firefox. Als het plaatje dan getoond wordt is ie allang happy. Had IE echter niets weergegeven, dan had ie nu z'n headers gewoon goed staan...

[crisp]

De huidige status-quo is niet meer te veranderen, dat is in een ver verleden al fout gegaan en is feitelijk een kip-ei verhaal: de vogelvlucht die het internet genomen heeft, de enorme aanwas van allerlei exotische bestandsformaten, webserversoftware die 'out of the box' enkel text/plain als Content-Type gebruikte, onwetendheid van degenen die deze webserversoftware gebruikten en browsers die in het midden van de browser-wars niets anders konden dan op een alternatieve manier de juiste bestandssoort bepalen.

"be liberal in what you accept, and conservative in what you send" is hier duidelijk op het 2e punt fout gegaan, het eerste deel is imo nog steeds een groot goed vermits dat ook op een zinnige manier wordt gedaan en dat gewoon wordt vastgelegd in een standaard (HTML5 probeert dat nu te doen overigens) zodat ook iedereen hetzelfde doet (interoperability).

Daarbij is content-sniffing niet volledig uit te bannen, er zijn genoeg situaties waar helemaal geen MIME type beschikbaar is (filesystems bijvoorbeeld, maar het zou ook beter zijn als een webserver die geen MIME kan bepalen van een bepaald bestand dan maar geen Content-Type header genereerd ipv de text/plain variant die daardoor voor z'n uiteindelijke doel compleet onbruikbaar is geworden op het web).

[Reactie gewijzigd door crisp op 28 juli 2024 16:11]

[Verwijderd]

Flowerp heeft helemaal gelijk, er is namelijk een fundamenteel en onoplosbaar probleem met de methodiek die crisp aanhaald:

"be liberal in what you accept, and conservative in what you send"....

Het eerste deel van dat statement lokt per definitie uit dat het 2e deel nooit nageleeft kan worden. Het is gewoon onkpraktisch aangezien je nergens complexe software kunt testen op het conservatief zijn als er geen platform is dat conservatief je software uitvoerd.

Het probleem aangedragen in deze thread (en aanverwante security problemen) komen voort uit het te gemakkelijk zijn bij de acceptatie van data. Het is beter dit te veranderen en zo een situatie te scheppen die uiteindelijk zorgt dat de aanbieders van data wel strikt moeten zijn in wat zij aanleveren.

Nu het probleem oplossen en daar eenmalig de pijn voor te dragen heeft wat mij betreft de voorkeur. Er is ondertussen genoeg expertise op webgebied aanwezig om de gevolgen op te lossen. Je kunt niet eeuwig fout op fout blijven stapelen en dan nog meer fouten introduceren om de fouten van de vorige generatie software (deels) te compenseren, enz.

Er is in het verleden al genoeg kapitaal (en de wil om te leven) vernietigd doordat standaarden te losjes waren waardoor er grote praktische verschillen onstonden. Iedere ontwikkelaar heeft zindsdien letterlijk jaren van zijn leven verspild om om die troep heen te werken!!! En zelfs nu zijn we er nog niet geheel van verlost, het is soms net wolkenkrabbers bouwen op drijfzand, onder variabele weersomstandigheden nog wel en dat moet maar eens afgelopen zijn.

Laatst moest ik de RFC voor cookies er op naslaan en daar stond ook "be liberal in what you accept, and conservative in what you send". Groot probleem dus want voor de meest simple situatie moet je dan rekening gaan houden met alle mogelijke gedachtenkronkels op deze aardbol....uiteindelijk maar een sniffer gebruikt en soortgekijke output gegenereerd en daarna getest. Het is best mogelijk dat blijkt dat het uiteindelijk niet altijd goed gaat, maar ja....dat is hoe de standaard is gedefinieerd...doe maar wat. Als je niet strikt kunt testen, hoe weet je dan dat wat je hebt gemaakt ook klopt? De software wordt er bovendien ook complexer door, waarmee je uitlokt dat er meer fouten onstaan en dat de code niet goed kan worden onderhouden.

De eerstvolgende W3C professor die "be liberal in what you accept, and conservative in what you send" aanhangt die moet ter plekke afgevoerd worden naar het gevang wegens misdaden tegen de menselijkheid (populair tegenwoordig, dus waarom niet hiervoor).

[Reactie gewijzigd door Verwijderd op 28 juli 2024 16:11]

[crisp]

Het eerste deel van dat statement lokt per definitie uit dat het 2e deel nooit nageleeft kan worden. Het is gewoon onkpraktisch aangezien je nergens complexe software kunt testen op het conservatief zijn als er geen platform is dat conservatief je software uitvoerd.

Natuurlijk kan je software wel testen op het conservatief zijn, daar zijn gewoon hulpmiddelen voor zoals validators en andere tools.

Juist het liberalisme heeft het internet groot gemaakt en bepaalde software populair. Als jij als software bouwer de keuze moet maken tussen het strict opvolgen van bepaalde richtlijnen en daarmee de gebruiker opzadelt met verminderde functionaliteit of het liberaal omgaan met common mistakes die nu eenmaal gemaakt worden en daarmee de gebruikerservaring kan verbeteren dan is die keuze snel gemaakt.

Je zou wel kunnen stellen dat we van meet af aan alle RFC's naar de letter hadden moeten volgen, en dat content-producerende software dat ook had moeten doen en dat elke fout op de XML-mallformedness manier afgestraft had moeten worden, maar dan was het internet lang niet zo rijk geweest als het nu is. Imo moet je de drempel niet hoog/hoger leggen maar juist zo laag mogelijk; het liberaal omgaan met content is juist de uitdaging voor programmeurs en specificatie-schrijvers - het keyword hier is interoperability en daar ligt juist het grootste struikelblok van dit moment.

Het is grappig dat je hier de cookie RFC aanhaalt; wist je dat geen enkele useragent die naleeft? Daar ligt nog een hoop werk voor de HTTP WG, en je hebt gelijk dat legacy in deze de materie behoorlijk complex maakt. Echter kan je niet zomaar even zeggen "we gooien alles weg en beginnen opnieuw en doen het nu goed", daarmee zou je onze collectieve wetenschap van de laatste decenia feitelijk in een black hole weggooien...

[Verwijderd]

Het vergelijk dat je aanhaald bevat een aanname die je standpunt versterkt, maar volgens mij onterecht is. Een strikt platform staat niet gelijk aan een beperkend platform, maar is wel gemakkelijker met testen. Ook bij de huidige situatie is het niet de bedoeling dat je random data verstuurd en zo nieuwe functionaliteit 'ontdekt', er zijn gewoon grenzen die je kunt afbakenen en daarmee voorkom je gekke toestanden zoals die van deze thread.

Verder zie ik niet in hoe los omgaan met dataspecificaties door browsers de mogelijkheden voor gebruikers groter heeft gemaakt dan wat anders zou zijn gebeurd. Welke functionaliteit zouden we bijvoorbeeld niet hebben (anders dan de security hacks) als er striktere standaarden waren die door browsers afgedwongen zouden worden?

Wat betreft specificaties zelf, die moeten ruim genoeg zijn om nieuwe toepassingsmogelijkheden te openen, maar ook strikt, volledig en testbaar vanaf het moment van release.

De HTML validators zoals ik die ken, die zijn toch wel primitief hoor. Interactive pagina's met dynamische HTML testen als onderdeel van een omvangrijke applicatie is geen pretje aangezien de validators meer zijn gemaakt om een enkele statische pagina op fouten te controleren.

In applicaties zijn die pagina's gewoon niet zo statisch. Daarom lijkt mij het gewoon beter ontwikkelen voor een strikt platform waardoor je er vanuit kunt gaan dat wat bij jou werkt, het elders ook goed doet. Hoewel dit laatste langzaam beter wordt, zijn er nog genoeg uizonderingen die er voor zorgen dat gebruikers nog steeds minder functionaliteit krijgen voor meer geld dan anders het geval zou zijn geweest. Alle effort die ontwikkelaars moeten steken in het werkend maken over platformen en browsers heen kosten tijd en geld, wat natuurlijk ook anders besteed kan worden.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 16:11]

[crisp]

Een strikt platform staat niet gelijk aan een beperkend platform, maar is wel gemakkelijker met testen

Een strikt platform is in zekere mate wel een beperkend platform want je legt de instapdrempel hoog. Het liberaal omgaan met (in dit geval) markup op het web heeft er wel degelijk voor gezorgd dat het internet zo'n grote vlucht heeft kunnen nemen: iedereen kan er aan deelnemen en je hoeft geen programmeur te zijn om een stukje markup op het web te plaatsen, noch heb je daar ingewikkelde en dure tools voor nodig.

Diezelfde liberaliteit heeft ons ook wel degelijk een heel scala aan mogelijkheden en technologieën opgelevert, aldanniet indirect.

Daarbij moet ook opgemerkt worden dat specificaties en richtlijnen een levend iets zijn en dus contemporary, en zeker de huidige specificaties vaak zaken ongedefinieerd laten (HTML, CSS, HTTP) of simpelweg in het huidige ecosysteem niet eenduidig implementeerbaar (meer) zijn (cookies). Dat laat altijd een leegte tot het moment dat er een nieuwe specificatie beschikbaar is.

"Strict, volledig en testbaar" is een utopie, en vooral testbaar is ook niet altijd mogelijk omdat er vaak ook zaken met een subjectief karakter meespelen (specificaties laten ook ruimte voor ruimere interpretaties, niet alles is een MUST of MUST NOT).

De HTML validators zoals ik die ken, die zijn toch wel primitief hoor.

True, en in de huidige vorm ook compleet waardeloos met een 'Valid HTML!' button die je op je site kan plaatsen op het moment dat je enkel nog maar de technische syntax-check goed doorloopt; document conformance gaat immers veel verder dan dat. De experimentele HTML5 validator is al een stuk beter, maar uiteindelijk is een browser zelf al best in staat om aan te geven of een document syntactisch conformant was of niet (en sommige doen dat al, al dan niet mbv een plugin of extensie).

Als laatste leg je de vinger wel op de uiteindelijke zere plek: het grootste probleem op dit moment zijn niet de specificaties zelf of de strictheid daarvan (note daarbij dat author-requirements bijvoorbeeld in HTML5 wel degelijk strict zijn, maar dat van useragent implementaties liberaliteit wordt verwacht) maar het feit dat er op veel gebieden gewoon geen interoperabiliteit is. Oftewel: elk platform is op z'n eigen manier liberaal, maar allemaal weer net even anders, en dat is wat het meeste tijd en geld kost...

[Reactie gewijzigd door crisp op 28 juli 2024 16:11]

[Verwijderd]

Het klopt dat meer striktheid de instap drempel voor het ontwikkelen hoger maakt voor niet IT'ers. Daar staat tegenover dat de drempel voor ervaren ontwikkelaars hoger wordt als je dat niet doet. Die kunnen niet zonder meer leunen op de generieke kennis die zij hebben en moeten experimenteel uitzonderingsgevallen aanleren (en dat kost een hoop tijd, weet ik nog van mijn eerste webapplicatie).

Voor de minder technisch aangelegde gebruikers zijn er natuurlijk prima tools waarmee zij meer kunnen behalen dan wanneer zij zelf door de syntax moeten worstelen. Dat indirect nieuwe gangbare 'features', onstaan als gevolg van die technische laagdrempeligheid zie ik niet zo op basis van deze redenatie. Voor vernieuwing heb je een goed idee nodig (niet technische aspect), maar hoeveel hiervan kunnen er door een leek als gevolg van de laagdrempeligheid geimplementeerd worden?

We kunnen het er 100% over eens zijn dat interoperabiliteit een groot goed is, en dat vervolg standaarden hier zwaar de nadruk op moeten leggen. Maar gezien de redenatie die ik hierboven net uiteen heb gezet, betwijfel ik of het losjes omgaan met input hier wel bij helpt, terwijl wel duidelijk naar voren komt dat interoperabiliteit eronder lijd. Bij ongewijzigd digitaal ecosysteem zal na nog eens 10 jaar evolutie het probleem zeker minder worden. Maar hoe realistisch is dat dan wel?

En dat het internet een success is kan ook aan andere zaken toegewezen worden dan het liberaal zijn van de standaarden. Ondanks de slechte interoperabiliteit van de eerste browser implementaties is het uitendelijk toch geworden wat het nu is. En ik denk vrij stellig te kunnen zijn dat we die eerste problemen voor een groot deel toe kunnen schijven aan het gebrek aan strikte standaarden.

Ik laat het laaste woord nu aan jouw crisp, het wordt een discussie op zichzelf zo onderhand.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 16:11]

[crisp]

Nou, dan neem ik dat laatste woord maar

Daar staat tegenover dat de drempel voor ervaren ontwikkelaars hoger wordt als je dat niet doet.

Het feit dat useragents liberaal mogen/moeten zijn laat niet onverlet dat de norm voor in ieder geval ervaren ontwikkelaars een stricte basis heeft, maar de praktijk op het web laat toch zien dat zelfs 'professionals' daar veel moeite mee blijken te hebben
De uitzonderingsgevallen betreffen over het algemeen verschillen tussen proprietary technologieën versus bestaande standaarden en het verschil in mate waarin useragents zich aan die standaarden confirmeren, dat is heel wat anders.

Voor de minder technisch aangelegde gebruikers zijn er natuurlijk prima tools waarmee zij meer kunnen behalen dan wanneer zij zelf door de syntax moeten worstelen.

Een minder technisch aangelegde gebruiker kan in eerste instantie al niet het onderscheid maken tussen een slechte tool en een goede tool. Feit is wel dat dankzij het liberale gedrag van useragents zelfs met een slechte tool nog een redelijk resultaat behaald kan worden. Als agents juist strict met syntax zouden omgaan zouden er wellicht geen slechte tools meer zijn, maar zal het aantal goede tools ook aanzienlijk kleiner zijn en wellicht ook een stuk duurder waardoor de drempel voor onervaren gebruikers juist nog hoger wordt.

Daarbij zou het werken met syntax juist helemaal geen worsteling moeten zijn...

Dat indirect nieuwe gangbare 'features', onstaan als gevolg van die technische laagdrempeligheid zie ik niet zo op basis van deze redenatie.

Adoptie door een grote groep betekend automatisch dat de drive voor verbetering en uitbreiding van de mogelijkheden aanzienlijk groter is dan wanneer enkel een selecte groep gebruik kan maken van een bepaalde technologie. De browser-war (wat uiteindelijk een gevecht om de gunst van de gebruiker was, niet alleen de loerders maar ook de auteurs, van amateur tot pro) heeft wat dat betreft in een korte tijd een rijk skala aan technologieën voortgebracht waarvan vele op dit moment wel in een standaard zijn gevat of een gestandaardiseerde opvolger hebben gekregen.

Maar gezien de redenatie die ik hierboven net uiteen heb gezet, betwijfel ik of het losjes omgaan met input hier wel bij helpt, terwijl wel duidelijk naar voren komt dat interoperabiliteit eronder lijd.

Interoperabiliteit lijdt onder specificaties die geen normatieve criteria opstellen voor die liberaliteit en vendors die op een eigen eilandje leven maar ondertussen de hele wereld denken te regeren Ik heb toch goede hoop dat beide punten in de toekomst alleen maar zullen verbeteren

En ik denk vrij stellig te kunnen zijn dat we die eerste problemen voor een groot deel toe kunnen schijven aan het gebrek aan strikte standaarden.

Of misschien wel door het algehele gebrek aan standaarden die bemeten waren op de nieuwe functie die het internet in korte tijd gekregen heeft. Niemand kon dat indertijd voorzien, alsmede ook de problemen op gebied van security waar we nu mee kampen. Hoe strikt had je dan in de begintijd van het internet de standaarden willen opstellen? En hadden we daarmee dan wel gehad wat we nu hebben? Ik neem dat beetje legacy dan wel op de koop toe

[YopY]

Ik denk niet dat het zo eenvoudig is. Immers, het artikel zegt dat de gebruiker 'alleen een afbeelding ziet', wat er op wijst dat de browser hem sowieso als een valide afbeeldingsbestand ziet. Ik weet niet hoe een bestand precies ingelezen wordt, maar het bestand wordt sowieso wel als een afbeelding ontvangen en weergegeven.

[SWINX]

Als het een image/gif is moet die als image/gif behandeld worden.
Daarbij hoort geen JavaVM aan de pas te komen.
Dus feitelijk is het wel zo simpel.

Zelfde effect is als je een .txt bestand op een website plaatst met HTML code erin,
Deze zou als text/plain behandeld moeten worden, maar deze werd in IE altijd gewoon geparsed onder het motto "wat nou mime type, ik zie toch html tags?"
Ik weet overigens niet of dat nog steeds zo is, maar het was lange tijd wel zo.

[edit]
Ik lees uit de reacties hieronder dat content sniffing dus is begonnen doordat webservers alles doorzonden als text/plain. Daar kan ik me dan wat bij indenken, maar ik mag toch hopen dat de webserversoftware in de loop der tijd ook zo is aangepast dat deze tegenwoordig de correcte mime-types teruggeeft, en de browser kan hier dan toch gebruik van maken?
Maar ik mist vast en zeker ergens wat, waardoor het niet zo simpel is

[Reactie gewijzigd door SWINX op 28 juli 2024 16:11]

[dgompie]

Het kan natuurlijk ook zijn dat een van de taken van het Java programma is om een plaatje te tonen (via code).

[Het.Draakje]

Het zou al heel wat zijn als ieder bestand maar op één manier herkent wordt : of als niet uitvoerbaar of als uitvoerbaar.

Een uitvoerbaar bestand moet dan altijd door de gebruiker eerst bevestigd worden vóór hij uitgevoerd kan worden. Dan ligt de grootste beveilingsrisico weer waar hij hoort te liggen : tussen de oren van de gebruiker.

Het is heel leuk dat alles maar rechtstreeks vanaf het internet uitgevoerd kan worden, maar voor het internet geldt nog steeds : het loont om achterdochtig te zijn.

[WPN]

en tussen de oren is dus precies waarom alles fout gaat bij dit soort dingen.....

gebruikers beseffen of snappen het niet en klikken gewoon op de eerste beste knop waarmee de waarschuwing weg gaat

[sdebusschere]

Helemaal juist, de meesten beginnen gewoon te klikken tot ze de waarschuwing niet meer zien. Vraag maar eens aan 10 mensen wat er precies in een dialoogvenster wordt gezegd...

[Verwijderd]

Al klikkerdieklikkend kom ik op een site welke omschrijft dat het nog enger kan eigenlijk: http://www.cyberwart.com/blog/2008/08/01/mixing-file-types/ .Stel je hebt een HTML file met een gezellig activex dingetje erin. FF htmlfile renamen naar .doc en je code zal lokaal uitgevoerd worden. Ik heb het niet geprobeerd, maar het klinkt eng genoeg.

[Vordreller]

Momenteel kan ik slechts 1 ding bedenken dat hiertegen misschien iets kan uitmaken

De NoScript addon voor firefox. Die staat het toe alle scripts en code te verbieden op basis van domeinnaam.

Ik zeg misschien want ik ben het niet zeker. Als de browser het gewoon ziet als een afbeelding, dan neem ik aan dat NoScript dat dus ook zal doen. Dus wordt niks geblokkeerd en kan de code uitgevoerd worden.

2de mogelijkheid is dat de browser kijkt of er iets te runnen valt, herkent de Java maar kan niet uitvoeren omdat de domeinnaam niet toegestaan is.

[Punksmurf]

NoScript stript JavaScript, dat is iet heel anders.

[PhazeD]

Met NoScript schakel je javascript en java standaard uit, als ik het goed begrepen heb. Vervolgens kan je handmatig java en javascript weer inschakelen voor de sites die je vertrouwt:
"You can enable JavaScript, Java and plugin execution for sites you trust with a simple left-click"

NoScript lost het probleem niet op. Voor sites die je regelmatig bezoekt en actief gebruikt, zoals hives, facebook of myspace, zal men java over het algemeen inschakelen. Het is immers een site die je vertrouwt, en bovendien werken er stukken van de site niet als java uitstaat.

[Reactie gewijzigd door PhazeD op 28 juli 2024 16:11]

[Verwijderd]

Is dit een reden om geen Java VM (ala Sun) te draaien? Ik heb hem in ieder geval niet.

[latka]

Er zijn ergere dingen dan een JavaVM met foutjes. Kun je beter alle active-content (ActiveX, Flash, PDF etc.) allemaal uitzetten. Overal worden gaten in gevonden. Zo weten de meeste mensen niet dat je JavaScript in PDF kunt proppen en dat Acrobat dat doodleuk uitvoert...

[Verwijderd]

De vraag is, hoeveel schade kan je met javascript doen? Als Acrobat de javascript interpreter van de browser gebruikt dan zal dat script maar -zeer- weinig met je systeem kunnen doen.

Datzelfde geldt overigens voor deze Java-exploit, waarbij de schade voorlopig beperkt lijkt te blijven tot het verkrijgen van toegang tot iemand's Facebook/Hyves/etc profiel.

[ppl]

Die beperking zit hem in de mogelijkheden van de software die ze gemaakt hebben. Ze kunnen hem ook uitbreiden dat hij hetzelfde kunstje doet bij bijv. de online banking sites en noem maar op. Dan wordt de impact toch ineens heel wat groter. Ze willen iets bewijzen en dan pak je gewoon wat stuff bij elkaar zodat je dat ook kan doen. Je bent dan niet bewust bezig om alle mogelijkheden die er maar zijn te laten zien: alleen dat het mogelijk is om hiermee kwaad te doen.

Het antwoord op je vraag is dan ook "voldoende" en misschien ook wel gewoon "te veel".

[Verwijderd]

Die beperking zit hem in de mogelijkheden van de software die ze gemaakt hebben. Ze kunnen hem ook uitbreiden dat hij hetzelfde kunstje doet bij bijv. de online banking sites en noem maar op.

Dat vraag ik me af. Voor zover ik uit het artikel kan halen krijgt dit programma zijn rechten omdat mensen al ingelogd op facebook de afbeelding bekijken op een of ander facebook profiel, waarna het script met dezelfde gebruikersrechten in het facebook-profiel. Het verschil tussen facebook en online banking sites is dat iedere huis- tuin- en keukenhacker een dubieuze afbeelding op facebook kan plaatsen, maar dat is op de internetbankier-site van ABN AMRO al een stuk moeilijker.

Dus zo simpel als jij het schetst is het niet, voor zover ik na kan gaan.

[Verwijderd]

Inderdaad, ik merk dat ik al in maanden geen Javacode meer uit heb hoeven voeren, en toen de JVM maar met updates bleef komen (en èn passant ook even OpenOffice mee wilde installeren) heb ik 'm maar gewoon verwijderd. Geen moment spijt van gehad.

[Verwijderd]

ik vraag me in hoeverre dit effect op linux heeft.. aangezien het hier om gif en java bestanden gaat

[Verwijderd]

Tuurlijk heeft dit geen effect op Linux. Daar word een bestand wèl herkend op zijn mimetype.

[Verwijderd]

Juist wel.
Zolang het een Java bestand is, is het voor alle OSsen bedoeld.
Alleen de vraag is nog, werkt het ook als Java niet op een computer is geïnstaleerd?

[Verwijderd]

Hmm ja, ik lees net het bronartikel, waarin duidelijker uitgelegd word dat de Java VM zelf bekijkt hoe de informatie geïnterpreteerd moet worden.
Rijst bij mij de vraag: Moet de browser niet eerst de Java VM vertellen wat er geopend moet worden? Zo ja, dan ligt het probleem nogmaals bij de browser zelf.

[SuperDre]

yep, juist weer de reden waarom linux toch niet zo goed is, men DENKT dat men veilig is, zelfde als met OSX van Apple (niet voor niets verbied apple nu hun medewerkers over alle security lekken)..

[Punksmurf]

Die doen het ook op Linux hoor.. Echt.

[dracozna]

java is platform-onafhankelijk, dus in theorie zou het op elke OS kunnen draaien waar een java-vm op kan draaien

[Verwijderd]

Ja dat dacht ik dus al.. maar wilde het toch ff bevestigd hebben

[Blaat]

Lekker handig om dit soort info uit te lekken.

Op die manier kan men zich hier op voorbereiden .

[Punksmurf]

Inderdaad... ook de beveiligingsbedrijven, dus. Deze hack is binnenkort niet meer bruikbaar, omdat hij wereldkundig is gemaakt. Dat is toch goed?

[High-Voltage2]

Het zal wel aan mij liggen, maar hoe kan een bestand nu twee bestandstypes vormen? Als je gewoon de extentie in de gaten houdt begrijp ik niet waarom JVM per se dat scriptje wil gaan uitvoeren... Een overactieve JVM?
Of kijken die webbrowsers niet naar extenties en gaan ze gewoon elk bestand openen, kijken naar de headers en hup... Als je dan mixed headers hebt, heb je het natuurlijk vlaggen.

[Verwijderd]

Je reageert precies verkeerd om (zoals bij eerdere posts te lezen valt). De browser negeert het MIME type, maar gebruikt de bestandsextensie. Bug geboren.

[cool0]

Ach je hebt toch ook zo'n tool: Camouflage heet het. Klik je een plaatje aan en een bestand dan voeg die het samen plaatje verstuur je naar een andere die kan het bestand eruit halen met dezelfde tool. Werkt perfect om firewall te bypassen.

[stresstak]

Dat kan inderdaad al jaren met "copy /b" Kopieer een zip aan een jpg en noem het bestand .jpg. Opent de ontvanger de jpg dan ziet hij een plaatje. Hernoemt hij het bestand naar .zip en opent hij die, dan blijkt het een ook zip.
Geinig toch ?

[Verwijderd]

we gaan misschien offtopic:
samenvoegen dat lukt wel maar alleen de eerstgenoemde file kan ik nog openen. De tweede (na hernoemen naar originele extensie) geeft fouten.

[Verwijderd]

Met die code kunnen vervolgens de inloggevens van bijvoorbeeld Hyves, Myspace of Facebook gestolen worden, omdat de .jar-code met de rechten van de bezoeker kan communiceren met de website waar die vandaan kwam.

Hoe komt die java-code dan precies aan die rechten?