I don't get why, but it is a problem, how can I make it so it lets me upload jpegs too?
I tried several different jpegs before realising it wasn't going to let me upload any of them.
The PNG image was bigger in file size than any of the jpegs, but it uploaded fine anyway.
Have you tried uploading a jpeg as an attachment in a post out of curiosity?
I tried and I only get this error:
Quote
Your attachment has failed security checks and cannot be uploaded. Please consult the forum administrator.
Yay for Photoshop adding nonsense inside JPEG files that looks suspicious. There's not that much you can do to get around it.
And I think it is something to do with GD for libjpeg version mismatch ,I may be wrong but if possible for you, when try to upload JPG image, do you see any error in apache error log ?
If yes, care to share with us ?
QuoteAnd I think it is something to do with GD for libjpeg version mismatch
No, it's not. The error given clearly indicates that it is being caught by SMF's malicious image detection routine. Namely the check for <cellTextIsHtml> inside the body of an image, refer to bug 4953.
Right, I figured at first it was just a corrupted image so I tried several more from different sources. They are all doing this.
I don't know how or where to access the apache log...care to enlighten me? :)
I am happy to know that SMF does have an image malware detector, though!
In Admin>Attachments and avatars>Attachment settings, you COULD disable "Perform extensive security checks on uploaded image attachments".
But, of course, you could be leaving yourself open to some smelly brown stuff, as it were.
Up to you, GS...
QuotePerform extensive security checks on uploaded image attachments
I've always had mine tuned off and never had an issue (and we have GB's of attachments). The risk is there but I've come to the conclusion that it's more trouble than it's worth to have it enabled. In some respects it depends on your membership base and whether "
in general" you trust em.
I just keep "Re-encode potentially dangerous image attachments" enabled.
;)
No, I don't want to disable it. Our site has a lot to protect.
But why would it be barring ALL jpegs? Most are clean. This makes no sense. What I need to do is for it to only bar the Jpegs that are actually containing malware.
Just curious, here...
Are the files named with the extension "jpg", or "jpeg"?
Are both affected?
I remember this, from a couple of years back.
http://www.simplemachines.org/community/index.php?topic=418692.0
"jpg" actually. I think they were all "jpg".
Dear Groovystar, dear supporters,
Maybe to easy and already investigated (so very naive), but have you checked the "Allowed attachment extensions" in the "Administration Center » Attachments and Avatars » Attachment Settings" are those file extensions included (don't know if such has an impact on the avatar as well)
(http://sangham.net/Smileys/sadhu_sangham_sw.gif)
Johann, it has nothing to do with whether that extension is allowed. SMF would give a different error if that was a problem.
Quote from: Arantor on April 23, 2013, 11:57:45 PM
The error given clearly indicates that it is being caught by SMF's malicious image detection routine. Namely the check for <cellTextIsHtml> inside the body of an image, refer to bug 4953.
Photoshop adds a bunch of junk into JPEG files. This is one of those examples. It won't be *all* JPEGs, just ones with extra rubbish in them.
Quote from: Groovystar on April 24, 2013, 11:38:12 AM
No, I don't want to disable it. Our site has a lot to protect.
Might I ask why that suddenly is of importance?
Last week or the week before and on other earlier occasions, I had noticed this feature was not enabled on your forum at all; it seems to have been enabled only recently. Why didn't it matter then that it was not enabled, but it does matter now?
Clearly it causes more trouble than it solves with some of the pictures. :)
QuotePhotoshop adds a bunch of junk into JPEG files. This is one of those examples. It won't be *all* JPEGs, just ones with extra rubbish in them.
Might be wrong but can you not "strip" the junk out ? Thought I remembered doing that some time back...
[Hmmm ... Storman's memory is past it's "sell by" date...]
I'm not sure how you'd do that in PS, never having actually *used* it.
Perhaps export the image as a Gif or PNG? that should strip any weirdness away from the file
Quote from: Joseph @ OLI on April 25, 2013, 03:58:41 PM
Perhaps export the image as a Gif or PNG? that should strip any weirdness away from the file
But why should a user have to go through that trouble?
Unfortunately, the bug report doesn't say how it was fixed.
http://dev.simplemachines.org/mantis/view.php?id=4953
No, but it tells you it was fixed in the Github repository, and on what date, just go back through the repo and find the commits on that day and glance through them.
In Subs Graphics the check has been changed to remove cellTextIsHtml from matching.
// Check for potential infection
if (preg_match('~(iframe|(?<!cellTextIs)html|eval|body|script\W|[CF]WS[\x01-\x0C])~i', $prev_chunk . $cur_chunk) === 1)
Quote from: Arantor on April 25, 2013, 03:26:12 PM
I'm not sure how you'd do that in PS, never having actually *used* it.
In PS, use the "Save for web" option, this will strip the EXIF data from your jpg's, if that's what you mean by "Extra rubbish"
That's not what I meant by extra rubbish. I consider EXIF information useful. I consider Adobe's proprietary extensions to the JFIF/JPEG format to be largely rubbish, however.
Quote from: Arantor on April 25, 2013, 05:09:26 PM
That's not what I meant by extra rubbish. I consider EXIF information useful. I consider Adobe's proprietary extensions to the JFIF/JPEG format to be largely rubbish, however.
Indeed... It's bloating images for no reason...
Trying "saving images for the web" rather than "save as" might do the trick though.
Quote from: Arantor on April 25, 2013, 05:09:26 PM
That's not what I meant by extra rubbish. I consider EXIF information useful.
True, it is very useful when talking photos, but a pointless waste of space for a Avatar. ;)
Groovystar, in your Sources/sub-package.php. Find:
if ($file_info['compressed_size'] != $file_info['size'])
replace it with:
if (!empty($file_info['compress_method']) || ($file_info['compressed_size'] != $file_info['size']))
Um... how is that related? That's to do with unpacking gzipped data...
Part of the commit that:
https://github.com/SimpleMachines/SMF2.1/commit/43a398c88539fe5734886f6dd4da528c76668f54
Quote from: Groovystar on April 24, 2013, 11:38:12 AM
No, I don't want to disable it. Our site has a lot to protect.
But why would it be barring ALL jpegs? Most are clean. This makes no sense. What I need to do is for it to only bar the Jpegs that are actually containing malware.
I'm guessing you got around this problem then? http://warriorcatsrpg.com/index.php?topic=490301.0
Quote from: Kill Em All on April 25, 2013, 05:34:57 PM
Part of the commit that:
https://github.com/SimpleMachines/SMF2.1/commit/43a398c88539fe5734886f6dd4da528c76668f54
Yup, it's the last item on the changelog: fixes bypassing deflate step during unzip. Unrelated to the second item on the changelog regarding cellTexIsHtml.
Core, I think I didn't know that it hadn't been enabled until recently.
So uh...is there a way this can be fixed or do we just live with it? :P
I'd say disable it and ensure the recode suspicious thingies thingy is on. :)
Seems to have worked fine for a long time that way. :)
Otherwise; probably indeed a "deal with it" for now.
Oh well. :P I guess so. Will this be corrected eventually?
Yes, it is suppose to be corrected in 2.1. When that will be released... eh.