When a file is attached in SMF, it's stored in the attachment folder with an encrypted filename.
This filename should have an extension on it and it should be an extension that suggests a binary file so FileZilla does not attempt to download it as a text file by default.
2.1 would be a great time to actually implement this so all existing files can be swept up and dealt with but an examination of the 2.1 codebase as at last week suggests that it isn't doing this.
There's no security or performance implications but it would solve a lot of headaches with attachments, users and FileZilla...
Maybe some will quit blaming Filezilla for this problem. I've seen it a handful of times across the boards when people have problems like this. Sounds like a good idea to me. Filename is encrypted so there's no reason not to have an extension IMO.
Agreed.
Whoa! Brad, nice seeng ya.
Does it has to be an already known binary extension or can they use .smf? I don't know how filezilla treats unknown file extensions.
By default Filezilla is set to upload a file with an unknown extension as ASCII.... Filezilla developers seem to be unwilling to change this default behavior. There is a setting in filezilla to change the default. I read a bug in the filezilla bug tracker where even the phpBB developers were asking them to change this behavior. And that was like 4 or 5 years ago IIRC.
Just one more reason this would be a good change. :)
Hey Mick and Suki!! Good to see you guys!
ETA: Even found the old bug post. Here's the link.
http://trac.filezilla-project.org/ticket/4235
We can use any extension we want as long as it's not in the list of extensions that FileZilla treats as ASCII by default. I do agree that this should be done, since the FZ devs don't seem to understand the problems.
Any suggestion? It is important to chose carefully what the extension would be, many users do often take a look at the attachment folder, if you decide to use some common and known extension, some users may want to open the file.
Found this list: http://en.wikipedia.org/wiki/List_of_file_formats
Is there a list of files that filezilla treats as binary?
Yeah, but why not use the same extension that the file already has? There's no need to hide the extension of the file if you're already encrypting the name. Filename will likely never be able to be guessed anyway.
That way a php file would remain a php file and if htaccess disappears for whatever reason it would be only a brute-force away from being executed.
That assumes that the person knows what the encrypted file name is. If that is the case, you have bigger problems to worry about. :)
Since all attachment's names are handled via Subs::getAttachmentFilename() the mot basic implementation of this would be adding a harcoded ext to the full path that is returned: https://github.com/MissAllSunday/SMF2.1/commit/de11d5504102c336151d1cab1cad74ec902c277b
Couldn't noticed if anything was broken by this, (it shouldn't be since it doesn't mess with the DB fields) but I didn't test it well enough apart from uploading and deleting a few attachments.
The only inconvenient of course is handling old attachments, for that I simply am checking if the exact same file do exists without the ext, if it does, do a rename() on it: https://github.com/MissAllSunday/SMF2.1/commit/17240c386bce3b77625e49f853e546ec84dad83b
Quote from: IchBin™ on September 15, 2013, 12:58:36 PM
That assumes that the person knows what the encrypted file name is. If that is the case, you have bigger problems to worry about. :)
No, a brute-force attack doesn't need to know the name.
You could try the Change Attachment Extension (http://custom.simplemachines.org/mods/index.php?mod=3039) mod.....
Quote from: emanuele on September 15, 2013, 05:50:04 PM
Quote from: IchBin™ on September 15, 2013, 12:58:36 PM
That assumes that the person knows what the encrypted file name is. If that is the case, you have bigger problems to worry about. :)
No, a brute-force attack doesn't need to know the name.
Only so much you can do ema. The likely hood of htaccess going away is not something I would worry about. If that is the case, then we should worry about servers that aren't configured properly and parse files that they shouldn't (without file extensions). That's about how remote the possibility of these two things happening is IMO.
Stupid person's question - can we not invent an extension? Like .att for attachment? Or does it have to be one that FZ actually recognises?
Quote from: ChalkCat on September 16, 2013, 01:44:07 PM
Stupid person's question - can we not invent an extension? Like .att for attachment? Or does it have to be one that FZ actually recognises?
If you add something like .smf or any other new ext then filezilla will treat it as an "unknown" file and thus will be treated as ASCII instead of "as is".
gotcha.
pain in the bloody....
at this point, I'd say go with IchBin's reasoning... I understand emanuele's concern, but there's only so much we can do and still keep things working simply... :)
Quote from: Suki on September 16, 2013, 01:51:38 PM
Quote from: ChalkCat on September 16, 2013, 01:44:07 PM
Stupid person's question - can we not invent an extension? Like .att for attachment? Or does it have to be one that FZ actually recognises?
If you add something like .smf or any other new ext then filezilla will treat it as an "unknown" file and thus will be treated as ASCII instead of "as is".
That's not the case actually. If the default transfer type is "auto" and the file has an extension, it will be uploaded in binary mode unless that extension is in the list of types that should be treated as ASCII by default. There are separate settings for files without extensions and "dotfiles". I just tested it with a CSS file that was renamed to ".extension" and the file was uploaded in binary mode (you can see which mode it's choosing by looking at the commands list).
On the topic of what extension to actually use, I think it would be best to give all the files the same extension, rather than using the "proper" one based on what the file really is. This allows us to maintain the same level of security as we have without an extension on the file while at the same time getting around the problems caused by the incompetence of the FZ developers.
well, then.... if you have confirmed this, I agree - and I think this resolves the issue that emanuele was concerned about.
Why don't we do it as .smf
for people aware of the extension it may be confusing
http://whatis.techtarget.com/fileformat/SMF-MIDI-audio-file
also we would need to apply this to all existing attachments and avatars not just new ones.
It seems no one actually payed attention to my commit.... oh well, lesson learned I suppose.
Sorry Suki... I don't read github that well.... what did your commit do?
The same you are talking about:
- Having a unique extension for all attachments.
- Handling old attachments and add the extension if they doesn't have one yet.
ah. excellent.
Oldiesmann, can you check and accpet her commit?
After all, if she's alreayd done, it, cycle it in! :)
Why use .iso? Why not .dat?
Was the first extension I came up with. They can (and will) change it. Not a big deal.
SMF 2.1 now does this by default.