January 2009 - Test - lists.nanog.org

Re: Leap second tonight
by Peter Lothberg 04 Jan '09

04 Jan '09

bash-2.05b# date Thu Jan 1 00:59:58 CET 2009 bash-2.05b# date Thu Jan 1 00:59:59 CET 2009 bash-2.05b# date Thu Jan 1 00:59:60 CET 2009 bash-2.05b# date Thu Jan 1 01:00:00 CET 2009 bash-2.05b# date Thu Jan 1 01:00:01 CET 2009 bash-2.05b# -P

12 14

RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
by Skywing 04 Jan '09

04 Jan '09

That md5 has now been deprecated for awhile is certainly also true; and people should have definitely moved on by now. Then again, I just got yet another Debian DSA mail which has plaintext download links for new binaries. The integrity verification mechanism for said binaries is, you guessed it: PGP-signed md5sums. We still have a long way to go. :) – S -----Original Message----- From: Steven M. Bellovin <smb(a)cs.columbia.edu> Sent: Friday, January 02, 2009 15:07 To: Skywing <Skywing(a)valhallalegends.com> Cc: Deepak Jain <deepak(a)ai.net>; NANOG <nanog(a)nanog.org> Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. On Fri, 2 Jan 2009 16:51:53 -0600 Skywing <Skywing(a)valhallalegends.com> wrote: > Of course, md5 *used* to be good crypto. > See http://www.cs.columbia.edu/~smb/blog/2008-12/2008-12-30.html for the links, but MD5 has been suspect for a very long time. Dobbertin found problems with it in 1996. The need for caution with it was not just knowable but known, and stated publicly. I'm sure others did so as well; I can only easily quote my own works. From the second edition of my Firewalls book, in 2003: Additionally, \i{SHA} has replaced \i{MD5}, as the latter appears to be weaker than previously believed. and Hints of weakness have shown up in MD5 and RIPEMD-160; cautious people will eschew them, though none of the attacks are of use against either function when used with HMAC\@. As of this writing, the \i{NIST} algorithm appears to be the best choice. For many purposes, the newer versions of SHA are better; these have block sizes ranging from 256 to 512 bits. Even if that were not enough, Wang et al presented the actual collisions in 2004. There have been many updates and patches to more or less everything since then... Yes -- if you pick something that's very weak, you can get caught by surprise. But modern algorithms don't fall all at once. I should add, of course, that if you use bad algorithms or bad protocols, it doesn't matter where you store the public key. When I said that the update problem was easier, what I was saying is that you're not relying on outside parties for verification of identity, etc., it's all your own data. --Steve Bellovin, http://www.cs.columbia.edu/~smb

5 5

RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
by Skywing 03 Jan '09

03 Jan '09

What's the cost to switching to something other than MD5 here, though? I agree that users not checking download links is likely more probablistic. But as checking the sums is already entirely a manual process, what's the trouble with switching to sha256 now abd stating this in the DSA mails? No, there probably won't be another major md5 break in six months. Or maybe a year, or two, or... However, the both of us well know that the attacks here won't do anything but get better. Even if it's not a thing to sound a fire drill about, I have to admit that hearing that Debian's going to continue moving forward with md5 until an unspecified somewhen date in the future is a bit disappointing. Not (yet) the end of the world, but I would like to understand the reason (cost) for the pushback here. – S -----Original Message----- From: Florian Weimer <fw(a)deneb.enyo.de> Sent: Saturday, January 03, 2009 08:23 To: Skywing <Skywing(a)valhallalegends.com> Cc: Steven M. Bellovin <smb(a)cs.columbia.edu>; NANOG <nanog(a)nanog.org> Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. > Then again, I just got yet another Debian DSA mail which has > plaintext download links for new binaries. The integrity > verification mechanism for said binaries is, you guessed it: > PGP-signed md5sums. I can assure you that you will continue to receive these messages for a while (unless you unsubscribe from the relevant mailing lists). Our rationale is that in order to carry out currently known attacks on MD5, you need to create a twin of documents, one evil and one harmless. In Debian's case, we prepare the data we sign on our trusted infrastructure. If someone can sneak in an evil twin due to a breach, more direct means of attack are available. In practice, the download links themselves are the larger problem because users might use them without checking anything. Eventually, they will go away, together with the MD5 hashes. Newer versions of APT also use the SHA-256 checksums embedded in the Release and Packages files.

2 1

NANOG 45: ISP Security BOF - Call for participants
by Warren Kumari 03 Jan '09

03 Jan '09

Hello and Happy New Years all, NANOG 45 is fast approaching and so here is the call for participants for the ISP Security BOF. This is *your* chance to talk about interesting security related topics and provide some feedback on what you would (and would not) like to hear about... Some security thing been buggin' you all year? Some topic that you feel strongly about and would like a change to inform others about? Step right up and give a talk... Slides are welcome, but not required... W

1 0

RR Routing Loop?
by Neil 02 Jan '09

02 Jan '09

