Virus Found [UPDATE: Unrelated to Moving Pictures] (1 Viewer)

[fforde]

Well according to the VirusTotal PDF you linked, this is a buffer overrun exploit from 2004. But I am trying to reproduce the issue by setting up the same movies on my test system using the same data providers, but all images that are downloaded for me are clean according to VirusTotal. I am not really sure what to do. If we could identify a malicious image on a web server we pull from, then we could alert the site owner. Moving Pictures also sometimes converts an image file to JPG format depending on the source, so I suppose it's possible that the Windows GDI library we use is creating in some cases malformed files.

Can you provide debug log files from when one of these image files is downloaded? To generate such files you'd have to try to recreate the same situation that caused the image files to be grabbed in the first place.

 

[TheWho]

well i can try to... but i don't know exactly how to "force" the virus to be downloaded...

 

[fforde]

If it is in fact a malicious file on a web server then you should be able to delete all the covers from your covers folder for the given movie and re-retrieve artwork for that film. Because theoretically the same image files will be downloaded again, you should be reproducing the issue. If you can not consistently reproduce the issue this way, then it means either a bug in the image file writing logic in Moving Pictures, or the cause is something local on your machine.

 

[TheWho]

fforde this is just a wild guess between you and me but couldn't it be a loadbalancing thing.... like... cover-loadbal-server1 got a non infected file but cover-loadbal-server2 got a infected file....

anyway..... i will try this later on today (its 16.50 here now...)

 

[jameson_uk]

I remember an MS vulnerability to do with jpg files several months ago.

Could it be that your machine is infected by some other malware and this is trying to exploit this vulnerability each time you download a jpg?

This particular vulnerability was patched in windows some months ago so your machine would only be at risk if you have not pactched in over six months. That said not ideal but have you tried downloading other images from the web and naming them in the same format as these?

AIUI the actual exploit is in a header being set to 1 or 0 when the only allowable value is 2 so I doubt NOD is being as silly as looking at the name mask but could be....

 

[TheWho]

jameson_uk i have almost never ever had any malware/spyware or virus/trojan/masks on my computer but to be 100% sure i will run anti-malware, spybot, ad-aware. (have already run a complete nod32 scan)

 

[Ratti3]

I get this too on one movie (Basic Instinct), I'm using Win 7 32, MP 1.0.2, MP 0.7.5, UK IMDB Scripts. Using Mcafee Ent 8.7
Don't have access to logs atm.

Edit: This is a brand new install of Windows.
Edit 2: I will provide the logs later, I can recreate this everytime. Not near the HTPC at the moment, sorry.

 

[fforde]

Thanks for the additional feedback, but really can not help or investigate the issue unless someone posts a debug log file from when a bad image file is downloaded.

Edited to be less of an ass. Sorry I was grumpy this morning. ><

 

[Ratti3]

Please see attached logs

 

[fforde]

Thanks for the log files Ratti3. What is happening is the windows logic we are using to save the image file to disk is failing. Based on the log files here, I cant know the exact nature of the error, simply that we call Image.Save(), a Windows function, the method then errors out, and we do not handle the error properly. We have actually added error handling for this in 1.0, so I think it no longer occurs with the new Beta. Can anyone confirm this? Has anyone seen this problem in Moving Pictures 1.0?

If this is in fact the root of the problem, it would be possible to back port this fix to 0.7 while a 1.0 Stable is pending. I think we are just a week or two from a 1.0 Stable though so I am hesitant to do this back port. :/ Any thoughts?