Malware op GoT?

[defixje]

Dag Adjes,

Mijn Chrome geeft een Malware alert op deze pagina:

\[3D] Post je 3d-stuff maar weer - part 44

Klopt dit of is dit een false positive?

[gambieter]

Google Chrome 'safe browsing' malware meldingen al gelezen?

[Raven]

defixje schreef op donderdag 17 april 2014 @ 22:51:
Dag Adjes,

Mijn Chrome geeft een Malware alert op deze pagina:

\[3D] Post je 3d-stuff maar weer - part 44

Klopt dit of is dit een false positive?

Link even naar het bericht dat de melding triggert, niet iedereen heeft dezelfde aantal berichten per pagina ingesteld

[Kees]

Post aangepast.

Is niet perse een false positive, maar meer dat chrome ziet dat er op die pagina vanaf een domein die bij hen bekend staat als malwareverspreider iets ingeladen word. En aangezien veel gebruikers hun eigen webspace gebruiken kan dat wel eens bijten.

[ Voor 89% gewijzigd door Kees op 18-04-2014 10:26 ]

[NMe]

Kees schreef op vrijdag 18 april 2014 @ 10:25:
Post aangepast.

Is niet perse een false positive, maar meer dat chrome ziet dat er op die pagina vanaf een domein die bij hen bekend staat als malwareverspreider iets ingeladen word. En aangezien veel gebruikers hun eigen webspace gebruiken kan dat wel eens bijten.

Blijft absurd en compleet paranoïde. De enige manier waarop je iets verkeerds binnen zou kunnen trekken is als ze op de een of andere manier code weten te executen via het tonen van images. Als Chrome dat voor elkaar krijgt hebben ze wel een erg grote bug... Daarbij is het ronduit geschift dat ze dan de hele pagina blokkeren in plaats van alleen die ene image. Digibete gebruikers snappen dit niet en denken door dit soort geintjes ineens dat Tweakers onveilig is.

Tijd om meer stars te regelen op deze issue.

[Kees]

NMe schreef op vrijdag 18 april 2014 @ 12:04:
[...]

Blijft absurd en compleet paranoïde. De enige manier waarop je iets verkeerds binnen zou kunnen trekken is als ze op de een of andere manier code weten te executen via het tonen van images. Als Chrome dat voor elkaar krijgt hebben ze wel een erg grote bug... Daarbij is het ronduit geschift dat ze dan de hele pagina blokkeren in plaats van alleen die ene image. Digibete gebruikers snappen dit niet en denken door dit soort geintjes ineens dat Tweakers onveilig is.

Tijd om meer stars te regelen op deze issue.

Hoezo is dat zo vreemd? Ik kan mij genoeg bugs herinneren met Javascript/html in images die gewoon uitgevoerd werden door de browser ook al stond alles in een <img> tag. Dat er nu geen bekende bug is, wil niet zeggen dat er geen mensen zijn die een oude browser gebruiken en/of dat er in de toekomst niet perongeluk een bug geschreven word.

[ Voor 8% gewijzigd door Kees op 18-04-2014 13:27 ]

[RaZ]

Dan is het verstandiger om pics zelf te hosten, en de optie voor remote pics gewoon uit te schakelen Of kijken naar safe-browsing's malware list, en die domeinen gewoon niet meer toestaan Maar opzich is het raar dat je zaken gaat aanpassen omwille van een browser-instelling die ronduit paranoia is...

[ Voor 17% gewijzigd door RaZ op 18-04-2014 13:29 ]

[kamerplant]

Bizar dat het probleem nog steeds open staat. Hoe star ik een item in de betreffende bug tracker

/edit/ Ah, er staat een knopje onderop de pagina.

[ Voor 21% gewijzigd door kamerplant op 18-04-2014 13:32 ]

[Zeror]

Externe avatar afbeeldingen enkel voor abbonees laten toestaan zal het probleem aanzienlijk verminderen en tevens het forum tegelijkertijd versnellen. Er is immers al genoeg ruimte op tweakers om je avatar op te slaan in zowel je avatar opties als het fotoalbum.

[ Voor 9% gewijzigd door Zeror op 18-04-2014 13:35 ]

[NMe]