So my night was fun: I was in the middle of configuring a mail server over SSH when suddenly it goes unresponsive... It seems (to me, but I'm by no means an expert) to be a routing loop. This is off a residential line in Southern California, between about 2-4:30am PST. Does anyone know what was going on there? 1 cpe-75-82-48-1.socal.res.rr.com (75.82.48.1) 23.890 ms 11.594 ms 10.598 ms 2 gig11-35.vnnyca2-rtr2.socal.rr.com (76.167.5.141) 12.732 ms 11.605 ms 10.378 ms 3 * * * 4 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 28.318 ms 30.164 ms 25.177 ms 5 * * * 6 * * * 7 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 43.524 ms 43.117 ms 42.888 ms 8 * * * 9 * * * 10 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 60.265 ms 59.196 ms 59.076 ms 11 * * * 12 * * * [snip] 28 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 150.724 ms 154.224 ms * 29 prt23.vnnyca2-rtr1.socal.rr.com (76.167.2.11) 154.232 ms * * [snip] 56 * * * 57 * * * 58 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 173.394 ms 173.101 ms 168.737 ms 59 * * * 60 * * * 61 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 178.986 ms 178.072 ms * 62 * * * 63 * * * 64 prt24.lsanca3-rtr2.socal.rr.com (76.167.2.14) 189.424 ms 188.331 ms 196.333 ms

1 0

London Demon Internet NOC/ENG contact?
by Mike Lyon 02 Jan '09

02 Jan '09

Could you please hit me up off list? E-mails to your helpdesk and NOC have gone unanswered. It's in regards to a routing loop: 16 227 ms 204 ms 204 ms park-ll-1-7200.access.demon.net[194.159.245.133] 17 225 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 18 175 ms 204 ms 204 ms 194.159.245.129 19 175 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 20 227 ms 204 ms 204 ms 194.159.245.129 21 227 ms 204 ms 204 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] 22 227 ms 204 ms 204 ms 194.159.245.129 23 227 ms 205 ms 203 ms lon1-service-1e2-xxx.router.demon.net[194.159.245.130] Thanks in advance. Cheers, Mike

1 0

RE: Security team successfully cracks SSL using 200 PS3's and MD5 flaw.
by Skywing 02 Jan '09

02 Jan '09

Of course, md5 *used* to be good crypto. – S -----Original Message----- From: Steven M. Bellovin <smb(a)cs.columbia.edu> Sent: Friday, January 02, 2009 14:46 To: Deepak Jain <deepak(a)ai.net> Cc: NANOG <nanog(a)nanog.org> Subject: Re: Security team successfully cracks SSL using 200 PS3's and MD5 flaw. On Fri, 2 Jan 2009 16:13:45 -0500 Deepak Jain <deepak(a)ai.net> wrote: > > If done properly, that's actually an easier task: you build the > > update key into the browser. When it pulls in an update, it > > verifies that it was signed with the proper key. > > > > If you build it into the browser, how do you revoke it when someone > throws 2000 PS3s to crack it, or your hash, or your [pick algorithmic > mistake here]. > If you use bad crypto, you lose no matter what. If you use good crypto, 2,000,000,000 PS3s won't do the job. --Steve Bellovin, http://www.cs.columbia.edu/~smb

2 1

Re: Anyone else seeing loss in SAVVIS?
by Henry Linneweh 02 Jan '09

02 Jan '09

Target Name: N/A IP: 204.70.95.25 Date/Time: 1/2/2009 1:59:37 PM 1 1 ms 0 ms home [192.168.1.254] 2 11 ms 11 ms adsl-75-18-183-254.dsl.pltn13.sbcglobal.net [75.18.183.254] 3 10 ms 10 ms [64.164.107.130] 4 11 ms 9 ms bb1-g3-0.pltnca.sbcglobal.net [151.164.43.54] 5 12 ms 12 ms ex1-p10-0.eqsjca.sbcglobal.net [151.164.191.66] 6 11 ms 12 ms [151.164.251.146] 7 11 ms 12 ms pr2-ge-2-0-0.SanJoseEquinix.savvis.net [204.70.200.130] 8 * * [-] destination address unreachable ________________________________ From: Tomas L. Byrnes <tomb(a)byrneit.net> To: nanog(a)merit.edu Sent: Friday, January 2, 2009 1:53:19 PM Subject: Anyone else seeing loss in SAVVIS? 7 170 ms 163 ms 167 ms cr2-pos-0-3-0-2.sanfrancisco.savvis.net [204.70. 95.25] 8 * 208 ms * cr1-tengig-0-15-0-0.NewYork.savvis.net [204.70.1 6.117] 9 170 ms * * kar1-ge-0-0-0.newyork.savvis.net [204.70.193.1] 10 * * * Request timed out.

1 0

Anyone else seeing loss in SAVVIS?
by Tomas L. Byrnes 02 Jan '09

02 Jan '09

7 170 ms 163 ms 167 ms cr2-pos-0-3-0-2.sanfrancisco.savvis.net [204.70. 95.25] 8 * 208 ms * cr1-tengig-0-15-0-0.NewYork.savvis.net [204.70.1 6.117] 9 170 ms * * kar1-ge-0-0-0.newyork.savvis.net [204.70.193.1] 10 * * * Request timed out.

2 1

Happy New Year! Let the botnets loose!
by Jack Bates 02 Jan '09

02 Jan '09

From reports in the CBL database, it appears they have enjoyed some DOS traffic yesterday, and I'm currently enjoying a little 40k+ botnet attack (small botnet beats large one when you host the victim IP). Anyone have any good resources on the breakdowns of the current known botnets and their traffic patterns? This one appears to use random IP protocol numbers, and extremely small packets. IP 255 and ICMP type 70 seem popular on this one, but I see a lot of randomness. Feel free to reply offlist if you have some good resources. Jack Bates

1 0