Does the MediaWiki software, or any independently-running 'bots, look for code placed into pages of the Foundation projects? This article claims that we're a security risk...
http://www.itworldcanada.com/a/News/036ff0b8-a384-4019-944c-bf09be58eec5.htm...
Nick
On 02/08/07, Nicholas Moreau nicholasmoreau@gmail.com wrote:
Does the MediaWiki software, or any independently-running 'bots, look for code placed into pages of the Foundation projects? This article claims that we're a security risk... http://www.itworldcanada.com/a/News/036ff0b8-a384-4019-944c-bf09be58eec5.htm...
Rubbish. I've commented accordingly.
- d.
On 8/2/07, David Gerard dgerard@gmail.com wrote:
On 02/08/07, Nicholas Moreau nicholasmoreau@gmail.com wrote:
Does the MediaWiki software, or any independently-running 'bots, look for code placed into pages of the Foundation projects? This article claims that we're a security risk... http://www.itworldcanada.com/a/News/036ff0b8-a384-4019-944c-bf09be58eec5.htm...
Rubbish. I've commented accordingly.
Only mostly rubbish:
People can, and have, externally linked to malicious software from our sites.
Of course, that can happen anywhere on the net and users (and their browser software) should be smart enough not to execute such code, but Wikipedia looks rather respectable so people may be more inclined to bypass security measures based on something on our site.
At the moment there are 209 external links to .exe files from the main namespace of English Wikipedia.
I don't think we should worry about malicious software specifically. Instead view any external link to malicious code as part of the larger problem of weak oversight of external links.
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.
It's also possible to rename malicious content as one of our accepted formats for upload and upload it. If you client will execute an 'exe' renamed to 'ogg' and sent with the Ogg mime type your client is broken, but broken clients do exist. I do not recall ever seeing an example of something malicious distributed that way on our sites.
On 02/08/07, Gregory Maxwell gmaxwell@gmail.com wrote:
It's also possible to rename malicious content as one of our accepted formats for upload and upload it. If you client will execute an 'exe' renamed to 'ogg' and sent with the Ogg mime type your client is broken, but broken clients do exist. I do not recall ever seeing an example of something malicious distributed that way on our sites.
Really? I thought we ran "file" on uploads as well as looking at the extension.
Though I suppose that wouldn't protect against the "specially crafted malicious file" of security notice fame.
- d.
On 8/2/07, David Gerard dgerard@gmail.com wrote:
Really? I thought we ran "file" on uploads as well as looking at the extension.
We do. And if it doesn't match what we think it will be... we put a notice that no one notices on the image page.
Example: http://commons.wikimedia.org/wiki/Image:Edvard_Grieg_-_03_-_In_The_Hall_Of_T...
(that file is an mp3 renamed to ogg, normally I just transcode all these but I've left that one sitting around because the copyright status on it looked suspect)
There is a constant slow stream of misnamed files that come in.... every few months I hit one and get a wild hair to go convert or delete all the ones on commons and enwiki. I've found some weird stuff, even suspicious, but not yet something which I am confident was malicious.
[[User:Gmaxwell]] gets bored and takes a pushbroom it it once a year is not a scalable method of handling this stuff.
Though I suppose that wouldn't protect against the "specially crafted malicious file" of security notice fame.
Even if we had the more aggressive filtering that you thought we had the risk of such files would remain. For the most part the handlers for the formats we do support tend to be pretty robust, internet grade stuff though..
We do. And if it doesn't match what we think it will be... we put a notice that no one notices on the image page.
The reason nobody notices it is because it looks generic. It should say why the file is suspicious. As it is, it looks like a message that could be applied to any file.
Gregory Maxwell wrote:
On 8/2/07, David Gerard dgerard@gmail.com wrote:
Really? I thought we ran "file" on uploads as well as looking at the extension.
We do. And if it doesn't match what we think it will be... we put a notice that no one notices on the image page.
That's incorrect.
If the detected filetype doesn't match the defined filetype for the extension, then the upload is rejected.
(However note that at this moment we don't have very solid detection for OGG.)
The warning on image pages about malicious code is bullshit -- we should remove it, since it has nothing to do with reality.
Greg, don't be afraid to pop things into bugzilla or work with us over in SVN to fix things up. :)
-- brion vibber (brion @ wikimedia.org)
On 8/2/07, Brion Vibber brion@wikimedia.org wrote:
We do. And if it doesn't match what we think it will be... we put a notice that no one notices on the image page.
That's incorrect. If the detected filetype doesn't match the defined filetype for the extension, then the upload is rejected.
(However note that at this moment we don't have very solid detection for OGG.)
O_o. I still find a lot of random crud uploaded as other things on commons.
We reliably detect Ogg as far as I can tell, at least in the sense that when I've checked in the past all the files on commons that had the bad mime data in the database were actually not ogg files.
I'll have to check more carefully but if we are, as I believe, correctly detecting Ogg files then we could turn on limiting on those files.
The warning on image pages about malicious code is bullshit -- we should remove it, since it has nothing to do with reality.
I just conducted a test: [gmaxwell@bessel ~]$ file ./.wine/drive_c/windows/system32/cmd.exe ./.wine/drive_c/windows/system32/cmd.exe: MS-DOS executable PE for MS Windows (console) Intel 80386
http://commons.wikimedia.org/wiki/Image:Winecmdexe.sxd http://commons.wikimedia.org/wiki/Image:Winecmdexe.svg http://commons.wikimedia.org/wiki/Image:Winecmdexe.xcf http://commons.wikimedia.org/wiki/Image:Winecmdexe.mid http://commons.wikimedia.org/wiki/Image:Winecmdexe.sxw http://commons.wikimedia.org/wiki/Image:Winecmdexe.pdf http://commons.wikimedia.org/wiki/Image:Winecmdexe.ogg
It did reject the exe renamed to both png and jpg but thats it.
Greg, don't be afraid to pop things into bugzilla or work with us over in SVN to fix things up. :)
I'm not, but I honestly thought this was 'works as designed'.
At least in the ogg case we may already have reliable enough detection.. if something is lacking there it should be trivial to fix ogg is easy to detect robustly. I don't know about the other file types.
Gregory Maxwell wrote: [snip]
Let's conduct this discussion on bugzilla instead of the Wikimedia Foundation list, maybe? :)
-- brion vibber (brion @ wikimedia.org)
wikimedia-l@lists.wikimedia.org