Default, Dear Brutus, Is in Ourselves

Reading through the updates on the latest PDF-related security flaw, I found one key observation about the pathway to exploits with full access to local file systems. Quoting CTO Jeremiah Grossman at White Hat Security, a CNET story noted that

“For an attack to work, a malicious link has to point to an existing PDF file on the Web or on the target system. PDFs are abundant on the Net and finding one on a local system also isn’t hard: a sample PDF file comes with Acrobat Reader and is installed in a predictable location on PCs. [emphasis mine]“

Again and again, attackers find their job made much easier than it ought to be by the plethora of junk–sample scripts, sample data, administrative tools, whatever–that applications install in predictable locations on people’s machines. We once saw one of our own international eWEEK “OpenHack” challenges won, at the last minute, by an attacker who was too tired to look up the default admin ID and password to an entry point he’d found on the system–and who just tried the most likely string, something obscure like “admin” I think it was–and got in.

For some time, it’s been part of my product review strategy to change every single default value when installing things, intending to expose any unknowingly hard-coded directory paths or other values that ought to be subject to user control. Now, that’s not just a matter of being deliberately severe with a product: It’s a matter of making life more difficult for attackers, so that naive attack strategies don’t find you to be a soft target.

Address Space Layout Randomization in Microsoft’s Vista applies the same idea of making life more difficult for the bad guys at the lowest level of the machine, but it takes deliberate effort to do the same at higher levels as well. If we fail, as Shakespeare might have said, “default is not in our stars, but in ourselves.”