[Info-vax] Software does wear out, was: Re: Raid Controller in I64 ans Alpha(MSA$UTIL)

[David Froble]

Simon Clubley wrote:
> On 2013-11-30, David Froble <davef at tsoft-inc.com> wrote:
>> Simon Clubley wrote:
>>> On 2013-11-26, David Froble <davef at tsoft-inc.com> wrote:
>>>> If you can assume that VMS is working today, no problems, then I feel 
>>>> that it is a safe assumption that it will work the same tomorrow. 
>>>> Software doesn't wear out.
>>>>
>>> Tut, tut. I expected better from you... :-)
>> Ok, let's discuss it.  I sometimes like a challenge ...
>>
> 
> $ set response/mode=good_natured
> 
> Ok, have a think about the following issues: :-)
> 
>>> Software most certainly _can_ wear out in at least one form:
>> If it does something today, it will do the same thing tomorrow.  I stand 
>> by that statement.
>>
> 
> Not always true. What happens when you hit some internal date/time
> limit you might not have been aware of ?
> 
> For example, the 19-May-1997 10,000 day limit (which was a pure VMS
> problem) or when you start storing dates past 19-Jan-2038 in a signed
> 32-bit integer with a 1970 base ?
> 
> BTW, time_t is the perfect example of something which should have been
> unsigned from day 1. (I think I may have mentioned one or twice my
> opinions on defaulting to signed integers unless required. :-))
> 
>>> What happens when someone comes along with a new exploit for your
>>> networking stack or even in VMS itself and there's no one around
>>> to fix it ?
>> A very valid concern.  However, there could be multiple answers to such 
>> problems.
>>
>> If you are on an emulaltor, it's possible to control anything going to 
>> or from VMS.  Actually, from the virtual machine running VMS, to be 
>> percise.  Not saying that it would be optimal or easy.
>>
> 
> Not so easy.
> 
> To pick a simple example (just to demonstrate the type of issue I am
> thinking of), imagine you _need_ a SMTP server running on your VMS box
> as part of your application workflow.
> 
> Now imagine someone finds a exploit, triggered by, say, a specific command
> sequence or parameter format, which allows your SMTP server to do things
> it must _not_ be allowed to do. [*]
> 
> You now have to implement a method which allows your SMTP server to
> continue to operate as normal for your application workflow, but blocks
> the specific SMTP level sequence exploit.
> 
> How do you do this when you can't get someone to fix your SMTP server
> because VMS is no longer supported by HP ?
> 
> You can't block SMTP at firewall level because the SMTP server is required
> as part of your application workflow. You may be able to get someone to
> modify your firewall to do deep packet inspection (DPI) on the SMTP packets,
> but, depending on the specific exploit, that could still be tricky.
> 
> You can't do it in a normal emulator however, because the emulator (with
> some basic exceptions such as idle loop detection) emulates a machine
> without any deep knowledge of what is running on that emulated machine.
> 
> In theory, with enough knowledge and access to the emulator sources, it
> may be possible to rewrite parts of the emulator to add that support;
> maybe by adding DPI code to inspect the packets passing through the
> emulated NIC.
> 
> However, in reality, running VMS in a emulator in production use, when
> applications are exposed to untrusted data, is not a viable option if
> you cannot get the software fixed that's running under that emulator.
> 
> (For example, what happens when it's a issue within VMS itself (such as
> the above time issues) and not something which could be tackled using DPI ?)
> 
> Simon.
> 
> [*] Actually, thinking about it, about a decade ago, I managed to get
> the SMTP server to act as a open relay when a very specific sequence
> was used (even though the SMTP server had been correctly configured).
> I reported it to HP and it was fixed.
> 

Well, as my first response to your arguments ....

Gérard Calliet (pia-sofer) wrote:

 > hum ! all that let me remember a story :
 >
 > Max and John speak about their next hollidays in Africa.
 > Max : “you know there are a lot of lions in Africa”
 > John : “if you know how to do with a lion, no problem”
 > Max : “how do YOU do, you don’t know anything about it”
 > John : “first thing, have with you a gun”
 > Max : “and if You meet the lion and have forgot the gun”
 > John : “I ‘ll never forgot the gun”
 > Max : “and if you have no munitions ?”
 > John : “I will always have munitions”
 > Max : ”and if you gun is blocked ?”
 > John : “ok, I keep cool, I don’t move, and the lion will go away”
 > Max : “and if runs back you”
 > John : “I will climb a tree”
 > Max : “and if there is not any tree ?”
 > John : “hum, Max, you are for me or for the lion ?”


Yes, there can always be issues.  Doesn't mean they will happen.

Codis uses an 8 byte string of the format "yyyymmdd" for dates.  I 
seriously doubt we'll have any problems for the next 8000 years.

I'm sure there may be things that we, and others, use that might have a 
problem.  I still feel that there is a much lesser chance of the 
software breaking than for some piece of hardware to fail.