- Test - lists.nanog.org

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

new openssh issue
by Len Rose 17 Sep '03

17 Sep '03

Just in case no one has seen this: http://slashdot.org/articles/03/09/16/1327248.shtml?tid=126&tid=172

7 6

anyone from telia online
by Peter Galbavy 17 Sep '03

17 Sep '03

I need a little help with (what appears to be) an IGP issue withing Telia's UK network. I am stuck in a twisty maze of little resellers. Any response would be appreciated. Peter

1 0

Change to .com/.net behavior
by Matt Larson 17 Sep '03

17 Sep '03

Today VeriSign is adding a wildcard A record to the .com and .net zones. The wildcard record in the .net zone was activated from 10:45AM EDT to 13:30PM EDT. The wildcard record in the .com zone is being added now. We have prepared a white paper describing VeriSign's wildcard implementation, which is available here: http://www.verisign.com/resources/gd/sitefinder/implementation.pdf By way of background, over the course of last year, VeriSign has been engaged in various aspects of web navigation work and study. These activities were prompted by analysis of the IAB's recommendations regarding IDN navigation and discussions within the Council of European National Top-Level Domain Registries (CENTR) prompted by DNS wildcard testing in the .biz and .us top-level domains. Understanding that some registries have already implemented wildcards and that others may in the future, we believe that it would be helpful to have a set of guidelines for registries and would like to make them publicly available for that purpose. Accordingly, we drafted a white paper describing guidelines for the use of DNS wildcards in top-level domain zones. This document, which may be of interest to the NANOG community, is available here: http://www.verisign.com/resources/gd/sitefinder/bestpractices.pdf Matt -- Matt Larson <mlarson(a)verisign.com> VeriSign Naming and Directory Services

29 34

Re: Change to .com/.net behavior
by sthaug＠nethelp.no 17 Sep '03

17 Sep '03

> While I too am outraged by the actions of Verisign, I've decided to NOT > modify my servers in any way. > I might decide to block the sitefinder IP, but I will not change my > nameservers into modifying DNS responses. Doing so would be to break things, *You* cannot modify DNS responses, but it's okay for Verisign to do so? Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

3 2