Kees schreef op vrijdag 18 april 2014 @ 13:25:
[...]

Hoezo is dat zo vreemd? Ik kan mij genoeg bugs herinneren met Javascript/html in images die gewoon uitgevoerd werden door de browser ook al stond alles in een <img> tag. Dat er nu geen bekende bug is, wil niet zeggen dat er geen mensen zijn die een oude browser gebruiken en/of dat er in de toekomst niet perongeluk een bug geschreven word.

Dan nog is het ronduit achterlijk om een forumpagina met tig images en lappen tekst erop te blokkeren omdat er van één untrusted domein een plaatje wordt ingeladen.

Zeror schreef op vrijdag 18 april 2014 @ 13:34:
Externe avatar afbeeldingen enkel voor abbonees laten toestaan zal het probleem aanzienlijk verminderen en tevens het forum tegelijkertijd versnellen. Er is immers al genoeg ruimte op tweakers om je avatar op te slaan in zowel je avatar opties als het fotoalbum.

Tegelijkertijd lost het niks op want ook abonnees zouden zomaar eens Lycos gebruikt kunnen hebben.

[Hooglander1]

Tjah, of gewoon externe plaatjes niet meer toestaan. Hele probleem ook opgelost voor GoT.

[Nakebod]

Ik zal eens even iemand kicken of er (weer) naar dat Chrome ticket gekeken kan worden
Een iets subtielere melding kan al veel helpen.

[NMe]

Hooglander1 schreef op vrijdag 18 april 2014 @ 14:22:
Tjah, of gewoon externe plaatjes niet meer toestaan. Hele probleem ook opgelost voor GoT.

Breedgebruikte features weghalen om om de paranoia van Google heen te werken lijkt me een slecht plan.

[F_J_K]

Kees schreef op vrijdag 18 april 2014 @ 13:25:
Hoezo is dat zo vreemd? Ik kan mij genoeg bugs herinneren met Javascript/html in images die gewoon uitgevoerd werden door de browser ook al stond alles in een <img> tag. Dat er nu geen bekende bug is, wil niet zeggen dat er geen mensen zijn die een oude browser gebruiken en/of dat er in de toekomst niet perongeluk een bug geschreven word.

Zeker wel vreemd; immers is de hele pagina blokkeren onzinnig als het een enkele img tag betreft op een forum.

[PromWarMachine]

NMe schreef op vrijdag 18 april 2014 @ 12:04:
[...]
Tijd om meer stars te regelen op deze issue.

Grappig, ik heb dat issue jaren geleden al gestarred.
Kreeg eerder vandaag een update op het ticket in de mail en begreep niet zo goed waar het vandaan kwam.
Nu zie ik dat jij er op gereageerd hebt.

Hopelijk gaan ze er snel iets aan doen ja, want sommige mensen zullen inderdaad gaan denken dat de site onveilig is.

[ Voor 30% gewijzigd door PromWarMachine op 18-04-2014 15:15 ]

[Hero of Time]

RaZ schreef op vrijdag 18 april 2014 @ 13:28:
Dan is het verstandiger om pics zelf te hosten, en de optie voor remote pics gewoon uit te schakelen

Dat voorkomt eventueel misbruik van de bug niet. De uitvoerbare code was namelijk embedded in het plaatje. Het boeit dan dus niet waar deze staat.

[Raven]

NMe schreef op vrijdag 18 april 2014 @ 12:04:
Tijd om meer stars te regelen op deze issue.

"Status: Unconfirmed"

Is er ooit wel eens naar gekeken?

[NMe]

