topic Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this? in Operating System - OpenVMS

MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Scot Newton — Tue, 06 Jul 2010 22:30:25 GMT

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!

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

P Muralidhar Kini — Wed, 07 Jul 2010 02:17:16 GMT

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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Volker Halle — Wed, 07 Jul 2010 04:25:54 GMT

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.

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Robert Gezelter — Wed, 07 Jul 2010 12:59:06 GMT

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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Scot Newton — Wed, 07 Jul 2010 14:32:16 GMT

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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

P Muralidhar Kini — Wed, 07 Jul 2010 14:37:32 GMT

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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

John Gillings — Sun, 11 Jul 2010 22:00:18 GMT

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).

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Hoff — Sun, 11 Jul 2010 22:48:47 GMT

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.

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Ian Miller. — Mon, 12 Jul 2010 12:35:07 GMT

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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Brad McCusker — Mon, 12 Jul 2010 15:19:27 GMT

>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

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

sgprasad — Tue, 13 Jul 2010 02:44:28 GMT

Hi,

The text the "OpenVMS Guide to System Security" is changed in the "HP OpenVMS Guide to System Security OpenVMS Version 8.4"

http://h71000.www7.hp.com/doc/84final/ba554_90015/ba554_90015.pdf

"Passwords used in break-in attempts are not displayed on security operator terminals and also not logged to the security audit log file."

Thanks and warm regards,
Prasad

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Verne Britton — Tue, 13 Jul 2010 17:30:50 GMT

I was concerned by this too, and logged case 4616845931 on July 8 ... (I figure we have had a support contract for 25+ years, might as well ask a question or two):

and was given this response and the case was closed (no one told me it was secret) (may wrap poorly):

We understand that customer is asking for an option to display the wrong password from the break in
records, which were disabled in the recent recent vms*_sys_mup-v* patches.
As already highlighted in the problem description, this change was done due to a security alert.
Leaving an option to display the wrong password in the operating system can be abused in general.
It is also an industry standard to not display any information related to passwords in the logs.
While the wrong password display might be useful for the current customer in some cases, going
without this display will be a safe and recommended approach.
Thanks and warm regards,
(OpenVMS Security Engineering)

============================================
=========

I mentioned to them I have made use of (as others have said) the literal password data in the audit logs in the past ...

I also suggested having a switchable setting ... with the default being to hide the password but allow the system manager to return to the old behavior if desired.

Verne

Re: MUP VMS831H1I_SYS_MUP-V1100 - how critical is this?

Ian Miller. — Wed, 14 Jul 2010 07:15:24 GMT

References

SSRT100144
SSRT090267
CVE-2010-1973