Malicious attachments through support tickets

[bodhisattva]

If the file can't be run on the server, there shouldn't be an issue. With this patch, it is impossible for the uploader to know where to find the file, as it is assigned a random filename and you can also move the attachments folder so is that really an issue?

probably is not. i am just be reactionary/paranoid.

[Dominic]

ok cool. what about to block dynamic content in trojan image files, (<script> cookie.stealer(blah blah blah) </script>) ?

 

i am still of the mindset that if you are going to have image uploads there needs to be some image parsing, through GD or AJAX along those lines, that checks for dynamic content, or that the file is in fact a valid image file and not something else with that extension.

 

btw, not trying to be a pain. just wanting to make sure things are as secure as can be, for everyone. i had attachment uploads off by default, but thats just because i hadn't seen the code to know how secure it was, and i guess i went into wait and see what happens with others mode.

 

i appreciate the quick fixes and solutions and the new release. good job Matt!

If the $_FILES['name']['type'] is checked (the MIME type of the file) then you can verify the file type after it's uploaded, and I don't think browsers will execute code in images when they have the correct extension and mime type

[Jordan]

YAY! I'm glad that I mentioned this here, so it was able to get fixed =D

[ppc]

just curious,

 

lets say php code ends up in a ticket, whmcs wouldnt run it, would it?

 

thanks

[Matt]

No, that's never been the case. The issue was a bug with PHP mime type handling that allowed ".php.gif" files uploaded as attachments to be run as PHP files on the web server. PHP code can't be executed from a tickets content.

 

Matt