- NANOG - lists.nanog.org

OT: Interesting visuals. interesting message, 560 kb, 5 min to run (if you have a moment)
by Dr. Jeffrey Race 18 Sep '03

18 Sep '03

Interesting diversion from quotidian banalities <http://www.fdnylodd.com/BloodofHeroes.html> Jeffrey Race

1 0

VeriSign responds to complaints via press release
by Jeff Wasilko 18 Sep '03

18 Sep '03

----- Forwarded message from Dave Farber <dave(a)farber.net> ----- If this was Microsoft issuing a statement like this we would really go through the roof. Since when in the Internet do we talk with technical people AFTER the fact and AFTER the disruption. In other words BULL. Can we sue them for email disruption? Dave >Delivered-To: dfarber+(a)ux13.sp.cs.cmu.edu >Date: Wed, 17 Sep 2003 19:27:49 -0400 >From: "Wingfield, Nick" <Nick.Wingfield(a)wsj.com> >Subject: VeriSign update >To: "'dave(a)farber.net'" <dave(a)farber.net> > > >Dave, >In case it's of interest to IP... >Nick > > >=WSJ: VeriSign Responds To Complaints About New Service > >Dow Jones News Service via Dow Jones > > > By Nick Wingfield > Of THE WALL STREET JOURNAL > > > SAN FRANCISCO (Dow Jones)--VeriSign Inc. (VRSN), responding to an >outpouring >of complaints about a new service that exploits the typing errors users make >when surfing the Web, said it plans to work with technologists to remedy >disruptions the service has caused to some Internet applications like >e-mail. > > At the same time, the VeriSign service triggered a huge increase in the >amount >of traffic flowing to the Mountain View, Calif., company's Web site, a >portion >of which may be the result of a hacker attack against the company, VeriSign >said. > > (This story and related background material are available on the Journal's >Web >site, WSJ.com.) > > VeriSign on Monday introduced the service, dubbed Site Finder, which >steers >users who attempt to reach nonexistent Web addresses to a site operated by >VeriSign. The company is able to take control of the traffic because it >operates >the master list, or "registry," for all Internet addresses ending in ".com" >and >".net." > > VeriSign said it designed Site Finder as a navigational aid for Web users. >It >also receives revenue from the additional traffic through relationships with >Overture Services Inc. (OVER) and Yahoo Inc.'s (YHOO) Inktomi, which guide >users >to Web sites. > > The new VeriSign service infuriated many network operators, though, who >say it >has disrupted the functioning of e-mail and other applications. Among the >complaints about the VeriSign service is that it hurts the ability of >Internet >service providers to block "spam" sent from Internet addresses that don't >exist >- a common technique normally used to stem the flow of junk e-mail. Internet >service providers and software groups have developed patches that prevent >the >VeriSign service from working on their networks. > > In a statement Tuesday, VeriSign said it would release technical >information >on its Web site that would help network operators adapt their software so >they >could block unwanted e-mail again. "In the course of implementation, various >users asked us to modify the service to accommodate anti-spam applications," >the >company said in the statement. "Because VeriSign strongly supports >appropriate >technical measures designed to reduce unwanted spam, we are reaching out to >users and the community to make appropriate adjustments to the service." > > "We remain committed to ensuring that Site Finder improves Web navigation >and >the user experience," VeriSign added. > > Despite the controversy, VeriSign's efforts to nab control of typo-prone >Internet users appears to be having a sizable impact on the volumes of users >visiting its site. Traffic to the company's Web site on Tuesday skyrocketed >to >about 1.3 million visitors from an average of about 100,000 visitors on the >previous four Tuesdays, according to measurement firm ComScore Networks Inc. > > > Some of that may have been due to malicious - not typo - traffic. A >VeriSign >spokesman said the company experienced a "denial of service" attack on its >Web >site on Tuesday, in which hackers use computers to bombard Web sites with >traffic in hopes of overloading them. The attack appeared to subside by >Wednesday, the spokesman said. A ComScore spokesman said it's "very >unlikely" >that a denial of service attack on VeriSign had a significant impact on the >ComScore traffic figures.

3 2

Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 17 Sep '03

17 Sep '03

> > i don't think so. verisign is on public record as saying that the > > reason they implemented the wildcard was to enhance the services > > offered to the internet's eyeball population, who has apparently > > been clamouring for this. > > My question is, if this was to serve some need of internet users, why > does port 25 work and not port 80? i wouldn't speak for verisign on that point even if i knew the facts (which i don't) but i'm guessing that the internet today has mostly just got web browsers on it, and verisign is principally concerned with those people. > So, I'm curious as to your opinion about the bigger issue. Maybe it > has been stated somewhere else, and if it has, please direct me to > it. I've read all of your posts about this on nanog, and you do an > excellent job of staying neutral. You point out that what Verisign is > doing is technically valid and therefore shouldn't be addressed with a > technical "solution", but you also release a patch for Bind to > accomodate obvious demand (and to save users the hassle of > implementing half-assed patches with hardcoded A records). However, > you do so without actually stating whether or not you think the > wildcards are a (policy) problem or not. let me be clear on that point, then. i've now heard some people from icann's various committees and boards say that they either were not consulted, or that they were consulted and they advised against this, and they feel rather strongly that these wildcards should not have been put in. so, there is a policy problem, which is that folks don't agree as to whether verisign is the owner or the steward for .com and .net, and folks don't agree on whose permission is needed for what. i would like to see that policy problem resolved, but i have no part in it, and i don't actually care which way it's resolved, so long as it is resolved. we all need to know whether verisign is the owner or steward, and we all need to know whose permission is needed for what, and we all need to know what to expect. resolving the policy problems will give us all those things. so, i hope that someone (else) resolves those policy problems. (if y'all need me i'll be out washing my cat.) > You point out that there is high-level ambiguity about the > relationship between DOC, ICANN, and Verisign, and about whether or > not Verisign should have the public's interest in mind. speaking as an individual, and not as a party to policy discussions between the people who need to set and follow policies in this arena, i can say: > Do you think > they should have the public's interest in mind? yes. because any tld who does not do this gives ammo to the kooks who want to set up their own alternative namespace. that would be bad for the public since it would be even more chaotic than what we have now, and chaos is expensive and painful. > And do you think the > wildcards are in the public's interest? no. i liked it better when vix.com's parent domain (com) had no wildcard, so that if someone mistyped my domain name they got a hard dns error rather than a verisign search page or mail error. > I can certainly empathize with wanting to stay neutral, but I think we > need somebody who carries substantial influence in the name resolution > community to have strong opinions about such a poor policy decision. i sure hope you find her (or him). good luck with that. see you all in san diego (usenix) next month, when i shall joyously lampoon all of this bitrot during my invited talk on the subject of internet governance.

1 0

Re: Change to .com/.net behavior
by Paul Vixie 17 Sep '03

17 Sep '03

> > ... shouldn't they get to decide this for themselves? > > Returning NXDOMAIN when a domain does not exist is a basic > requirement. Failure to do so creates security problems. It is > reasonable to require your customers to fix known breakage that > creates security problems. that sounds pretty thin. i think you stretched your reasoning too far. > VeriSign has a public trust to provide accurate domain > information for the COM and NET zones. They have decided to put their > financial interest in obscuring this information ahead of their public > trust. i'm not sure how many people inside verisign, us-DoC, and icann agree that COM and NET are a public trust, or that verisign is just a caretaker. but, given that this is in some dispute, it again seems that your customers should decide for themselves which side of the dispute they weigh in on. > Microsoft, for example, specifically designed IE to behave in a > particular way when an unregistered domain was entered. Verisigns > wildcard record is explicitly intended to break this detection. The > wildcard only works if software does not treat it as if the domain > wasn't registered even though it is not. then microsoft should act. and if it matters to you then you should act. but this is not sufficient justification to warrant a demand by you of your customers that they install a patch (what if they don't run bind?) or that they configure delegation-only for particular tld's (which ones and why not others?) > Verisign has created a business out of fooling software through > failure to return a 'no such domain' indication when there is no such > domain, in breach of their public trust. As much as Verisign was > obligated not to do this, others are obligated not to propogate the > breakage. ISPs operate DNS servers for their customers just as > Verisign operates the COM and NET domains for the public. the obligations you're speaking of are much less clear than you're saying.

6 6

FW: Sendmail 8.12.9 prescan bug (a new one) [CAN-2003-0694]
by Avery Buffington 17 Sep '03

17 Sep '03

-----Original Message----- From: Michal Zalewski [mailto:lcamtuf@dione.ids.pl] Sent: Wednesday, September 17, 2003 4:20 AM To: bugtraq(a)securityfocus.com; vulnwatch(a)securityfocus.com; full-disclosure(a)netsys.com Subject: Sendmail 8.12.9 prescan bug (a new one) [CAN-2003-0694] Hello lists, -------- Overview -------- There seems to be a remotely exploitable vulnerability in Sendmail up to and including the latest version, 8.12.9. The problem lies in prescan() function, but is not related to previous issues with this code. The primary attack vector is an indirect invocation via parseaddr(), although other routes are possible. Heap or stack structures, depending on the calling location, can be overwritten due to the ability to go past end of the input buffer in strtok()-alike routines. This is an early release, thanks to my sheer stupidity. -------------- Attack details -------------- Local exploitation on little endian Linux is confirmed to be trivial via recipient.c and sendtolist(), with a pointer overwrite leading to a neat case of free() on user-supplied data, i.e.: eip = 0x40178ae2 edx = 0x41414141 esi = 0x61616161 SEGV in chunk_free (ar_ptr=0x4022a160, p=0x81337e0) at malloc.c:3242 0x40178ae2 <chunk_free+486>: mov %esi,0xc(%edx) 0x40178ae5 <chunk_free+489>: mov %edx,0x8(%esi) Remote attack is believed to be possible. ---------------- Workaround / fix ---------------- Vendor was notified, and released an early patch attached below. There are no known workarounds. Index: parseaddr.c =================================================================== RCS file: /cvs/src/gnu/usr.sbin/sendmail/sendmail/parseaddr.c,v retrieving revision 1.16 diff -u -r1.16 parseaddr.c --- parseaddr.c 29 Mar 2003 19:44:01 -0000 1.16 +++ parseaddr.c 16 Sep 2003 17:37:26 -0000 @@ -700,7 +700,11 @@ addr[MAXNAME] = '\0'; returnnull: if (delimptr != NULL) + { + if (p > addr) + p--; *delimptr = p; + } CurEnv->e_to = saveto; return NULL; } -- ------------------------- bash$ :(){ :|:&};: -- Michal Zalewski * [http://lcamtuf.coredump.cx] Did you know that clones never use mirrors? --------------------------- 2003-09-16 21:18 --

1 0

ICANN - Formal Complaint re Verisign
by matthew-l＠itconsult.co.uk 17 Sep '03

17 Sep '03

Please find below a copy of a formal complaint I have made to ICANN today regarding Verisign's wildcard change of yesterday, which may be of interest to members of this list. The text is also available at:- http://www.itconsult.co.uk/misc/icann17sep2003.htm Best wishes, Matthew ==================== From: Matthew Richardson To: Tina Dam Subject: {18876} Formal Complaint - .com & .net wildcards cause Internet destabilisation Date: Wed, 17 Sep 2003 20:46:54 +0100 Organization: I. T. Consultancy Limited, Jersey -----BEGIN PGP SIGNED MESSAGE----- {ref: 18876} To: The Internet Corporation for Assigned Names and Numbers (ICANN) For the attention of: Tina Dam I refer to our telephone conversation of yesterday morning relating to the very recent addition of "wildcard" records to the .com & .net GTLDs by Verisign. My purpose in writing, as we discussed, is to make a formal complaint to ICANN regarding Verisign's actions, and furthermore to formally request ICANN to instruct Verisign to remove these wildcard records with immediate effect, subject only to their possible reinstatement following an appropriate period of consultation. This complaint is being made in the public interest. Specifically it is that the CHANGE in behaviour within two of the largest Internet TLDs is likely to cause serious difficulties in a number of areas. The inevitable consequence of these CHANGES is that many businesses and users involved with .com & .net domains (quite a sizeable proportion of the Internet) will be involved in varying degrees of unforeseen inconvenience, failure and expenditure. Such unexpected disruption and expense seems, at the very least, somewhat inequitable to those on the receiving end, all the more so in the absence of any notice from Verisign. This is clearly a destabilising effect on a very significant portion of the Internet as a whole, which seems to be at some variance with ICANN's ongoing responsibilities as described in your announcement of today http://www.icann.org/announcements/announcement-17sep03.htm, which states "The MoU highlights ICANN's responsibility to ensure the stability of the Internet". There may be many additional (and perhaps compelling) reasons why others might suggest that change is not good, predominantly from a privacy and data protection perspective. However this complaint deals solely with the issues of the failures caused by the unexpected change and the cost of correcting them. The change appears to have been announced by Verisign yesterday and I have seen references by them in public to the documents:- http://www.verisign.com/resources/gd/sitefinder/implementation.pdf http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf The former, dated 27 August 2003, describes their wildcard implementation, citing its conformance with their latter document, which is dated 09 September 2003. Whilst the lay reader might assume that this latter document represents some form of approved Internet standard, nothing could be further from the truth. The following are merely a few very examples of the sorts of issues which will cause failures and which will cost money to fix:- (a) Unsolicited commercial email (colloquially known as "spam"), is a serious (and increasingly serious) problem. Many email servers incorporate anti-spam protections. One commonly used method is to perform a DNS check on the sender domain prior to continuing to accept the message. If it does not exist, the email is not accepted being either delayed or permanently rejected. At a low level, this is done by issuing a DNS query for the sender domain and checking for the presence of MX or A records. Verisign's changes will cause this mechanism to fail for all non-existent .com or .net domains. (b) Verisign have installed software which answers on SMTP port 25 on the IP address returned as the A record. This software, which purports to be an email server, is not even remotely compliant with rfc2821, the current standard for SMTP email. It is clearly designed to receive email connections and reject the messages, although it remains unclear what difficulties its gross non-compliance will cause. As an aside, its ability to capture sender addresses (and should it wish in the future whole email messages) which is most likely to cause significant concern to those of a privacy protection persuasion. (c) There are likely to be many applications and services around the Internet, which utilise the results of DNS lookups to test the existence of domains under .com & .net, a method which has worked correctly since the creation of these TLDs long long ago. Many of these applications will belong to those involved in the domain registration business. The addition of wildcard records will cause all such applications to fail. This appears to be understood by clearly Verisign who state in the latter document referred to above "It is important to note that this response, though generated as the result of a wildcard, does not differ from a non-wildcard-related response. The recipient cannot determine the presence of a wildcard entry in a zone from a single response generated as a result of that wildcard". (d) Blacklists known generically as "DNSBL" have evolved from the original MAPS RBL as a means of specifying IP addresses from which email can be blocked. The addition of the wildcard record may make certain retired DNSBL spring back into life listing all addresses resulting in the incorrect rejection of incoming emails. In conclusion a change of this magnitude to the operation of two of the most major TLDs on the Internet should not have been undertaken without significant consultation and notice. I therefore urge ICANN to act promptly and decisively to remove these records in furtherance of its ongoing obligations to ensure stability of the Internet. Regards, Matthew Richardson I T Consultancy Limited Jersey Channel Islands -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAgUBP2i5aQKwLwcHEv69AQFytQQAsC/XgAdvbK/tBsIFyaiemYJneDTR9d/O FGNTvmMtUbht6RCPgpPYAv/M2I4eBIXRSVYFEQQGEok24McKjEl78n4mTi/N0pLp EUcO/UnLhwaa5Vt6SAokdqsFUFQvkl2jfDiHJ8C72JCYPaOG/KGvG9z/idotZKGh BXhaA1973gY= =JRfV -----END PGP SIGNATURE-----

1 0

Re: Change to .com/.net behavior
by Paul Vixie 17 Sep '03

17 Sep '03

> How about rewriting all DNS responses to your liking? :-) > > Like if you ask for www.register.com, you would get the A record for > www.verisign.com ? done. #fh:i386# ping -c 1 www.register.com PING www.register.com (216.21.229.101): 56 data bytes 64 bytes from 216.21.229.101: icmp_seq=0 ttl=234 time=79.703 ms --- www.register.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max/stddev = 79.703/79.703/79.703/0.000 ms #fh:i386# echo 65.205.249.60 www.register.com >>/etc/hosts #fh:i386# ping -c 1 www.register.com PING www.register.com (65.205.249.60): 56 data bytes ^C --- www.register.com ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss next? the point i'm illustrating is, as an end user, i'm in charge of my own name->address translations. > Responses for the highest bidder! that would be an interesting form of symbol democracy, if it scaled to all end users. instead we have a relatively nondemocratic namespace.

