- Test - lists.nanog.org

RE: new openssh issue
by Ingevaldson, Dan (ISS Atlanta) 16 Sep '03

16 Sep '03

ISS X-Force discovered this vulnerability and our advisory will be released shortly. We were working to determine the full scope of the vulnerability before we notified the vendor. Unfortunately, someone else found the flaw and began to cause discuss it using specifics. That caused us to push forward our disclosure. Typically, when we do X-Force Advisories, we have developed an in-house, functional exploit (not proof of concept) in order to verify the exact nature and scope of the issue. We have not done so in this case. Right now it is undetermined if the issue is exploitable on *any* platform. It may turn out that it may be exploitable on every platform. This issue is serious enough that it should be addressed on all platforms as quickly as possible. I'll forward our Advisory to the list when it is public. Regards, =============================== Daniel Ingevaldson Engineering Manager, X-Force R&D dsi(a)iss.net 404-236-3160 Internet Security Systems, Inc. The Power to Protect http://www.iss.net =============================== -----Original Message----- From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Tuesday, September 16, 2003 3:50 PM To: Richard A Steenbergen Cc: William Allen Simpson; nanog(a)nanog.org Subject: Re: new openssh issue On Tue, 16 Sep 2003 15:33:03 EDT, Richard A Steenbergen said: > > patched, but does anybody know whether there's a problem with the > > criscos? (as in "how do I configure my router for that?" ;-) > > Or better yet, the OpenSSH running on Junipers? Nothing on Juniper's > site > about a vulnerability so far. A posting to full-disclosure quotes Theo as saying HP and Cisco are affected, and I don't see any reason that Juniper would *NOT* be, given the common code base of the OpenSSH implementations. I'm not going to say the routers are vulnerable, but I *would* say that ACLs blocking port 22 to the router might be a good idea.....

1 0

Re: Verisign insanity - Distributed non-attack
by Stephen J. Wilcox 16 Sep '03

16 Sep '03

Alternatively: Improve your hits - Point the IP to your company webserver or add an A record to your local DNS servers to resolve to your site If you want to help your peers to rid their networks of verisign, why not announce the IP via BGP anycast ;p I do like the idea of inundating their systems, my only gripe is that I see their server on my transits, which even if I leave things as is I assume verisign wont be paying for the extra bandwidth that they now cause ISPs across the world to use... Steve On Tue, 16 Sep 2003, RoDent wrote: > > After reading the posts on this list about Verisign's insane behaviour > regarding the .com and .net TLD wildcards, I'd like to make a suggestion: > > Anyone remember the old RC5, distributed.net or Seti@Home projects? > > If Verisign continues with this irrational behaviour I propose developing > a distributed client that will inundate their wildcard hosts with invalid > requests, thus making harvesting useful information from any HTTP, or > SMTP traffic that they hijack nigh impossible. > > I nice distributed effort, a simple win32, and Unix client, and a stats > based reporting system will make this a project where everyone can vote > with their IP address. > > I've also taken a look at the BIND code myself, to see how to rid myself > of these falsely reported A records, but the fact is that unless EVERYONE > joins in on running such a version of bind, Verisign will still get away > with it. > It's ridiculous that I as an administrator have to take steps to correct > the greedy self-righteousness that is the halmark of their "experiment" in > an > effort to get some of the FUNDAMENTALS of DNS behaviour to operate > as expected. > > Inundating them with requests (such as the small Lynx shell script posted > earlier), will force bigger ISP's to take a stance against this behaviour as > well, > since they'll be the ones footing the bill in terms of transparent cache > servers > being filled with invalid requests, sitting on expensive disc, and expiring > other > more cache-worthy documents, and filling up processing queues. > > Effectively this would amount to "denial of service" attack, but since > there is > nothing illegal about making an http request to an invalid hostname, > Verisign > will be bringing the denial of service attack upon themselves, and > unfortunately > dragging ISP's with them. Why ISP's haven't publically taken a stance > against > this yet is fascinating. > > I'm a mild mannered programmer/administrator by day, but blatantly > monopolistic practices such as this requires decisive mass action, and makes > my blood boil. There are enough issues to deal with on a day to day basis > just to combat the loopholes there currently are for spammers. > > Having Verisign give spammers free FROM: domains to spam from has just > made the task all the more unpleasant... > > If Verisign doesn't retract their mal-implemented "White Paper" and it's > insiduous > behaviour from the internet within the next week, I WILL start developing a > client > that allows netizens to vote with their IP's and HTTP, or SMTP traffic. > > I will personally put up a 100$ prize for the client that according to > statistics have > made the most requests to invalid .com/.net domains within the period > required > to get them to stop. > > Cheers, > Roelf Diedericks > Systems Programmer > > "I might be on the other end of a 56k modem, but I have a lot of friends > with > 56k modems..." > >

