Wat mij nog meer zorgen baart is het feit dat Google dus blijkbaar verschillende methoden door elkaar gebruikt om tot dezelfde oplossing te komen. Immer suggeert:
Gillon zegt dat het uitzetten van 'Active Scripting' in de opties van Internet Explorer het bevissen van de lokale schijf onmogelijk maakt. Alternatieve browsers zoals Firefox en Opera zouden geen last hebben van het probleem.
dat het programma ook gewoon werkt zonder active scripting met IE. Dit betekent dus dat Google speciaal voor IE een Active Scripting implementatie heeft gemaakt, terwijl de alternatieve methode voor alle browser werkt. Het lijkt wel Windows op die manier

.
Hopelijk halen ze dit soort truckjes niet teveel uit, want dan is de kans groot dat er nog veel exploits en problemen gaan komen in de Google tools en met de meest gebruikte zoekmachine, een populaire emailclient en ook de andere tools die gretig aftrek vinden, wil je als systeembeheerder niet nog meer gerotzooi.
Het draaien van een lokale webserver om te kunnen zoeken in je eigen bestanden vind ik trouwens ook erg NOT DONE. Geen idee wie het heeft gebouwd, maar volgens mij hadden ze best wat andere oplossingen mogen bedenken. Mijn baas zou me levend villen als ik met zo'n oplossing aan zou komen.
@cSp: Ach ja, verrek. Eerste punt heb je helemaal gelijk. Niet helemaal goed gelezen. Het zal wel bedtijd wezen

Nou snap ik de techniek hierachter ook niet helemaal, maar het lijkt me nogal zinloos dat Google speciaal voor IE een ActiveX script maakt dat uiteindelijk tot hetzelfde resultaat leidt als wanneer je ActiveX uitzet. M.a.w.... dat doet Google niet.
Ik denk dat het stukje code aan de phisher-kant bestaat uit ActiveX code. Deze stuurt dan Google aan, en verkrijgt door een bugje in IE inzicht in de harde schijf.
Dit betekent dus dat Google speciaal voor IE een Active Scripting implementatie heeft gemaakt, terwijl de alternatieve methode voor alle browser werkt.
Dit is absoluut onjuist. De kwaadaardige website maakt gebruikt van scripts om Internet Explorer gegevens van webpagina's uit een ander domein door te spelen naar de kwaadaardige website. GDS (Google Desktop Search) speelt hier geen actieve rol in bij en gebruikt dus ook geen active scripting van IE.
Het draaien van een lokale webserver om te kunnen zoeken in je eigen bestanden vind ik trouwens ook erg NOT DONE.
Google is wat zoeken betreft nou eenmaal bekend met google.com dus het wil zijn diensten daarin integreren. Om nu te voorkomen dat ze voor ieder browsend programma een nieuwe implementatie (met nieuwe bugs) moeten maken in de vorm van plug-ins kiezen ze ervoor om één systeem brede implementatie in de vorm van een webserver die zoekpagina's van google aanpast te maken.
Het probleem zit hem niet in de webserver rol van GDS maar in het feit dat de Internet Explorer willekeurige websites toestaat informatie uit de interface van Google te vissen. Het probleem had zich niet (in enige vorm) voorgedaan als GDS zich alleen met een andere interface dan webpagina's had aangeboden aan de gebruiker, maar dat is een begrijpelijke keuze.
Dit betekent dus dat Google speciaal voor IE een Active Scripting implementatie heeft gemaakt, terwijl de alternatieve methode voor alle browser werkt. Het lijkt wel Windows op die manier
Nee, de exploit werkt omdat:
* IE een geen veiligheidscontroles uitvoert op bestanden van andere domeinen die via een CSS-import geladen worden.
* IE de mogelijkheid biedt om CSS imports at-runtime uit te voeren.
* IE de mogelijkheid biedt om de originele CSS source te tonen.
Het draaien van een lokale webserver om te kunnen zoeken in je eigen bestanden vind ik trouwens ook erg NOT DONE. Geen idee wie het heeft gebouwd, maar volgens mij hadden ze best wat andere oplossingen mogen bedenken. Mijn baas zou me levend villen als ik met zo'n oplossing aan zou komen.
Wel nuttig om te vermelden dat de webserver aan je localhost interface gekoppeld is, en dus NIET vanaf een ander systeem te benaderen is.