|
|
Subscribe / Log in / New account

Security

Who owns your domain?

January 31, 2007

This article was contributed by Jake Edge.

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.

Comments (20 posted)

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:
Red Hat RHSA-2007:0057-02 bind 2007-03-14
Gentoo 200702-06 bind 2007-02-17
Red Hat RHSA-2007:0044-01 bind 2007-02-06
Ubuntu USN-418-1 bind9 2007-02-05
Trustix TSLSA-2007-0005 bind, ed, elinks 2007-02-05
Mandriva MDKSA-2007:030 bind 2006-01-30
SuSE SUSE-SA:2007:014 bind 2007-01-30
Fedora FEDORA-2007-147 bind 2007-01-29
Debian DSA-1254-1 bind9 2007-01-27
OpenPKG OpenPKG-SA-2007.007 bind 2007-01-29
Slackware SSA:2007-026-01 bind 2007-01-29
rPath rPSA-2007-0021-1 bind 2007-01-25

Comments (none posted)

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:
OpenPKG OpenPKG-SA-2007.008 cvstrac 2007-01-29

Comments (none posted)

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:
rPath rPSA-2007-0020-2 rmake 2007-01-25
rPath rPSA-2007-0020-1 rmake 2007-01-25

Comments (none posted)

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:
Gentoo 200703-17 ulogd 2007-03-18
Mandriva MDKSA-2007:028 ulogd 2007-01-26

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Kernel development>>


Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds