Re: OSPF Vulnerability - Owning the Routing Table
On (2013-08-03 18:38 -0500), Jimmy Hess wrote: That's not news to me, but fully expected. Do the vendors /really/ have a code fix to what would seem to be an inherent problem; if you failed to properly secure your OSPF implementation (via MD5 authentication)? It is news to me. It's design flaw in the protocol itself which has gone unnoticed for two decades and I would have naively fully expected that this flaw does not exist in standard. As I've understood issue lies in the fact that 'link state id' and 'advertising router' should always be the same (so it's redundant information in the LSA, single field should suffice?). But standard does not enforce this at all. Victim will omit doing corrective reflood for received bogus LSA if 'advertising router' is something else than 'router-id', even while 'link state id' == 'router-id' I suppose vendors implement fix where either a) corrective reflood occur if 'link state id' == 'router-id' or b) LSA is rejected unless 'link state id' == 'advertising router' How serious or new this is, may be debatable, as only thing it seems remove, is the need for attacker to inject 0.2pps worth of packets which will suppress the corrective reflooding. -- ++ytti
Re: OSPF Vulnerability - Owning the Routing Table
On 8/4/13, Saku Ytti s...@ytti.fi wrote: On (2013-08-03 18:38 -0500), Jimmy Hess wrote: That's not news to me, but fully expected. Do the vendors /really/ have a code fix to what would seem to be an inherent problem; if you failed to properly secure your OSPF implementation (via MD5 authentication)? It is news to me. It's design flaw in the protocol itself which has gone unnoticed for two decades and I would have naively fully expected that this flaw does not exist in standard. I would say the risk score of the advisory is overstated. And if you think ospf is secure against LAN activity after any patch, that would be wishful thinking. Someone just rediscovered one of the countless innumerable holes in the back of the cardboard box and tried covering it with duck tape... What is the rationale for overlooking or ignoring the possibility that an attacker can introduce a device with /faithful/ correct implementation of the protocol with bad/malicious data intentionally advertised by the Rogue speaker ? This could be as simple as inserting a real router (which can be just a piece of software) on a broadcast LAN with a proper OSPF implementation but malicious configuration -- in that routes configured for advertisement are bogus ones, or a router ID is intentionally chosen to conflict with the router ID of another device. In addition, the rogue router, can be configured such that it forces an election and becomes the DR. Just a few examples -- -JH
Re: OSPF Vulnerability - Owning the Routing Table
On (2013-08-04 05:01 -0500), Jimmy Hess wrote: I would say the risk score of the advisory is overstated. And if you think ospf is secure against LAN activity after any patch, that would be wishful thinking. Someone just rediscovered one of the countless innumerable holes in the back of the cardboard box and tried covering it with duck tape... I tend to agree. OTOH I'm not 100% sure if it's unexploitable outside LAN via unicast OSPF packets. But like you say MD5 offers some level of protection. I wish there would be some KDF for IGP KARP so that each LSA would actually have unique not-to-be-repeated password, so even if someone gets copy of one LSA and calculates out the MD5 it won't be relevant anymore. L2 is very dangerous in any platform I've tried, access to L2 and you can usually DoS the neighbouring router, even when optimally configured CoPP/Lo0 filter. -- ++ytti
Re: IP allocations / bogon - ARIN Inconsistency
On 8/4/13 6:50 AM, Geoff Huston wrote: On 04/08/2013, at 2:06 PM, Rob Mosher rmos...@he.net wrote: Frank, HE uses the extended files for these stats since the standard ones will soon be deprecated. As Rene pointed out, the extended and standard delegation files from ARIN do not match for this prefix. I do not know why there is inconsistent data between the two, but this is something that ARIN should look into. I have been lead to understand that, for ARIN, the extended stats file reflects the registry state at a slightly different time (earlier by ~1 day) than the standard stats file. This is a likely explanation of the observed inconsistency. Geoff It looks like the update process for the extended stats got stuck. The files which have been published in recent days all are identical to the version of 2013-07-30, ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20130730 Thus allocations and changes made to the registry on 30 July or later are not accounted for in delegated-arin-extended-latest -- Rene
Re: OSPF Vulnerability - Owning the Routing Table
Agree, that't why using p2p has been mentioned as BCP in networking howto's for at least last 10 years. Regards, Jeff On Aug 4, 2013, at 3:14 AM, Saku Ytti s...@ytti.fi wrote: On (2013-08-04 05:01 -0500), Jimmy Hess wrote: I would say the risk score of the advisory is overstated. And if you think ospf is secure against LAN activity after any patch, that would be wishful thinking. Someone just rediscovered one of the countless innumerable holes in the back of the cardboard box and tried covering it with duck tape... I tend to agree. OTOH I'm not 100% sure if it's unexploitable outside LAN via unicast OSPF packets. But like you say MD5 offers some level of protection. I wish there would be some KDF for IGP KARP so that each LSA would actually have unique not-to-be-repeated password, so even if someone gets copy of one LSA and calculates out the MD5 it won't be relevant anymore. L2 is very dangerous in any platform I've tried, access to L2 and you can usually DoS the neighbouring router, even when optimally configured CoPP/Lo0 filter. -- ++ytti
Re: Returned mail: see transcript for details
This was just received a flood of bounces reporting delivery failuers on messages I sent to nanog@ a few days ago... Actually, I have just received a flood of about 15 messages just like this one around 9:00pm; from various nanog posts I had sent 2 to 5 days in the past.. Is that strange or what? I thought the mailing list software rewrote the return path to suppress bounces? On 8/4/13, mailer-dae...@mx1.kdc.fujixerox.co.jp mailer-dae...@mx1.kdc.fujixerox.co.jp wrote: The original message was received at Mon, 5 Aug 2013 10:37:12 +0900 (JST) from ms2.dc.fxis.co.jp [143.94.15.17] - The following addresses had permanent fatal errors - tosh...@de-anza.rdh.fujixerox.co.jp (reason: 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp: Recipient address rejected: User unknown in local recipient table) - Transcript of session follows - ... while talking to de-anza.rdh.fujixerox.co.jp.: DATA 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp: Recipient address rejected: User unknown in local recipient table 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp... User unknown 554 5.5.1 Error: no valid recipients -- -JH
Re: Returned mail: see transcript for details
I got hit the same. Sent from my Mobile Device. Original message From: Jimmy Hess mysi...@gmail.com Date: 08/04/2013 9:09 PM (GMT-08:00) To: nanog@nanog.org Subject: Re: Returned mail: see transcript for details This was just received a flood of bounces reporting delivery failuers on messages I sent to nanog@ a few days ago... Actually, I have just received a flood of about 15 messages just like this one around 9:00pm; from various nanog posts I had sent 2 to 5 days in the past.. Is that strange or what? I thought the mailing list software rewrote the return path to suppress bounces? On 8/4/13, mailer-dae...@mx1.kdc.fujixerox.co.jp mailer-dae...@mx1.kdc.fujixerox.co.jp wrote: The original message was received at Mon, 5 Aug 2013 10:37:12 +0900 (JST) from ms2.dc.fxis.co.jp [143.94.15.17] - The following addresses had permanent fatal errors - tosh...@de-anza.rdh.fujixerox.co.jp (reason: 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp: Recipient address rejected: User unknown in local recipient table) - Transcript of session follows - ... while talking to de-anza.rdh.fujixerox.co.jp.: DATA 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp: Recipient address rejected: User unknown in local recipient table 550 5.1.1 tosh...@de-anza.rdh.fujixerox.co.jp... User unknown 554 5.5.1 Error: no valid recipients -- -JH
Re: Returned mail: see transcript for details
On 8/4/2013 11:13 PM, Warren Bailey wrote: I got hit the same. me too. e, me two. No clues as to what the messages were that I could see. -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)
Re: Returned mail: see transcript for details
On Sun, 04 Aug 2013 23:07:59 -0500, Jimmy Hess said: I thought the mailing list software rewrote the return path to suppress bounces? Yeah, but every once in a while you'll come across a mail server hosted at Billy Bob's Bait, Tackle, and E-mail, or Klooful Joe's Bargain Hosting, that doesn't understand that bounces go to the RFC821 MAIL FROM and instead insist on sending to the RFC822 From:. In this case, it appears to be an end user with a badly misconfigured Fetchmail 6.3.21 that isn't handling bounces sanely. pgpA0gKDnRwmH.pgp Description: PGP signature