2 1

simple way to fix Verisign DNS issues
by John Brown 16 Sep '03

16 Sep '03

Ok, so the Verisign issue seems to impact a number of various things. 1. RBL's 2. Testing scripts 3. MX and mail handling 4. Taking eyeballs and possible revenue away from others I think the solution is quite simple. Each provider that is unhappy with this should stand up a ANYCAST server that answers on this IP. Use Zebra to inject AS 30060 into your network and have it goto a machine that simply answer NXDOMAIN. Have that DNS server(s) answer the same way "it should" or "the way you want" Make sure you tag the route with NO-EXPORT :) If you are a hosting company, you could redirect them to your "Buy Domains Now" page. Verisign is HELPING YOU get more customers. All you need is a few stewpid router tricks and poof you are set. I've stood up two anycast servers today and its working nicely. The DNS server just answers like it should. Heck you could have this server also become a AS112 box for your network as well. Kill two birds with one ,er two zebras Cheers

2 1

Fwd: Re: Patching BIND (Re: What *are* they smoking?)
by Mark Vevers 16 Sep '03

16 Sep '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 16 Sep 2003 6:41 am, John Brown wrote: > we've burned a AS for this, ICK Yup - and 2 /24's .... #show ip bgp regexp _30060$ Network Next Hop Metric LocPrf Weight Path *>i12.158.80.0/24 xxx.xxx.xxx.xxx 305 100 0 1239 7018 26134 30060 ? *>i64.94.110.0/24 xxx.xxx.xxx.xxx 305 100 0 1239 7018 26134 30060 ? > based on the ASNAME, its seems a nice little route-map > /dev/null will be real easy. As long as they keep prefixs > used in this really dumb idea for this idea. If you have a full table (i.e. no default) just drop inbound routes with a AS path _30060$ Also .... <user>@dns0:/var/named/verisignwildcard#host 64.94.110.11 Host 11.110.94.64.in-addr.arpa not found: 3(NXDOMAIN) Oh dear, I wonder what happened to the reverse ..... looks like that doesn't resolve any more from here ;-) ... so we can still do reverse DNS checks.... Mark - -- Mark Vevers. mark(a)ifl.net / mark(a)vevers.net Principal Internet Engineer, Internet for Learning, Research Machines Plc. (AS5503) - -- GPG Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB08F3CA3 Fingerprint: 85BA 30C4 9EC8 1792 4C8C C31E 58B5 3D1C B08F 3CA3 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/ZtFGWLU9HLCPPKMRApqHAJwJAxEbkUmKfUsuK4lOrrs5izPaRgCfePsT b0klVYOObpWZqQZIUd3TrJk= =gb31 -----END PGP SIGNATURE-----

6 5

Re: Verisign insanity - Distributed non-attack
by Stephen J. Wilcox 16 Sep '03

16 Sep '03

On Tue, 16 Sep 2003, John Palmer wrote: > Sorry to sound like a broken record, but we in the Inclusive Namespace > have been saying this all along. Yeah, cmon step down from your soapbox.. > How about a world with 1000's of TLDs all operated by different people > with NO restrictions imposed by a monopoly-supporting politburo (ICANN). No, you miss the point. There are 100s of TLDs already, the point here is that this is .com and .net, I dont care about .blah! Steve > > How about a root network operated under rules designed ONLY to > support the technical stability of the network and not under rules that > masquerade as such but are really designed to prop up a monopoly of > four organizations so that they can corner the market and shut out > all others. > > Imagine such a world. Some people are doing just that. Some people > with a LOT of money to spend on such a project. Stay tuned. > > In a free market namespace (which the ICANN/USG IS *NOT*), > with no un-neccessary barriers to entry, competition would weed > out the players that did anti-social, predatory things like VRSGN > is doing. > > Either a business changes its practices to be in tune with its customer > base or it vanishes. > > FYI: ADNS had wildcard records in the DNS for the .USA, .EARTH, .Z, > .LION and .AMERICA TLDs. They simply pointed to a page that said "This > domain has not been registered yet". Those records were removed > today because of the controversy surrounding wildcard records at the > TLD level. I see a valid use for such records but there is also potential > for abuse and perception is sometimes as important as reality. In the > Inclusive Namespace, competition is a reality because there are no > artificial barriers to entry in the marketplace and players had better listen > to the consumer's opinions or else they will not survive. Thats as it should > be. So, why isn't the #1 (in terms of traffic) root server network operated > that way? > > ----- Original Message ----- > From: "Richard Cox" <Richard(a)mandarin.com> > To: <nanog(a)merit.edu> > Sent: Tuesday, September 16, 2003 10:18 > Subject: Re: Verisign insanity - Distributed non-attack > > > > > > On Tue, 16 Sep 2003 17:02:59 +0200 "RoDent" <rodent(a)mighty.co.za> wrote: > > > > | Effectively this would amount to "denial of service" attack, but since > > | there is nothing illegal about making an http request to an invalid > > | hostname, Verisign will be bringing the denial of service attack upon > > | themselves, and unfortunately dragging ISP's with them. Why ISP's > > | haven't publically taken a stance against this yet is fascinating. > > > > While I completely share your concern about Verisign's behaviour, I have > > a higher level concern about anything seeking to disrupt services on the > > 'net. For some weeks now, several of the abuse-prevention organisations > > have been subjected to Distributed Denial-of-Service attacks; the attack > > on SORBS is still continuing, and very few of the networks carrying this > > DDoS traffic have lifted a finger to either limit or trace the attacking > > traffic. Which, I have to say, is *most* disappointing. > > > > -- > > Richard Cox > > > > > > >

