SMF Development > Bug Reports
[2.0] encrypted attachment file names and FTP
Antechinus:
--- Quote from: MrPhil on May 16, 2012, 09:41:02 PM ---There are two different issues here. One is that FZ (at a minimum) corrupts these extensionless files by assuming they're ASCII. A solution to that is to force binary by adding an arbitrary binary extension such as .doc. A better solution (from the file transfer viewpoint) is to use the correct original extension. The counterargument is that weakens security. If no one is going to guess the name, how are they going to run this malware file?
--- End quote ---
Did think of one possibility, even though it would be cumbersome to run in practice. You could set up your script so that it attempted to run the malware in (say) every gif in the attachments folder. As long as you had the right code, it could probably cycle through them all until it hit the right one, even if you had no idea what the name was. Not sure exactly how you'd write such a beast, but it's probably possible.
emanuele:
--- Quote from: MrPhil on May 16, 2012, 09:41:02 PM ---The second issue is that after you've downloaded such a file, you need to rename it to the proper extension so it can be displayed or otherwise used. This problem would be bypassed by keeping the original extension. Now, if someone is going to bother to download an attachment, wouldn't they likely know the original name? (so they know they have the right file) What would be the purpose of downloading a random attachment file, such that you need to figure out a proper extension? Would anyone reasonably expect to download a specific attachment file, without knowing what its proper name (and extension) are? In what ways would people legitimately want to make use of an attachment file with a mangled name, whether or not the extension is correct?
--- End quote ---
So we should even attach the entire original file name to the hash? ???
I hope I got it wrong.
On a general level (and again not at SMF development level): instead of being here complaining with SMF about this "bug" you should go to fileZilla and complain about *their* bug first.
Side note: looking at the code that generates the server-side attachment I would change the time to microtime(true).
MrPhil:
--- Quote from: Antechinus on May 17, 2012, 02:28:07 AM ---As long as you had the right code, it could probably cycle through them all until it hit the right one, even if you had no idea what the name was. Not sure exactly how you'd write such a beast, but it's probably possible.
--- End quote ---
Chicken-and-egg. That would depend on their dropping malware (PHP code) under a known name into the system in the first place, so they could access the directory information and find out all the attachment names to potentially run. If they can't do that, would there be any way to discover the (mangled) name list from the browser level, regardless of whether the correct extension is given? If they can do that, there's no need to find the code with the mangled name ... just run your malware directly. You need to give a specific name (no wildcards) on the browser URL, don't you?
I would be as worried about the attachment ID prepended to the front of the mangled name as I would a correct extension. As long as neither provides any clue as to how the name can be unmangled (or, how the known name being sought was mangled in the first place), it's probably safe.
MrPhil:
--- Quote from: emanuele on May 17, 2012, 05:54:29 AM ---So we should even attach the entire original file name to the hash? ???
I hope I got it wrong.
--- End quote ---
You did. I'm just proposing the correct extension be used, or something distinguishing between ASCII and binary downloads (.txt/.doc), or at worst, binary-only .doc. If someone planted malware in a MyLittlePony.jpg attachment, they would know only that the mangled file has a .jpg or maybe .doc extension, and nothing else about the name being used. The intent is that they cannot discover the actual mangled name of the file, and invoke it directly, right? Come to think of it, even just adding a more or less random string to the name should be enough (i.e., append the original name to the end).
N.B.: Do not prepend the original name to a random string. In the case of Windows servers, the "8.3" form of the name might be used to invoke the file.
The whole point of the exercise is to store an attachment file under a different, unguessable name so that a hacker can't invoke it directly from the browser. Correct? Are there any other routes a hacker could take to run this file, via remote access (i.e., not breaking into the server in the first place)? As a secondary, though still important, consideration, the file must be transferred in the correct mode so that it doesn't get corrupted in a backup.
--- Quote ---On a general level (and again not at SMF development level): instead of being here complaining with SMF about this "bug" you should go to fileZilla and complain about *their* bug first.
--- End quote ---
According to the links that you provided, people (including phpBB developers) have been complaining to the FZ folks for years about this problem, and have been stonewalled the entire time. It ain't gonna happen. SMF needs to make its system invulnerable to damage from FZ's bad design, and not try to persuade them to fix things.
Antechinus:
--- Quote from: MrPhil on May 17, 2012, 11:32:36 AM ---
--- Quote from: Antechinus on May 17, 2012, 02:28:07 AM ---As long as you had the right code, it could probably cycle through them all until it hit the right one, even if you had no idea what the name was. Not sure exactly how you'd write such a beast, but it's probably possible.
--- End quote ---
Chicken-and-egg. That would depend on their dropping malware (PHP code) under a known name into the system in the first place, so they could access the directory information and find out all the attachment names to potentially run. If they can't do that, would there be any way to discover the (mangled) name list from the browser level, regardless of whether the correct extension is given? If they can do that, there's no need to find the code with the mangled name ... just run your malware directly. You need to give a specific name (no wildcards) on the browser URL, don't you?
I would be as worried about the attachment ID prepended to the front of the mangled name as I would a correct extension. As long as neither provides any clue as to how the name can be unmangled (or, how the known name being sought was mangled in the first place), it's probably safe.
--- End quote ---
Well if there's no way of running malware without knowing the actual file name, there's absolutely no reason to not keep the original extension, and some very good reasons for keeping it. Solution is obvious. :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version