[Discuss] Port Scanning

[bogstad at pobox.com (Bill Bogstad)]

On Fri, Aug 2, 2024 at 2:31?PM Kent Borg <kentborg at borg.org> wrote:

> On 8/1/24 18:46, Rich Pieri wrote:
> > Because we didn't have firewalls in the 1980s.
> ....
>
> Both of of these were happening because we *were* aware there were
> problems and we *knew* needed to do something about them.
>
> In the mid '90s there were two ways we could have gone. We could have
> actually held ourselves to the obligation of building secure stuff--and
> fixing things when we got it wrong--or we could have let ourselves off
> the hook, hid behind firewalls, and let 30-years of garbage build up.
> (Not a whole 30-years worth, the early garbage has been retired.)


What you are basically saying is that we need to write software that has
essentially 0 bugs.   As has become clear over at least the last three
decades, virtually any bug can be converted into a security problem.  Not
just reduce the number of bugs, you have to get rid of virtually all of
them.   A bug in a code path that a real use case will never follow is just
as important as one that is used every time the program is run.   Attackers
will try them all and force every possible code path, etc.  Even the best
programmers seem unable to produce programs with a high enough level of
correctness on a long term basis.  Nor will anyone give them time to even
try.

While there are technologies that can catch whole classes of errors
automatically either at compile or run time, no one seems to use them for
anything other than academic/toy projects.   The complaint is always that
it will reduce the performance of programs by 5% or even 10%.  Despite the
fact that modern systems are multiple orders of magnitude faster than those
from the 90s, giving up any of that performance for a guarantee that
certain classes of errors can't result in unexpected behavior has never
been acceptable.  In many cases, we could do this by simply using compilers
which add automatic bounds/type checking rather than rewriting programs in
safer languages.   So fairly minimal programmer time, just minor slow
downs.  Nope, not interested.  I'm pretty sure that I've seen the "linux
kernel development community" multiple times shoot down the idea of doing
special-cased security checking for classes of problems.   The slowdowns
are never acceptable and we should all write perfect code instead.

I think it is basically because the industry has convinced itself that bugs
are inevitable and there is no way to mitigate those bugs becoming security
problems.   Back in the 90s, I found security fascinating; but when I
realized that nobody had any interest in actually doing anything more than
dealing with this week's problem, I decided that wasn't a career path I
wanted to follow.

Bill Bogstad