Post by David Froble
I'm not privy to how a buffer overflow happened in SMG. Maybe someone
could report this?
However, usually when one reads about buffer overflow, it's in
combination with zero terminated strings. Perhaps using languages
which do not support such would be a beginning to a solution? It
appears that wanna-be programmers just cannot learn to "just don't use
zero terminated strings".
Seems tome that it always comes back to coders who are clueless about
what they write could do?
There's a write-up around on the flaw. Somewhere.
The SMG bug was due to not accounting for control sequences used for
That mess is also when I realized I needed to know much more about
system and network security, and that what was often the norm for
security on OpenVMS was badly dated, but I digress.
SMG has been around since the mid-1980s and a VAX/VMS release far too
long gone. The developers working on SMG and the terminal driver and
the I/O stack weren't beginners, either. Far from it. One look at
the smg$create_menu descriptor usage would indicate more than a passing
knowledge of descriptors, too.
Code of that era within OpenVMS was written in Bliss or Macro, and both
Bliss and Macro32 are akin to C in terms of the pointer messes
possible. SMG well predates the era of C usage in OpenVMS, too.
Given that OpenVMS is now written in C with somewhat lesser and
still-substantial amounts of Bliss and Macro32, rewriting the whole
operating system into some other language is a non-starter, too.
Which means that implementing and using fuzzing, implementing
code-scanning tools, and other techniques, are likely to be involved
sooner or later in automated-scanning for issues. Maybe incrementally
reworking and writing new code in different languages with better
Developers make mistakes. Even experienced developers make mistakes.
This is why I've been pointing to newer programming languages, and
toward sandboxes and pledges, at mechanisms for easier and faster
patches, and at other related techniques for improving security and app
isolation. At two-factor authentication, for that matter. At ways
of reducing and isolating the sorts of problems that can and do and
will arise, and at increasing the effort involved for the attackers
seeking to exploit security vulnerabilities. Pointing at developers
and at end-users has worked so well for us all, after all. We all
make mistakes. Which means... pragmatically, how do we deal with that,
and how do we harden our systems and applications and our end-user and
Pure Personal Opinion | HoffmanLabs LLC