Ze hebben de status aangepast (comment #7). Lijkt me wel dus.

[RaZ]

Hero of Time schreef op vrijdag 18 april 2014 @ 15:19:
[...]

Dat voorkomt eventueel misbruik van de bug niet. De uitvoerbare code was namelijk embedded in het plaatje. Het boeit dan dus niet waar deze staat.

[Panic-mode]
Direct de img-tag uitschakelen
[/]

[Kees]

F_J_K schreef op vrijdag 18 april 2014 @ 15:08:
[...]

Zeker wel vreemd; immers is de hele pagina blokkeren onzinnig als het een enkele img tag betreft op een forum.

Nee, dat is helemaal niet vreemd. In het verleden zijn ook in images bugs aangetroffen die bijvoorbeeld remote JS inclusion mogelijk maakten ook al stonden ze in img tags. En als je dus een malware verspreidende host hebt gevonden en je ziet dat er resources van die host op een andere site geinclude worden, dan wil je daarvoor waarschuwen en voorkomen dat men mogelijk besmet raakt op een legitieme site die alleen maar een image van dat domein bevat.

En nogmaals, momenteel zijn er afaik geen bekende bugs in images, maar die zijn er wel geweest en dat wil zeggen dat er in de toekomst ook best wel weer exploits gevonden zouden kunnen worden in de huidige code of in toekomstige code.

En ja, ook al was het deze keer een foto, vaak zijn het usericons en ik ben er ook voor om daar geen remote plaatjes meer in toe te staan. En ook alle plaatjes zou ik het liefste intern hosten voor de snelheid etc. maar dat stuit ongetwijfeld op wat meer problemen zoals auteursrecht.

[TERW_DAN]

Maar daarmee zou je dan wel zo'n beetje het enige forum zijn dat dat doet. Ik ken weinig fora waar de img-tags enkel lokale content kan laten zien (maar misschien dat ik dan juist op de verkeerde fora kom ).

Ik denk echter dat het vanuit de community gezien niet heel praktisch is, omdat er al zoveel images zijn gepost idie op externe hosts staan.

[NMe]

Kees schreef op vrijdag 18 april 2014 @ 15:31:
[...]

Nee, dat is helemaal niet vreemd. In het verleden zijn ook in images bugs aangetroffen die bijvoorbeeld remote JS inclusion mogelijk maakten ook al stonden ze in img tags. En als je dus een malware verspreidende host hebt gevonden en je ziet dat er resources van die host op een andere site geinclude worden, dan wil je daarvoor waarschuwen en voorkomen dat men mogelijk besmet raakt op een legitieme site die alleen maar een image van dat domein bevat.

Dan kunnen ze toch gewoon die image vervangen door een rood kruis of iets anders? Waarom moet de complete pagina geblokkeerd worden?

[RaZ]

@kees:

Kijkend naar de video-tag, dan zijn niet alle video's te embedden, kan dat natuurlijk voor icons ook prima een blacklist maken waarbij een aantal domeinen niet toegestaan worden. Want dynamic icons die veel mensen gebruiken kunnen die blijven gebruiken, en je haalt dan zeker voor 90% van die paranoia safe-browsing meldingen weg..

Lijkt me een mooi compromis toch?

Edit: En als je toch zo'n blacklist hanteerd, kan dan ook wel met de img-tag, want het forum checked de plaatjes sowieso (mits je die optie uitzet in je post)

[ Voor 17% gewijzigd door RaZ op 18-04-2014 15:38 ]

[Raven]

NMe schreef op vrijdag 18 april 2014 @ 15:28:
Ze hebben de status aangepast (comment #7). Lijkt me wel dus.

Het toevoegen van labels noem ik geen statusaanpassing

TERW_DAN schreef op vrijdag 18 april 2014 @ 15:34:

offtopic:
Happy b-day

[kamerplant]

Kees schreef op vrijdag 18 april 2014 @ 15:31:
[...]

En ja, ook al was het deze keer een foto, vaak zijn het usericons en ik ben er ook voor om daar geen remote plaatjes meer in toe te staan. En ook alle plaatjes zou ik het liefste intern hosten voor de snelheid etc. maar dat stuit ongetwijfeld op wat meer problemen zoals auteursrecht.

Tweakers.net wordt er niet sneller op als plaatjes intern worden gehost. De browser wacht niet totdat alles is geladen voordat het wordt laten zien, bij een trage 3th party host duurt het enkel langer voordat de usericoon wordt weergegeven. Who cares .

Qua auteursrechten maakt het ook weinig uit. Linksom of rechtsom wordt de afbeelding op de website van Tweakers.net weergegeven en is wordt het zonder direct medeweten van de organisatie achter T.net op de website gepubliceerd. Waar het daadwerkelijk wordt gehost doet niet perse ter zake.

Ook qua beveiliging maakt het niets uit of het plaatje door Tweakers of door een 3th party partij wordt gehost. Als het een onveilig plaatje betreft wordt het niet ineens op een magische manier veilig als het door Tweakers.net wordt gehost.

De bottomline is gewoon simpel: De functionaliteit van de forumsoftware is gewoon goed en hoeft niet te veranderen. Het betreft een ondoordacht side-effect van de betreffende security functie in Chrome en heeft -gezien de lage hoeveelheid klachten- gewoon een hele lage prioriteit.

[Verwijderd]

Hooglander1 schreef op vrijdag 18 april 2014 @ 14:22:
Tjah, of gewoon externe plaatjes niet meer toestaan. Hele probleem ook opgelost voor GoT.

Dat is ook niet te doen. Waar gaan mensen dan hun image content neerzetten? Het forum zou dan ook een soort attachment feature moeten krijgen zodat je topics ook kan vullen met afbeeldingen.
Echt alles inhouse proberen te houden is denk ik niet heel praktisch.
Ik vind het raar dat google een hele pagina tegenhoud in plaats van alleen verdacht elementen zeker als het slechts een [img] element is.

[NMe]

Verwijderd schreef op vrijdag 18 april 2014 @ 15:49:
[...]

Dat is ook niet te doen. Waar gaan mensen dan hun image content neerzetten? Het forum zou dan ook een soort attachment feature moeten krijgen zodat je topics ook kan vullen met afbeeldingen.

Pssst, je fotoalbum.

[Verwijderd]

NMe schreef op vrijdag 18 april 2014 @ 15:50:
[...]

Pssst, je fotoalbum.

Dan verpruts je het hele nut van het foto album als je mensen daar heel casual hun random topic meuk in laat zetten.

[TERW_DAN]

Hoezo? Daar gebruik ik mijn fotoalbum juist vrij veel voor als ik wat op 't forum wil zetten.

[NMe]

Verwijderd schreef op vrijdag 18 april 2014 @ 15:53:
[...]

Dan verpruts je het hele nut van het foto album als je mensen daar heel casual hun random topic meuk in laat zetten.

Hoezo? Je kan toch een al dan niet verborgen mapje maken voor het forum? Heb ik ook gedaan. Mijn fotoalbum heeft echt wel wat meer foto's en andere plaatjes dan de 4 die je zo ziet.

[Kees]

NMe schreef op vrijdag 18 april 2014 @ 15:35:
[...]

Dan kunnen ze toch gewoon die image vervangen door een rood kruis of iets anders? Waarom moet de complete pagina geblokkeerd worden?

dat is idd ook een goede optie voor een img tag, maar dat mag google doen

Datafeest schreef op vrijdag 18 april 2014 @ 15:47:
[...]

De bottomline is gewoon simpel: De functionaliteit van de forumsoftware is gewoon goed en hoeft niet te veranderen. Het betreft een ondoordacht side-effect van de betreffende security functie in Chrome en heeft -gezien de lage hoeveelheid klachten- gewoon een hele lage prioriteit.

offtopic:
Het heeft ook geen hoge prioriteit, maar het heeft wel een aantal voordelen
- geen irritante inlog-schermen meer als iemand zijn usericon/foto achter http-auth zet
- geen missende plaatjes omdat iemand ruimte nodig heeft en plaatjes weggooit of account opzegt
- [usericons] geen te grote plaatjes meer (gifje van 100MB als usericon bv)
- [usericons] minder privacy inbreuk door 'lekken' naar een third party
- [usericons] op de frontpage geven we alleen al uploaded icons weer

TERW_DAN schreef op vrijdag 18 april 2014 @ 15:34:
Maar daarmee zou je dan wel zo'n beetje het enige forum zijn dat dat doet. Ik ken weinig fora waar de img-tags enkel lokale content kan laten zien (maar misschien dat ik dan juist op de verkeerde fora kom ).

Ik denk echter dat het vanuit de community gezien niet heel praktisch is, omdat er al zoveel images zijn gepost idie op externe hosts staan.

Dat is een kwestie van de posts bij langs lopen, plaatjes ophalen, post aanpassen en klaar. Gewoon een background proces van maken. En volgens mij doet facebook hetzelfde