Security
Who owns your domain?
Using a domain registrar to reserve a domain seems a relatively straightforward transaction; one pays the registrar to ensure that the domain resolves to the addresses specified. The content at the domain would seem to be the responsibility of the registrant, leaving the registrar unconcerned with anything other than the technical DNS issues and making deposits. Unfortunately, that is not always the case as Fyodor (of Nmap fame) found out recently when GoDaddy effectively shut down his seclists.org site. With essentially no warning, GoDaddy stopped anyone from viewing the content of seclists (an excellent, comprehensive archive of security mailing lists) due to a complaint from MySpace.
Evidently concerned about MySpace username/password lists that were floating around the Internet and being posted to mailing lists, such as full-disclosure, MySpace went directly to the registrar of a site that archives the list. They made no attempt to contact Fyodor, whose email is prominently listed on the seclists contact page, to request that he remove the offending posts. When contacted, GoDaddy evidently deliberated for a minute or two before rerouting DNS requests for seclists.org to NS1.SUSPENDED-FOR.SPAM-AND-ABUSE.COM.
One would like to think that a registrar might require a complaining party to take some steps to try and have the offending content removed. One would also hope that a registrar might check with their customer about the complaint before taking any action. Unfortunately, if one uses GoDaddy, neither of those is likely to be the case. GoDaddy was willing to completely block access to content, the vast majority of which is outside the scope of the complaint, based on a single request from a large company. It is also unclear what steps GoDaddy took to confirm the validity of the complaint before shutting down the site. One would hope that randomly calling GoDaddy and claiming to be from MySpace (or another large organization) would not be a route to shutting down sites.
In Fyodor's account of the incident, he had to make numerous attempts to contact someone at GoDaddy to even find out why the site had been blocked. GoDaddy did not even see fit to tell their paying customer why they blocked the site and provided no easy route for reinstatement. This kind of behavior is not likely to lead to customer satisfaction; unsurprisingly, Fyodor is currently looking for a new registrar. He has also started the NoDaddy site to document abuses by GoDaddy and to help find alternative providers that will not cave in to the slightest pressure.
After numerous phone calls and emails, Fyodor was finally able to get the site back up. He was quite willing to remove the content that so offended MySpace as he has in the past for content, mostly from the full-disclosure list, that has generated legitimate complaints. It should be noted, however, that removing the content from seclists.org did almost nothing to fix the problem; much like trying to put toothpaste back in the tube, reversing an information leak onto the Internet is well nigh impossible. Worse yet, the way they went about things caused enough of a stink that now even casual observers know how to track down this password list; the malicious folks, of course, already had it.
This story might have been less damaging to GoDaddy (and MySpace for that matter) had they admitted a mistake was made and that in the future they would make some efforts to work with their customer to resolve complaints. Instead, they did the opposite and went on the offensive claiming that giving any notice was "generous" while essentially admitting that the notice was on the order of one minute. They were also quick to play the "its for the children" card in defending their actions. Somehow the fact that the lists had been available for nine days and that MySpace did nothing at their end (such as suspending the accounts if there was a password match from the list) to alleviate the problem, went completely over the heads of the folks at GoDaddy.
It seems implausible that MySpace would put up with the same treatment. If one were to find a page at MySpace with a list of usernames and passwords for that site or some other site frequented by teenagers, does that mean you can have MySpace routed to spam-and-abuse.com with a simple phone call to their registrar? The whole idea of registrars participating in web censorship is a slippery slope and one that sensible registrars will avoid; do they want to be in the middle of these kinds of disputes? It probably seemed very easy to GoDaddy in this case, MySpace vs. a 'hacker', but where are they going to draw the line?
For domain owners, this situation should provide an opportunity to go back and review the Terms of Service at your registrar. A community effort, like the one at NoDaddy, can hopefully identify a number of registrars who are more interested in providing the service they are paid for to the people who pay them than they are in appeasing the MySpaces of the world.
New vulnerabilities
bind: denial of service
Package(s): | bind | CVE #(s): | CVE-2007-0493 CVE-2007-0494 | ||||||||||||||||||||||||||||||||||||||||||||||||
Created: | January 26, 2007 | Updated: | March 14, 2007 | ||||||||||||||||||||||||||||||||||||||||||||||||
Description: | The bind package is vulnerable to two remote denial of service attacks in which attackers can cause the bind daemon to to crash or exit unexpectedly by providing malformed data to the daemon in a DNS request. | ||||||||||||||||||||||||||||||||||||||||||||||||||
Alerts: |
|
cvstrac: denial of service
Package(s): | cvstrac | CVE #(s): | CVE-2007-0347 | ||||
Created: | January 29, 2007 | Updated: | January 31, 2007 | ||||
Description: | Ralf S. Engelschall from OpenPKG GmbH discovered a denial of service (DoS) vulnerability in the CVS/Subversion/Git Version Control System (VCS) frontend CVSTrac, version 2.0.0. | ||||||
Alerts: |
|
rmake: privilege escalation
Package(s): | rmake | CVE #(s): | CVE-2007-0536 CVE-2007-0557 | ||||||||
Created: | January 26, 2007 | Updated: | January 31, 2007 | ||||||||
Description: | Rmake prior to version 1.0.3-2-0.1 does not drop supplemental users in the changeroot environment for builds. This provides malicious packages with excess permissions that are configuration-dependent, and may allow local users to run arbitrary code as the root user. | ||||||||||
Alerts: |
|
ulogd: buffer overflow
Package(s): | ulogd | CVE #(s): | CVE-2007-0460 | ||||||||
Created: | January 29, 2007 | Updated: | March 19, 2007 | ||||||||
Description: | A buffer overflow in ulogd has an unknown impact and attack vectors related to "improper string length calculations." | ||||||||||
Alerts: |
|
Page editor: Jonathan Corbet
Next page:
Kernel development>>