1 0

Re: Root Server Operators (Re: What *are* they smoking?)
by Paul Vixie 17 Sep '03

17 Sep '03

> So, Verisign just returns a NS pointer to another name server Verisign > controls which then answers the queries with Verisign's "helpful" web > site. > > Half-life of the patch: 1 day? i don't think so. verisign is on public record as saying that the reason they implemented the wildcard was to enhance the services offered to the internet's eyeball population, who has apparently been clamouring for this. in this story, for example... http://story.news.yahoo.com/news?tmpl=story&u=/ap/20030916/ap_on_hi_te/inte… ...it was thus spake: VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual service providers were free to configure their systems so customers would bypass Site Finder. But he questioned whether releasing a patch to do so would violate Internet standards. Vixie acknowledged that it could -- standards call for operators like VeriSign to have complete control over their directories -- but he said not releasing a patch would create greater chaos. therefore i believe that while they may have to change the A RR from time to time according to their transit contracts, verisign won't insert an NS RR into the sitefinder redirection. if they do, and if bind's user community still wants to avoid sitefinder, they can declare the second server "bogus", with no new code changes from isc. but that all seems terribly unlikely.

7 6

RE: Sabotage not backhoes: More cable cuts
by Justin Shore 17 Sep '03

17 Sep '03

