On my board at http://bw-forums.com we have been having problems getting images to upload as attachments.
The first problem began yesterday. Although the file type .png is allowed we would get an error message saying that the image couldn't be posted because it wasn't an allowed file type.
Now today we are getting this...
An Error Has Occurred!
Your attachment has failed security checks and cannot be uploaded. Please consult the forum administrator.
How do we fix this?
Try... er... disabling security checks, in your attachments settings. Read the note, there, before you do that, though.
I just checked and I did that, yesterday I think. I will now have to check that the file failed can now be uploaded. Would that also prevent a file type?
I would imagine that some filetypes are more susceptible than others, yes.
Our board is all about creating images and then attaching them. At least half will be in that format. Is there any way to solve this?
I have disabled security checks and now it seems like it's hit or miss. Sometimes they upload just fine and not the next time.
Some things to consider...
PNG files take-up a lot of room, compared to JPG files. Could the upload be timing-out, if the files are too big, filesize-wise? I know JPG files are lossy, compared with PNG. But, do the benefits outweigh the disadvantages? Maybe it'd be better for them to use JPG files, ay?
Do you have enough space, on the server, for a lot of attachments?
Do your attachment settings allow for such big files?
Just some things to consider.
this might help if the images are made in photoshop
Quote from: Spuds on January 05, 2012, 06:26:43 PM
Yup ... seen this a couple of times now .... as a work around you can do the following:
in Subs-Graphics.php
// Check for potential infection
if (preg_match('~(iframe|html|eval|body|script\W|[CF]WS[\x01-\x0C])~i', $prev_chunk . $cur_chunk, $matches) === 1)
// Check for potential infection
if (preg_match('~(iframe|(?<!cellTextIs)html|eval|body|script\W|[CF]WS[\x01-\x0C])~i', $prev_chunk . $cur_chunk, $matches) === 1)
Will allow images with that particular html "tag" to pass but other html tags will still fail.
I am not finding Subs-Graphics.php in any of my theme folders.
It should be in your Sources folder.
Oh, right....Sources. I always forget about them. Thanks, I have changed the code.
Let us know how it goes, won't you?
I have asked those who had a problem to repost the same image. We are still getting errors.
An Error Has Occurred!
Your attachment has failed security checks and cannot be uploaded. Please consult the forum administrator.
^^^ Am starting to see some of these "failed security checks" (for attachments that do not have any security problems whatsoever) in the logs (2.0.7), extra work + it's upsetting members (apart from the irritation of not being able to post, some also believe they got malware on their pc\phone). Seems smf is reading legit exif as threats. Got "extensive security checks" off, and "Re-encode" on. Thanks.
I seem to recall a discussion about this some time ago. There's something related to Photoshop images or whatever...
Can you point me to such an image? Maybe zip it?
If you want to bypass that completely, just edit Sources/Subs-Graphics.php and find
function checkImageContents($fileName, $extensiveCheck = false)
{
Add after:
return true;
Hello, thanks for replying. Sorry, did not keep any of the images (got some failing images by email, removed exif, emailed them back to members and they uploaded fine). The last occurrence was a jpg from an iphone, had normal exif and in addition gps info.
Will try your fix. Good to include options for security check, but seems 'something somewhere' needs adjustments to avoid false positives, apart from completely removing security.
Picture from iPhone? Well I might have some of those here :P
edit: just tried, I was able to upload the image without issues... Maybe different setups have different responses?
It's failing on html and eval. I fixed it by changing the code to this:
if (preg_match('~(iframe|<html|eval(|body|script\W|[CF]WS[\x01-\x0C])~i', $prev_chunk . $cur_chunk, $matches) === 1)
Aside from the small details that you just negated the two most useful tests in the batch.
While, yes, there is an issue with html, this is remedied as described above by adding the negative assertion for cellTextIsHtml, a known piece of unnecessary metadata added by Photoshop.
As for eval, your test is trivial to bypass - a space is perfectly legal syntax in PHP; a call of function ($param) with that space is completely legal. Is in other languages, too, which is why it was put in as simply eval in the first place (as some of the malware samples provided to the team were using spaces to evade some of the simpler detections such as the one you suggested. Now, if you'd put in eval\s*(, I'd agree with you, but I can see from your previous posts that you don't tend to listen to others and would generally prefer to roll your own solutions to problems...
I think you're stating the blatantly obvious regarding the checks. I'm working on my own code for my web server, so I don't really have time to meticulously go through smf's code. While I could implement far better checks, I'm not all that concerned about it. I couldn't care less really.
I'm stating something so obvious you missed both the changes. And you could care enough to tell people.
By the way, you also might want to look up NIH and the consequences for things like testing.
I really didn't *miss* anything A*rantor. I'm sure it took the Chinese military 43 years to come up with a way around your ingenious solution by simply "adding a space". I posted to help the original poster and the smf software developers. That really is what this Forum is for, is it not? All ****** slapping aside.
Except you haven't helped anyone. You've neutered a security measure by rendering it useless.
(Hint: I used to be on the SMF development team. Maybe I have inside knowledge of why these things were chosen in the first place.)
Well correct me if I'm wrong, but you can't preclude 4 letter words like html, eval and body in every 100k binary file that gets uploaded. They will randomly turn up. Especially if Photoshop, one of the most prolific software platforms, along with the exif standard, uses them in their meta data. You're going to run into problems. It's a no-brainer, really. Probably needs a bit more due diligence by the smf software developers. Just sayin'.
Which is why it doesn't. It only performs those tests on images, which generally should not include those, and if found it can still reencode the image (i.e. stripping said potentially harmful content out). The only reason this is even actually necessary is because certain browsers have been known to sniff the file's content to try to determine what it is and have been known to find webpage content buried inside images and then try to execute such content.
As for cellTextIsHtml, the only real variation on the original code, that's a proprietary extension peculiar to Photoshop and not covered in any of the variations of the JPEG standards (not even EXIF covers that one). Which is why, to accommodate them, the previous version suggested by another former SMF developer (and, I'll note, is in 2.1) specifically excludes the use by Photoshop while still detecting illegitimate use, since < followed by a null character followed by html will still be treated as an HTML tag by most of the browsers (which is why the angle bracket is not included in the regex)
If you're going to argue, please be sure to have your facts straight first.
eVal showed up *twice* in the first random image I uploaded. It had nothing to do with a virus.
And images are binary.
Interesting, because in the hundreds and hundreds of images I've uploaded to my sites, I've never encountered it even once.
Also, yes, I'm well aware that images are binary. But even binary files can contain text data (technically, text files are binary too!), my point which you're too busy trolling to have taken on board is that non-image files are not subjected to the same tests because they're served a different way where the browser will not be executing the code without the user's express consent (unlike an image request)
I can send you the image. I don't make this stuff up.
*shrug* Not my problem these days. I'm just saying that your 'I fixed it' suggestion has flaws and I explained to you the basis on which I made that determination and why it leaves it open to abuse.
If you're happy with the fix you have, fine. Just be aware that it isn't as secure as you seem to think it is, and those who call on others to have due diligence should probably have some themselves.
I generally write my own security measures. I don't rely on IIS, smf, or php. It's why I wrote my own server.
Because you never make mistakes, I assume.
If you don't trust SMF, why not write your own that's all super secure? If your own stuff is so great, why not share it and let everyone benefit?
I'm not sure what this all has to do with "me." We're talking about the smf code.
We're talking about it because you suggested a 'fix' and called out the SMF team on not doing due diligence, followed by my pointing out the problems with your fix. Thing is, you go on about how awesome you are and how you don't trust anything, why not take that to the next level and roll your own forum as well as your own web server?
We're all humbled by your skills, even when you're wrong and can't accept it.
This is getting really close to a lock, now... The support issue ended a good while ago, we all understand both points of view, let's just drop it, shall we?
I have honored the respect that Arantor deserves and locked this topic.