One aspect of the latest VeriSign nonsense that I stumbled upon through Haiko Hebig is mail delivery for non-existent domains. Here's an analysis of what happens with a non-existent domain:
muenster:~# exim -bt gb@blubberfaselblubb.com gb@blubberfaselblubb.com deliver to gb@blubberfaselblubb.com router = lookuphost, transport = remote_smtp host blubberfaselblubb.com [64.94.110.11]
So an email is sent normally to the A-record (the one with the wildcard). What happens there? You can see it here:
telnet blubberfaselblubb.com smtp Trying 64.94.110.11... Connected to sitefinder-idn.verisign.com. Escape character is '^]'. 220 snubby3-wceast Snubby Mail Rejector Daemon v1.3 ready HELO blubberfaselblubb.com 250 OK MAIL FROM: blah@blubberfaselblubb.com 250 OK RCPT TO: blah@blubberfaselblubb.com 550 User domain does not exist. DATA 250 OK quit 221 snubby3-wceast Snubby Mail Rejector Daemon v1.3 closing transmission channel Connection closed by foreign host.
So there's a mail rejector running at that address that rejects every mail delivery with 550 - User domain doesn't exist. Want some paranoia? Sure? OK: it's trivial to modify the mail rejector so that it collects and archives the sender addresses provided at MAIL FROM: of the misdirected emails. I'm not saying VeriSign does that - but wildcard A-records at such a central location are an abuse waiting to happen ...
Here's the original article.
At Forbes, anyone can tell the CEO of VeriSign in a poll whether he's doing his job well or poorly. Oddly enough, he's polling pretty negatively. I wonder why that could be?

Here's the original article.
I think it's great the way he's starting it, not letting his career fade out like a Cipollini, but stopping the way he's always been known: as a workhorse among cyclists. And perhaps he'll get one more chance to finish things off at the Rhineland-Palatinate Tour. He'd deserve it.
At RADSPORT-NEWS.COM - Nachrichten-Gesamtübersicht you can find the original article.
That's what's great about Debian: the updated patches are already available on http://security.debian.org/, simply:
apt-get update apt-get install ssh
and the system is up to date again with all patches. That's what I like about it.
Apple has not yet released a software update for OS X ...
At heise online news you can find the original article.
Get involved, generate a letter and send it!
At Wortfeld you can find the original article.
Well - I hope that this isn't implemented the way Jake Savin announced it on the radio-dev mailing list: http://groups.yahoo.com/group/radio-dev/message/7946
The problem: for weblogs that don't yet have comment notification, it's quite easy to hijack the comment notification, even if option 2 from the email is used (option 1 isn't an option anyway because of its immutability).
The scenario is quite straightforward: since the setPrefs function doesn't just send the password (or rather its MD5 hash), but also all the data to query another server for validity, you can simply set up a small XMLRPC server that generally returns "ok, password is correct". You then include this in the setPrefs calls as the server to be queried. And just like that, you can use a loop to steal comment notifications from all numeric users on Userland. A classic case of not thinking things through far enough. It's quite astonishing how few people actually think about security and what it ultimately means. Too often you encounter half-baked solutions. Granted, comment notifications aren't really critical. But the function that's supposed to be protected here is called setPrefs - it's foreseeable that programmers will soon store additional settings there, and how these can then be set externally.
Where exactly is the error here? In communication with the server, that's clear. But the real error lies in the fact that a security-relevant area is implemented using a coupled system, where the coupling of systems is determined by the end user. And that last small part - determined by the end user - is the problem. System couplings in security-relevant areas must be pre-configured by the administrator; users may at best be able to choose from options. Because only the administrator can determine which sources are trustworthy for authorization. At Der Schockwellenreiter there's the original article.
A few more comments and opinions on the VeriSign nonsense.
At heise online news there's the original article.