SELECT ... INTO OUTFILE allows writing to the filesystem.
That ability doesn't help an attacker as much as you think. Per the MySQL reference manual: "The SELECT ... INTO OUTFILE 'file_name' form of SELECT writes the selected rows to a file. The file is created on the server host, so you must have the FILE privilege to use this syntax. file_name cannot be an existing file, which among other things prevents files such as /etc/passwd and database tables from being destroyed." This means that while "INTO OUTFILE" can create new files --- if and only if the user has FILE privilege --- it still can't overwrite settings in something like "config.inc.php," which effectively makes "config.inc.php" data that can't be changed by an attacker --- "config.inc.php" is the anchor of your sea of data, and nails down things that shouldn't be allowed to float away.
I don't see how having something in a file helps security. If Coppermine can create and edit the file an attacker can too.
As I pointed out before: If the file already exists, and is rw-r--r-- or something like it, it's data that Coppermine itself --- that the web server, and thus any attacker --- can't edit. If all of your most vital configuration settings are stored in a file instead of in the database, the attacker can't change them even with an SQL injection, and, as in the case of the page headers, that can be the difference between executing unauthorized code and working fine.
How do you propose information can be 'checked, verified, analyzed, and validated' when only the database knows the information in the first place? If there is a user entry in the database how can Coppermine know if it is valid or not? How can that work with a 3rd party bridge?
Not all of what the database knows is uncheckable. In fact, a lot of what's in there can usually be validated in any web app. Again, consider the page headers: Let's say you want to leave that setting in the database. There are a number of places where the page-header file itself could be stored, and a number of places where no sane site designer would ever put it, like "albums/". Allowing it to exist in those places is just begging for a security breach. Allowing it to have ".jpg" or ".zip" as a file extension is just as bad.
Any paths or names in the database can usually be checked against the contents of the filesystem; internal references in the database can often be checked against each other without adding significant numbers of additional queries; and many things that can't be
absolutely checked can have simple "sane" vs. "crazy" heuristics applied to them --- like making sure that a field that's supposed to contain an integer really contains an integer and not an arbitrary string, or making sure that a string that's supposed to be a valid filename doesn't contain newlines. preg_match() and file_exists() are your friends --- and your first line of defense against the bad guys.
I check nearly all values in the web software I write for my clients; I don't see any fundamental reason why you can't do the same.
Coppermine was created a long time ago with no real emphasis on security. Each release we improve things (eg. Coppermine 1.5 (dev version) has a wrapper around user supplied data) but there is still a long way to go.
I understand that, and it was actually pretty obvious just reading the code. And I know all too well how much of a pain in the @$$ upgrading and patching a piece of cranky old software can be. But we're at the stage now where security is no longer optional in software: Coppermine already has a bit of a reputation as being "leaky" in security circles, and the last thing you want is for the general public to start avoiding it because of security issues. Your upgrades have mostly been reactive, but security is not just reactive: It can be proactive and preventive too. You need to think like your attackers and foil them before they have a chance to abuse your code.
I shudder to think whether Coppermine is vulnerable to things like rainbow-table attacks or XSS attacks or man-in-the-middle attacks. But, then, I've got code vulnerable to rainbow tables and man-in-the-middle too, so nobody's perfect
@phantom-inker: I appreciate you taking the time to share your thoughts with us. As Nibbler suggested, we are actually trying to improve things while developing cpg1.5.x (from a dev's perspective, cpg1.4.x is dead and will only be patched if needed in terms of security holes or bugs, bit not in terms of overall architecture). However, this discussion should not be lead within this very thread, as newbies might mistake our discussion about potential (yet-to-be-exploited Wink) flaws with actual issues that are already known and that could be fixed easily. This being said, you're welcome to start a new thread on the misc board with your proposals and ideas.
I'd be happy to do so, but you locked down the misc board for new threads
On a more serious note, if you can split this thread and move these postings there, that'd probably be best.
Author
Topic: Someone has Redirected my Site to cdpuvbhfzz.com-What do I do? (Read 327684 times)