See this talk page:
http://en.wikipedia.org/wiki/User_talk:189.148.6.25
The poster purports to be a journalist experimenting with putting toxic links on Wikipedia to see who will follow them.
Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc.
- d.
it would be as simple as adding .exe\s to the meta spam blacklist
On 9/5/09, David Gerard dgerard@gmail.com wrote:
See this talk page:
http://en.wikipedia.org/wiki/User_talk:189.148.6.25
The poster purports to be a journalist experimenting with putting toxic links on Wikipedia to see who will follow them.
Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc.
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2009/9/5 David Gerard dgerard@gmail.com:
See this talk page:
http://en.wikipedia.org/wiki/User_talk:189.148.6.25
The poster purports to be a journalist experimenting with putting toxic links on Wikipedia to see who will follow them.
Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc.
The relevant edits have been oversighted so I can't tell what kind of URLs they were. If they were like "www.foo.com/bar.exe" then we can easily stop them by not parsing URLs that end ".exe". There will be some false positives (eg. http://en.wikipedia.org/wiki/.exe although that is only a redirect, so no real harm), but it shouldn't involve more than a slight change to 1 or 2 lines of code, unless I'm missing something. Something more advanced that would actually block executables, rather than just things with an exe extension would require actually following the link, which is probably too slow to be practical (it would have to be done on rendering, rather than saving, otherwise you can just change what is at the other end of the link after saving the page).
Is there any great risk here, though? Modern browsers won't run such an executable (at least not without big scary warnings which, of course, we never just blindly click through).
2009/9/5 Thomas Dalton thomas.dalton@gmail.com:
The relevant edits have been oversighted so I can't tell what kind of URLs they were. If they were like "www.foo.com/bar.exe" then we can easily stop them by not parsing URLs that end ".exe".
It was on Rapidshare. It was of the form:
http://xxx123.rapidshare.de/123456789/InnocentToxicWaste.exe
- so it didn't link directly to the file itself, even - but to the page about the file.
There will be some false positives (eg. http://en.wikipedia.org/wiki/.exe although that is only a redirect, so no real harm),
I forgot about that. Given that exes could be on *any* sort of page, any collateral damage suggests this is a pointless bit of security theatre ...
but it shouldn't involve more than a slight change to 1 or 2 lines of code, unless I'm missing something. Something more advanced that would actually block executables, rather than just things with an exe extension would require actually following the link, which is probably too slow to be practical (it would have to be done on rendering, rather than saving, otherwise you can just change what is at the other end of the link after saving the page).
As I noted, in this case the link actually went to a download page, not directly to the .exe. He still got five people to download it.
Is there any great risk here, though? Modern browsers won't run such an executable (at least not without big scary warnings which, of course, we never just blindly click through).
*cough*
- d.
David Gerard wrote:
As I noted, in this case the link actually went to a download page, not directly to the .exe. He still got five people to download it.
Having people download it is not harmful per se. How many of them were for reviewing it?
I read the talk page and have the impulse of downloading it to see what it really was, since they link to two different analysis, supposedly of the linked file, but with different hashes.
David Gerard, how did you get the link to threatexpert.com? The behavior of 01cd53443e3e7a7453a85a58191558c7 is one from malware, but the submission being on 21 July 2009 makes me doubt that it really is that the file.
VirusTotal analysis show the result as clean, but if it was an inoffensive PoC written on the IT department, why did they use a packer?
2009/9/5 Platonides Platonides@gmail.com:
David Gerard, how did you get the link to threatexpert.com? The behavior of 01cd53443e3e7a7453a85a58191558c7 is one from malware, but the submission being on 21 July 2009 makes me doubt that it really is that the file.
I Googled for a description of the malware's name.
VirusTotal analysis show the result as clean, but if it was an inoffensive PoC written on the IT department, why did they use a packer?
I'm not sure if anyone has contacted Jornada to check his bona fides as yet.
- d.
On Sat, Sep 5, 2009 at 4:28 PM, David Gerarddgerard@gmail.com wrote:
Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc.
http://markmail.org/message/6zsebtdrahmwzs3s
What once was rubbish is no more? :)
2009/9/5 Gregory Maxwell gmaxwell@gmail.com:
On Sat, Sep 5, 2009 at 4:28 PM, David Gerarddgerard@gmail.com wrote:
Although his actions were IMO dickish, he has some point: is there any reason to allow .exe links on WMF sites? Is there a clean method to disable them? Is this a bad idea for any reason? What should default settings be in MediaWiki itself? etc., etc.
http://markmail.org/message/6zsebtdrahmwzs3s What once was rubbish is no more? :)
*cough*
I do like your note from then:
A while back I ran clamav against all 'executable' looking external links and found one nasty file. It would be really nice if the mechanism that updates externalinks table spat out a running log of external link additions and removals that we could hook an ongoing scanner into.
Simple matter of coding, then? :-)
- d.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
A while back I ran clamav against all 'executable' looking external links and found one nasty file. It would be really nice if the mechanism that updates externalinks table spat out a running log of external link additions and removals that we could hook an ongoing scanner into.
Simple matter of coding, then? :-)
This sort of thing would hekp with some of or external antispam tools. Currently we rely on parsing edits manually to see when links are added - - some realtime and machine-readable format for notifications of such edits would be great.
- -Mike
Mike.lifeguard wrote:
Simple matter of coding, then? :-)
This sort of thing would hekp with some of or external antispam tools. Currently we rely on parsing edits manually to see when links are added
- some realtime and machine-readable format for notifications of such
edits would be great.
-Mike
File a bug? This probably depends on bug 17450 and should block 16599.
wikitech-l@lists.wikimedia.org