Hi,
Does anybody have details on what this vulnerability is?
https://www.blackhat.com/us-13/briefings.html#Nakibly
Glen
Glen Kent wrote:
Hi,
Does anybody have details on what this vulnerability is?
Black Hat USA 2013 | Briefings
Glen
Could it be related to:
announced very recently?
There is a little more information here than in your link, but not enough to go out and reproduce the problem.
Cisco published an advisory on OSPF vulnerability yesterday I think. I
assume it's related.
OSPFv3 is not vulnerable, and connections protected by MD5 are safe too,
apparently.
Aled
These were published recently:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130801-lsaospf
http://www.juniper.net/alerts/viewalert.jsp?txtAlertNumber=PSN-2013-08-987&actionBtn=Search
Yes, these advisories (from both Cisco and Juniper), covering CVE-2013-0149, are both related to the announcement yesterday (1-Aug) at BlackHat regarding the OSPF LSA Manipulation vulnerability.
Thanks,
John
“Optimism is the faith that leads to achievement. Nothing can be done without hope and confidence”.
John Stuppi, CISSP
Technical Leader
Strategic Security Research
jstuppi@cisco.com
Phone: +1 732 516 5994
Mobile: 732 319 3886
CCIE, Security - 11154
Cisco Systems
Mail Stop INJ01/2/
111 Wood Avenue South
Iselin, New Jersey 08830
United States
Cisco.com
Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
So, only Cisco and Juniper are hit by this one? What about "the rest"?
Michael
Hi,
As for Ericsson (Redback) products.
We found the issue quite some time ago and fixed it immediately.
Smart Edge code base (SEOS) has been fixed back to the release 6.3
SSR code base (IPOS) - not affected.
Please let me know if you have got any questions.
Regards,
Jeff
Cisco published an advisory on OSPF vulnerability yesterday I think. I
assume it's related.
OSPF is a dynamic routing protocol. It automatically discovers
neighbors on a multi-access segment claiming to be routers.
In what way could it possibly be unexpected that an attacker can pose
as a router and inject false routes; if an attacker able to emit
multicast to OSPF multicast address onto a LAN speaking OSPF?
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.
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
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.
Agree, that't why using p2p has been mentioned as BCP in networking "howto's" for at least last 10 years.
Regards,
Jeff
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?
I got hit the same.
me too. errrr, me two.
No clues as to what the messages were that I could see.
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.
The mailing list does try to receive and process bounce messages.
I cannot find this address in the NANOG mailing list as a subscriber. It appears that a subscriber is forwarding messages to this mailbox.
Best Regards,
Andrew Koch
on behalf of the NANOG Communications Committee
The mailing list does try to receive and process bounce messages.
If it had caught these, I'd have been amazed - the offending site sent the
bounces directly to the address in the From: so the NANOG mail server never
saw the bounce.
I cannot find this address in the NANOG mailing list as a subscriber. It appears that a subscriber is forwarding messages to this mailbox.
The bounces that you didn't see contained a Received: header that ID'ed
the subscriber. I've sent you an off-list note..
The problem with that theory, Valdis, is that *I* saw half a dozen or so
of them as well. So I'm guessing the list server did see at least some of
them.
Cheers,
-- jra
as it so happens, i could still use a decent contact over at AS3209. noc
channels are unresponsive. even tried this one listed in radb:
noc@adm.arcor.net.
they are doing something really funky with their cg-nat setup for mobile
subs. like, frag mapping gone wrong, therefore crazy retries or acks never
received, etc. for us, it is breaking SSL.