CISCO 0-day exploits

Tue Feb 11 10:04:49 UTC 2020

On Tue, 11 Feb 2020 at 09:09, Ahmed Borno <amaged at gmail.com> wrote:

> 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.

I can't see situation getting better. Why should vendor invest in high
quality code, certainly the cultural shift will cost something, it's
not 0 cost and what is the upside? If IOS and JunOS realistically were
significantly less buggy many of us would stop buying support, because
we either know how to configure these or can get help faster free from
the community, we largely need the support because the software
quality is so bad _everyone_ finds new bugs all the time and we don't
have the source code to fix it as a community.
So I suspect significantly better quality software would at least
initially cost more to produce and it would reduce revenue in loss of
support.

I also think the way we develop needs to be fundamentally rethought,
we need to stop believing I am the person who can code working C, it's
the other people who are incompetent. At some point we should look,
are the tools we using the right tools? Can we move complexity from
human to computers at compile time to create more guarantees of
correctness? MSFT claims 70% of their bugs are memory safety, issue
which could be solved almost perfectly programmatically by making the
compiler and language smarter, not the person more resistant to
mistakes.
I think ANET at least for some part essentially writes their own DSL
which compiles to C++, I think solution like this for any large
long-lived project probably quickly pays dividends in quality, because
you can address lot of the systematic errors during the compilation
time and in DSL design.

-- 
  ++ytti