Posts in Kudos, Opinions and Rants
Page Content
Community Comments & Feedback to Security Absurdity Article
[tags]security failures, infosecurity statistics, cybercrime, best practices[/tags]
Back in May, I commented here on a blog posting about the failings of current information security practices. Well, after several months, the author, Noam Eppel, has written a comprehensive and thoughtful response based on all the feedback and comments he received to that first article. That response is a bit long, but worth reading.
Basically, Noam's essays capture some of what I (and others) have been saying for a while -- many people are in denial about how bad things are, in part because they may not really be seeing the “big picture.” I talk with hundreds of people in government, academic, and industry around the world every few months, and the picture that emerges is as bad -- or worse -- than Noam has outlined.
Underneath it all, people seem to believe that putting up barriers and patches on fundamentally bad designs will lead to secure systems. It has been shown again and again (and not only in IT) that this is mistaken. It requires rigorous design and testing, careful constraints on features and operation, and planned segregation and limitation of services to get close to secure operation. You can't depend on best practices and people doing the right thing all the time. You can't stay ahead of the bad guys by deploying patches to yesterday's problems. Unfortunately, managers don't want to make the hard decisions and pay the costs necessary to really get secure operations, and it is in the interests of almost all the vendors to encourage them down the path of third-party patching.
I may expand on some of those issues in later blog postings, depending on how worked up I get, and how the arthritis/RSI in my hands is doing (which is why I don't write much for journals & magazines, either). In the meantime, go take a look at Noam's response piece. And if you're in the US, have a happy Thanksgiving.
[posted with ecto]
The Dilbert Blog: Electronic Voting Machines
Once again, Scott Adams cuts to the heart of the matter. Here's a great explanation of what's what with electronic voting machines.
The Dilbert Blog: Electronic Voting Machines
Who do you trust?
In my earlier posts on passwords, I noted that I approach on-line password “vaults” with caution. I have no reason to doubt that the many password services, secure email services, and other encrypted network services are legitimate. However, I am unable to adequately verify that such is the case for anything I would truly want to protect. It is also possible that some employee has compromised the software, or a rootkit has been installed, so even if the service was designed to be legitimate, it is nonetheless compromised without the rightful owners knowledge.
For a similar reason, I don't use the same password at multiple sites -- I use a different password for each, so if one site is “dishonest” (or compromised) I don't lose security at all my sites.
For items that I don't value very much, the convenience of an online vault service might outweigh my paranoia -- but that hasn't happened yet.
Today I ran across this:
MyBlackBook [ver 1.85 live] - Internet's First Secure & Confidential Online Sex Log!
My first thought is “Wow! What a way to datamine information on potential hot dates!” :-)
That quickly led to the realization that this is an *incredible* tool for collecting blackmail information. Even if the people operating it are legit (and I have no reason to doubt that they are anything but honest), this site will be a prime target for criminals.
It may also be a prime target for lawyers seeking information on personal damages, divorce actions, and more.
My bottom line: don't store things remotely online, even in “secure” storage, unless you wouldn't mind that they get published in a blog somewhere -- or worse. Of course, storing online locally with poor security is not really that much better.....
So you think AJAX and Web 2.0 are all that and a bag of chips
You know, I would feel a lot better about this technology if someone had fixed basic problems with the way browsers handle JavaScript, about JavaScript policy specifications and compliance testing, and if there were good, usable and mature static analysis tools that could detect cross-site scripting vulnerabilities (Pixy by Jovanovic et al. comes to mind as a promising open source tool), and if people used them. These problems have been known for a long time.
- Same origin policy and shared servers. So, my home page is http://homes.cerias.purdue.edu/~pmeunier/; if I put a nasty javascript there, it can access or change the contents of other CERIAS home pages if you follow a link from my page, or if my page opens another home page for you. I made a demo which for Safari users displays Adam Hammer's home page url but with contents of my choosing (with apologies to Adam). Firefox is a bit smarter and the url displayed is instead that of my page, which could clue attentive users to the fact that the content really comes from elsewhere. Adam doesn't actually have a home page there.
- Modern browsers still can't survive a visit to this site (WARNING! Your browser will likely crash or become unusable when you click buttons on that site): Nasty Javascript Bombs (I didn't try all browsers, like Opera, but Safari died horrible deaths)
- Modern browsers can still be captured: Firefox users visit (WARNING! you won't be able to return) the jail, do not collect $200.
- Searching for JavaScript-related vulnerabilities in 2006 in the National Vulnerability Database gives 124 matches (and the year is not even over). 3 of those are accidental hits (because "javascript" was part of a file name or such). About 50% are cross-site scripting vulnerabilities, that could include the above Javascript (and likely worse code than changing your choice of hero). About 40% are coding errors in the JavaScript implementation. About 10% are still issues with the enforcement of JavaScript default security policies, or things that should explicitly be stated as part of default policies (e.g, CVE-2006-2900 and CVE-2006-2894, abusing Javascript keystroke events to trick users into typing where they didn't mean to). Cross-site scripting vulnerabilities are hard to avoid because scripts can be embedded almost anywhere inside HTML. The separation between code (JavaScript) and data (HTML) is flimsy and complex. I predict that XSS vulnerabilities will be to AJAX applications what buffer overflows and format string vulnerabilities are to C: a real pain. There is no sign that browsers have matured enough yet to be trusted in handling JavaScript safely, and this will likely continue for many years.
- Perfectly compliant JavaScript and browsers can be used to scan internal networks and even perform limited exploits.
- JavaScript seems to be used most of the time to perform tasks that are user-unfriendly (hide user interface elements and generally remove control from the user, create pop-unders, show ads, track you by history, etc...). So, I should expose myself to these, and the above and future vulnerabilities, so you can program something that's a little slicker, or poorly duplicates the functionality of executables on my system? Huh.
OSCON 2006: Where’s the Security?
OSCON 2006 was a lot of fun for a lot of reasons, and was overall a very positive experience. There were a few things that bugged me, though.
I met a lot of cool people at OSCON. There are too many folks to list here without either getting really boring or forgetting someone, but I was happy to put a lot of faces to names and exchange ideas with some Very Smart People. The PHP Security Hoedown BOF that I moderated was especially good in that respect, I thought. There were also a lot of good sessions, especially Theo Schlossnagle's Big Bad PostgreSQL: A Case Study, Chris Shiflett's PHP Security Testing, and the PHP Lightning Talks ("PHP-Nuke is a honeypot" - thank you for the best quote of the convention, Zak Greant).
On the other hand, I was very surprised that the Security track at OSCON was almost nonexistent. There were four sessions and one tutorial, and for a 5-day event with lots of sessions going on at the same time, that seems like a really poor showing. The only other tracks that has security-related sessions were:
- Linux (including one shared with the Security track)
- PHP
- Business
- Databases
- Desktop Apps
- Emerging Topics
- Java
- JavaScript/Ajax
- Perl
- Products and Services
- Programming
- Python
- Ruby
- Web Apps
- Windows


