Two weeks ago I said we'd have some IETF Internet-Drafts related to Atom and APP. The first one just got published: draft-rsalz-atom-adv-sec, "Advanced Security Processing for Atom and APP Documents." Whew, what's a mouthful. Most people will find the reading to be tough going, I think. It requires understanding the Atom and APP specs, as well as WS-Security (and by reference, XML Digital Signature and Encryption) . It's probably not a large community of potential readers; Atom/APP is firmly planted in the REST world, and WS-Security, obviously, comes from the Web Services world.
Basically, we use WS-Security so that you can use signatures and encryption over parts of Atom/APP documents, and that you can target those parts to individual or several users. For example, a consulting service could have an Atom feed of their reports, and encrypt those entries that are only available to premium-class customers.
We also define a new element, "atomsec:credentials", that lets an atom:link element hold certificates that can be used to verify any signatures on the pointed-to content, or the SSL certificate for the server. For example, a virtual-hosted APP server could have a different SSL cert for each feed, and the credentials element lets the administrator configure the service document appropriately.
Our goal is to have this be part of the son-of-atompub working group. For now, any discussion should happen on the atompub mailing list.
Security, Middleware, Appliances
RSalz 2700011QK0 635 Visits
Codenomicon, a Finnish security company, has been in the news recently because of a widespread set of vulnerabilities in XML parsing. Their press release is at http://www.codenomicon.com/news/press-releases/2009-08-05.shtml, and the official report from the Finnish CERT team is at https://www.cert.fi/en/reports/2009/vulnerability2009085.html. The vulnerabilities are pretty widespread, affecting most of the common C, Java, and Python toolkits. Everyone's working on fixes.
Basically, the attacks involve things that DataPower has been calling "XDos" for several years; here's a press release from 2003. But more importantly, we've been catching and preventing these kinds of things for more than six years. Sometimes, the paranoia pays off, and they really are out to get you... eventually.
Of course, we're not perfect -- we've had our own "packet of death" DoS, even though it was had fixed before the vulnerability was posted. Nothing's perfect, which is why a "defense in depth" is important.
RSalz 2700011QK0 544 Visits
No, not in the way you might first think (code bloat, huge data tables)... this story is about a real denial of service issue, although it was self-inflicted and not an attack.
These indexes were all correctly configured except for one attribute, secuuid. As can be seen from the following close-up, the letter i in secuuid was not an ASCII lower case letter i, but rather a Turkish lower case dotless ı:
RSalz 2700011QK0 482 Visits
Eve Maler is leaving Sun to start at PayPal. This is interesting for a couple of reasons:
RSalz 2700011QK0 1,015 Visits
In a talk on cloud security at the recent Blackhat USA 2009 event, Alex Stamos, Andrew Becherer, and Nathan Wilcox from iSec Partners gave a talk on cloud computing security. Update:: His slides are available at http://www.slideshare.net/astamos/cloud-computing-security. Also a web search for "alex stamos cloud" finds good links; David Berlind's blog entry and interview is good.
Virtual images, by design, are identical. This may mean that the random numbers generated by any image could be identical for all instances of that image. This is one of those things that's obvious once you think about it, but Alex and colleagues deserve credit for being the first. The devil is in the details, but this is the kind of thing to take very very seriously. Random numbers are crucial for security and if you they're not actually random, bad things can happen.
More then a decade ago, Ian Goldberg and David Wagner broke Netscape's SSL2 implementation because it didn't have enough randomness in generating session keys. Last year, Luciano Bello discovered that Debian broke the random number generator so that weak keys for SSL, SSH, etc., had been being generated for a couple of years, leaving these keys potentially guessable.
As more computing moves to the cloud, we need to make very sure that we're not building security on a foundation of sand.[Read More]