[Info-vax] DCL crashing bug update

[Stephen Hoffman]

On 2017-07-27 00:58:51 +0000, clair.grant at vmssoftware.com said:

> OK, I'll give this a shot. Whenever a code change is proposed, however 
> big or small, bug fix or new feature, we try to evaluate everything 
> that could be affected. Original intent (design) is a factor but the 
> bottom line is how the existing code gets changed. People with relevant 
> expertise review code and discuss. Sounds simplistic but that's what 
> happens, has for years. Obviously, every situation is different but 
> generally that's the way it works. Also, everything is reviewed by the 
> test engineers to see if existing tests or new tests are need to 
> properly exercise the changes.

There's a corollary to this design and review process, too.

Years ago, we were dealing with the sorts of shenanigans arising just 
from local and locally-connected folks, and most servers had staff 
assigned.   Our servers ran code written locally, or purchased from 
vendors or third-parties.  Our servers communicated locally with other 
servers we controlled, over a network we controlled.   Then we got 
dial-up.   Our servers started connecting remotely.  The number of 
folks accessing our servers got larger, and we were on the receiving 
end of war-dialing.   Which led to some of us using the "system" 
system-wide password mechanism, too.  Now we have planetary-scale 
access to many of our servers and whether that's directly or 
indirectly, and with far fewer staff covering far more servers.   Our 
servers are parts of massively-connected and networked systems.   We're 
increasingly running code from open-source archives and pre-built 
images from repositories, and it's routine to be running code on 
various of our local networked systems that has been loaded from remote 
servers and variously from servers we don't control.   Some of the 
networks we're connecting to or through and even some of the servers 
we're accessing can be accessible to attackers.   And botnets with 
massive resources continuously probing and testing our security 
continuously, and with ever more sophisticated networking and reversing 
tools available.

For some of us and what we're doing with our servers, we're already in 
a position where we can't trust what's running on our servers, and 
we're increasingly in an environment when we can't trust ourselves and 
what's in our source code repositories and our installed system and 
application configurations, and that's an even larger shift.  Where we 
have to design some of our own systems such that we can't get into them.

All code and all designs that haven't been reviewed in response to 
these changes are suspect.  Code that hasn't been fuzzed is suspect, 
and system and application installations that aren't or can't be 
cryptographically verified are all suspect.   Why?   Because somebody 
is inevitably going to review and fuzz the code.   If that's not us 
reviewing our own code looking for these latent assumptions and these 
now-mistakes, and verifying that our hardware and software and network 
environments are as intended, well, that can be a Bad Day for us.   
Because attackers don't care what combination of vulnerabilities they 
chain together — some down-revision printer exploit gets the attacker 
network access, network access sniffs SCS packets or private DECnet or 
telnet traffic or ARP spoofs and MITM's some HTTP traffic, and those 
unencrypted packets expose the known-weak Purdy password hash (yes, VSI 
is reportedly addressing that) or cleartext credentials or some other 
authentication, and....

I routinely end up working in source code that's ten and twenty years 
and variously older.    Code that was well-designed and that's been 
stable for a decade or two can now be operating in system and network 
environments that it was never designed nor intended nor tested for.   
Some other code was vulnerable as originally designed, but was 
supposedly isolated and all it takes is one bad coffee pot connected on 
the supposedly-still isolated network.

Beyond design reviews and testing reviews and source code reviews and 
fuzzing, we all certainly remember to actively review the state of our 
supposedly-isolated and secure private networks, right?   We've all 
checked our switch and firewall firmware revisions?   For our own 
access control and badge readers, we've all retired and replaced any 
125 KHz or Mifare NFC hardware, right?

Environments and vulnerabilities and risks change.   So must our 
responses and our implementations.  So must our designs, reviews and 
testing.





-- 
Pure Personal Opinion | HoffmanLabs LLC