Lousy security is all around us, and I'm not even thinking about airport security here (which, I admit, i love griping about). Here I have in mind lousy computer security. And lest you think I'm proceeding to engage in naval-gazing introspection, no -- I'm not going to write about our own products.
Jesper already wrote up his impressions of a popular wireless router. Now I'd like to tell you about some software I encountered recently.
Rights management systems (no, not evil DRM that stops you from using, on your own devices, music you've purchased) are becoming more critical in business information systems these days. It's becoming more and more difficult to use a network function -- in this case, file system ACLs -- to enforce access control to objects that can live in many places outside the network. This is the beauty of rights management systems: they offer you a way to enforce access control no matter where an object resides.
Sure, we have some pretty cool rights management stuff. But I'd like to tell you about another one. Recently at an event Jesper told me about a vendor who approached him. This itself isn't so unusual. But this gentleman was bubbling over with excitement about his new rights-management system that was entirely client based -- unlike Windows RMS, it required no server infrastructure. "Hm," thought I, and I agreed to let him show me the product.
Operationally, it was fairly straightforward -- while their software is running, any documents you create can be protected through the system. On the hard drive it's just an AES-encrypted blob. Good so far. I started chatting with him about how authorization is enforced, and while listening I tried an experiment. I had Jesper open a protected Word document inside Notepad -- always a good thing to do if you want to get an idea of how a file might be modified. At the top of the file was some XML, followed by random binary goop. Sure looked encrypted all right. Then I said, "Hey, save that thing right back to the hard drive and re-open it in Word," wondering whether a simple read-save in Notepad would do anything to his system.
We loaded Word, opened the document, and -- yes! -- a blue screen! Wham! Cue rapid expressions of surprise and fear across the sales robot's face.
What happened here? Originally the document was in Unicode. Notepad saved the file in ANSI. Obviously, then, their protection system is incapable of handling non-Unicode files, and the developers made the disastrous assumption that all input is valid. "Who would ever do that?" must have been their answer to the question "What if someone tries to open a non-Unicode file?" Probably, though, they never even thought to ask the question in the first place. The system should have checked the collating sequence and either rejectd non-Unicode files or adjusted for ANSI.
Now why do I relate this tale? It's simple -- software is difficult. Good software is more difficult. Good secure software is monumentally more difficult. Thinking about how a bad guy might abuse your application and developing reslient software that doesn't just blow up in the onslaught of attacks is something that the entire industry is only now beginning to figure out. Jesper's even talking about this now and demonstrating the good and bad in a new event session called "Is that app really safe?"
People bash Microsoft stuff for being insecure, but at least we have dedicated people whose job is to try to break our stuff. We've got the resources to do that. I'll tell ya, sometimes I'm not sure about some third parties, especially those selling "security software." Conduct your own dilligence, test the crap out of anything before you buy, and reward good vendors with your money.
I caught Jespers "Is that app really safe?" session at TechEd in Australia - was bloody awesome. I have to admit, stuff I'd never even thought about before... how do applications permission their install directories and what tricks they use to get around users with less than admin privileges.
I fully intend on giving a demonstration of some of those concepts to management, lest they make more informed decisions regarding what software we buy.
PingBack from http://proxy.11a.nu/2005/09/14/device-driver-signing-bypasses/