MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

[Scot Newton]

Our customers generally run in a very closed environment, and the limited users generally have accounts with most privileges enabled.

The brief description of this OpenVMS MUP states that when using the
SHOW PROCESS/CONTINUOUS command, there can be "local disclosure of information".

Does this MUP correct unintended display of system information only? Is there a nastier reason that would warrant installing this MUP?
Thanks!

[P Muralidhar Kini]

Hi Scot,

You can find the details of the patch at the following location -
* patch details: VMS831H1I_SYS_MUP-V1100
http://www11.itrc.hp.com/service/patch/patchDetail.do?patchid=VMS831H1I_SYS_MUP-V1100&sel={openvms:i64:8.3-1h1,}&BC=main|search|

As per the patch details -

>>5.2.1 A potential security vulnerability has been fixed with HP OpenVMS
>> Auditing
>> The vulnerability could result in a local disclosure of information.
This is related to OpenVMS Audit logfile information disclosure.
If a user logs in with a invalid password for a number of times, then he would
be marked as a intruder. However the break-in logs would contain invalid
password in the password field.
The fix was to replace the invalid password with the text "".

>> 5.2.3 SHOW PROCESS/CONTINUOUS Command can cause undesired
>> behavior on OpenVMS I64 System
This was related to a problem where the system would crash when the
DCL "$SHOW PROCESS/CONTINUOUS" command was being executed.


>> Is there a nastier reason that would warrant installing this MUP?
Does not look like.

Based on the above information, you need to decide whether its important for
this patch to be installed in your environment.

Hope this helps.

Regards,
Murali

[Volker Halle]

Murali,

thank you very much for the additional details of the 'local disclosure of information'. Note that this 'disclosure' most likely does exist since OpenVMS V1.0, so it was a design decision to display the passwords under these circumstances. You need privileges or access to a privileged terminal to view this data.

This information should help the system managers to decide, whether to install this MUP patch.

Volker.

[Robert Gezelter]

Scot,

Please take particular note of 5.2.3 in Murali's post.

Potential crashes that have not yet been experienced tend to be discounted. Unfortunately, Murphy's Law applies. Additionally, there are frequently other ways of encountering the problem.

Scheduled updates are generally easier to deal with than an unexpected encounter with the problem.

- Bob Gezelter, http://www.rlgsc.com

[Scot Newton]

Thanks for the information everyone. Will instruct our customers to install this MUP at next scheduled PM.

[P Muralidhar Kini]

Hi Scot,

Please refer the following link which says how you can thank the forum -
http://forums11.itrc.hp.com/service/forums/helptips.do?#28

Regards,
Murali

[John Gillings]

re: Murali

So here's what you get when you eliminate much of the history/memory of your engineering team!

My recollection is that what appears to have been changed was a deliberate feature of intrusion detection and evasion.

*Suspect* usernames and passwords were obscured in audit alarms and journal, on the assumption that a common error for a geniune login error for an authorized user would be for the username and/or password to contain sufficient information to guess the real password.

However, once there were sufficient attempts to become an intruder, it's unlikely to be a real error, so both usernames and passwords were logged in clear text. Since the audit journal requires privileged access, it's not such a big deal that a password might be revealed, as anyone who can read it can reset passwords anyway. Second, it allows the system manager to analyze intrusion attempts to determine the nature of the attack (which I've used a few times).

[Hoff]

John's recollection is correct.

This is (was) documented and intentional behavior within OpenVMS security mechanisms, and was designed to allow any particular password selections or break-in techniques being utilized by the intruder to be identified. Specifically, if this was a dictionary attack or something targeted to the user or the group or the server or the organization.

Here's a quick reference:

http://h71000.www7.hp.com/doc/84final/6048/6048pro_008.html

Additionally (and with rather more clarity) "Passwords used in break-in attempts are not displayed on security operator terminals, but they are logged to the security audit log file and can be displayed with the Audit Analysis utility." from page 325 here:

http://h71000.www7.hp.com/doc/732final/aa-q2hlg-te/aa-q2hlg-te.pdf

The decision to send these break-in passwords (just) to the auditing database and not to alarms (where viewing was not controlled) was also deliberate, as was the decision to send along cleartext passwords for an intruder and not for suspects.

[Ian Miller.]

My understanding is that this is a deliberate change in policy.

[Brad McCusker]

>My understanding is that this
>is a deliberate change in policy.

Ian - Really? Was the change in policy before or after the code change?

If this really was a change in policy, why was the change in policy not documented as such? Why was this presented as a "Problem corrected" and then a MUP issued?

If the intent was to change a well known behavior it should have been clearly documented as a change in behavior.

Brad McCusker

Software Concepts International
www.sciinc.com