Disclaimer, I do not work for any vendor right now, and I don't sell any product that might benefit from scaring anyone, so this is just some whining for a real issue that someone needs to do something about.

I've worked for the CDP vendor for a long time, and I do concur to what Saku is saying...the L3 packet of death [threat] is very real, and I'd like to take this opportunity (the buzz around CDPwn) to say a thing or two about these 'soft, mushy and vulnerable' code stacks we have running all over the world, under our feet, waiting for someone with the right incentive to take advantage of. 

IMHO, "Skilled" software developers, and in parallel...'software exploiters/reverse engineers' haven't been paying attention to these 'infrastructure' boxes (for now), maybe it is because they always had other pieces of the technology stack to work with, and these other tech. stacks were much more rewarding to spend time on (I'm quite sure Node.js / Kubernetes for example...will have a lot more vulnerability researchers looking at them than CDP/LLDP/SNMP....etc code). < and That is a serious sustainability issue on our hands, the risk here is very high; when it comes to infrastructure security of nations, especially in a world where miscreants are no longer script kiddies but actual nation sponsored soldiers...Even MBS is doing it in person.

Because the moment some miscreants from some oppressive regime decides to do damage, and not necessarily remote code execution as many might think, but more on the 'L3 packet of death' kind of situation that Saku mentioned earlier, these miscreants have a lot to play with, and the attacks vector is huge, it is green and it is ready for the ripe. 

In my life time, I've looked at so many 'DDTS' descriptions, and I saw nothing but an unwritten disclaimer of : 'I can be easily used for DDoS'...and that is the case even if *SIRT did their brief analysis of these bugs, so again, if some miscreants found it in themselves to look at bugs with the right 'optics', we are going to be in an interesting situation.

Luckily, we haven't seen a CDPwn/STPwn/BGPwn/NTPwn/*.*Pwn...etc worm/ransomware yet, but we also don't have reason to think its not possible, and to make matters worse, the code these babies are running is ancient (in every possible way), many of the libraries used to develop that code is glibc_ishy like in nature, and to make matters a bit more interesting, patching those babies is not easy, and the nature of their software architecture makes them even much more fragile than any piece of cheap IP camera out there on the internet or on enterprise networks.

So yeah iACLs, CoPP and all sorts of basic precautions are needed, but I'm thinking something more needs to be done, specially if these ancient code stacks are being imported into new age 'IoT' devices, multiplying the attack vector by a factor of too many.

~A

On Mon, Feb 10, 2020 at 5:42 AM Saku Ytti <saku@ytti.fi> wrote:
On Mon, 10 Feb 2020 at 13:52, Jean | ddostest.me via NANOG
<nanog@nanog.org> wrote:

> I really thought that more Cisco devices were deployed among NANOG.
>
> I guess that these devices are not used anymore or maybe that I
> understood wrong the severity of this CVE.

Network devices are incredibly fragile and mostly work because no one
is motivated to bring the infrastructure down. Getting any arbitrary
vendor down if you have access to it on L2 is usually so easy you
accidentally find ways to do it.
There are various L3 packet of deaths where existing infra can be
crashed with single packet, almost everyone has no or ridiculously
broken iACL and control-plane protection, yet business does not seem
to suffer from it.

Probably lower availability if you do upgrade your devices just
because there is a known issue, due to new production affecting
issues.

--
  ++ytti