1 0

Detroit Area
by frank＠try-us.de 16 Sep '03

16 Sep '03

Hello nanogers, thank you all for your fast and uncomplicated help. I'm overwhelmed about the respond. Thanks a lot -- Best regards, Frank Kuempel mailto:frank@try-us.de If it's there and you can see it - it's REAL If it's there and you can't see it - it's TRANSPARENT If it's not there and you can see it - it's VIRTUAL If it's not there and you can't see it - it's GONE

1 0

Verisign Countermeasures - BIND and djbdns patches
by Adam Langley 16 Sep '03

16 Sep '03

On Tue, Sep 16, 2003 at 04:03:08PM +0100, Adam Langley wrote: I'm collecting countermeasures to the verisign wildcard DNS records at http://www.imperialviolet.org/dnsfix.html. Currently there are patches for BIND 9.2.2 and djbdns (not authored by myself) and a Linux userland/netfilter program that rewrites DNS packets (which is). If anyone has other patches/countermeasures I'm happy to maintain a list of links at the above URL. -- Adam Langley agl(a)imperialviolet.org http://www.imperialviolet.org (+44) (0)7906 332512 PGP: 9113 256A CC0F 71A6 4C84 5087 CDA5 52DF 2CB6 3D60

3 2

Verisign's legal woes???
by Roy 16 Sep '03

16 Sep '03

I am just wondering how long until some sharp lawyer sues the heck out of Verisign. While one could argue about who owns unregistered names, there is little or no question about who owns registered names. Verisign's current implementation breaks down for registered names that are not in the zone for some reason. The legal problems 1. This could be considered hijacking of the domain name 2. If the domain name is trademarked, it could be a trademark violation 3. If a registered name goes on HOLD for a day, mail service is suspended (most MTAs keep retrying when the name doesn't resolve). Under the new scheme it all bounces 4. By bouncing mail using the name, it could be the unauthorized use of a domain (that's a crime in California) If one wants to experiment, use dorkslayers.com as your test case. Its a valid paid-for active domain name with no nameservers. Might make a nice class action suit on behalf of all the owners of domain names that aren't in the zone. Could be worth a lot of legal fees.

3 2

Verisign's New Change and Outdate RBL's
by Patrick Muldoon 16 Sep '03

16 Sep '03

Was playing with a test box here at home. Installed SpamAssassian from a newely cvsup'd ports tree on a FreeBSD box, and was surprised to see messages getting marked as received in blacklists that no longer exist. Most noteably ORBS. Since this was a fresh Install I hadn't gone through and removed the dead RBL's from 20_head_tests.cf yet. Since dorkslayers doesn't exist. any queries for it are returning that infamous sitefinder address. [doon@fawkes doon]$ host 34.131.246.64.orbs.dorkslayers.com 34.131.246.64.orbs.dorkslayers.com has address 64.94.110.11 So anybody that hasn't update their SpamAssassian config, now has the added benefit of all ip's being tagged as an open relay. Just an FYI -Patrick

2 1

Verisign changes violates RFC2821
by Avleen Vig 16 Sep '03

16 Sep '03

Just to make it clear, RFC2821 is likely being violated: - The reserved mailbox name "postmaster" may be used in a RCPT command without domain qualification (see section 4.1.1.3) and MUST be accepted if so used. This is *probably* being violated, but I'm not sure as it gets ambiguous later. However, returning a 550 is very wrong. The correct reply should be either: 554 Transaction failed (Or, in the case of a connection-opening response, "No SMTP service here") or: 502 Command not implemented

1 0