Who Broadwing? Alan Ralsky maybe. I've had Broadwing's 3 /14s and some small misc netblocks in my Sendmail reject list for going on two years. I can't think of anything worthwhile I've missed. :) On Wed, 17 Sep 2003, Winslow, Michael wrote: > I'm sure they are important to someone > > -----Original Message----- > From: Justin Shore [mailto:listuser@numbnuts.net] > Sent: Wednesday, September 17, 2003 12:53 PM > To: Sean Donelan > Cc: nanog(a)merit.edu > Subject: Re: Sabotage not backhoes: More cable cuts > > > > On Sun, 14 Sep 2003, Sean Donelan wrote: > > > > > Someone climbed a 15-foot tower in Southern Arizona cutting a fiber optic > > cable used by Broadwing and Tucson Electric Power. This was within five > > feet of the 138,000-volt power line. The site was also guarded by barbed > > wire. > > At least it's just Broadwing. I mean it not like it's anybody important > anyways... > > Justin > >

1 0

Re: Where will Verisign stop?
by E.B. Dreger 17 Sep '03

17 Sep '03

http://www.internetnews.com/bus-news/article.php/3_85721 Deja vu. If I didn't know any better, I'd think that article were written in the past few days. What's going to happen in another 4.5 years? Shall we have a contest who can write the most accurate article before the next incident happens? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist(a)brics.com -or- alfra(a)intc.net -or- curbjmp(a)intc.net Sending mail to spambait addresses is a great way to get blocked.

1 0