For a computer with a mature, proprietary operating system, the HP 3000 has been flagged for a glut of security holes in the last few weeks. Some observers thought the alarm about one regarding AIFs was a matter of HP security experts “discovering” the 3000. First, HP identified a hole in the Java Runtime Environment on the 3000. Sun passed along that warning, saying it poses a possible security risk by allowing a trusted class to call into a disallowed class under certain circumstances. To close this breach, customers must install the 1.2.2 MPE Version A.22.04 or higher release of Java; anything older has the hole in it. The problem applies to the MPE/iX releases certified for Java on the 3000, 6.0, 6.5 and the just-released 7.0.

The next breach reaches back even further, to MPE/iX 5.5 systems and others more recent. HP learned that Native Mode Debug does not handle breakpoints correctly, and so users fooling with it can obtain unauthorized privileges. HP’s got patches to solve this problem: MPELX89D for MPE/iX 5.5; MPELX89E for MPE/iX 6.0, and MPELX89F for MPE/iX 6.5. The 7.0 release isn’t affected.

Another problem with linkeditor on 5.5, 6.0 and 6.5 can also allow normal users of the program to gain “certain capabilities that are allowed for the system manager.” Again, there’s patches to close this hole: MPE/iX 6.5 gets LNKLXG1A, MPE/iX 6.0 users should install LNKLXG1B, and MPE/iX 5.5 users can install LNKLXG1C. HP’s window on 5.5 patches is only open for three more months, so order soon.

As if those three security warnings were not enough, HP issued a fourth warning regarding an Architected Interfaces Facility (AIF). These programming aids have been used by third party vendors and HP for years, and the AIFCHANGELOGON facility can give users unauthorized access to databases, let them gain additional privileges and compromise system availability. Once more, there are patches in play: For MPE/iX 6.5, install MPELXJ3C, for MPE/iX 6.0, install MPELXJ3B, and for MPE/iX 5.5, install MPELXJ3A. Allegro Consultants’ Gavin Scott notes that “AIFCHANGELOGON is a privileged routine, so I’m fuzzy on why this is a big deal. Assuming I can call AIFCHANGELOGON, I can think of lots of ways it could be used to override one or another common security mechanism — but I would think that any privileged program that is using AIFCHANGELOGON should be required to know what it’s doing. If someone writes a program that lets anyone AIFCHANGELOGON at will, then they shouldn’t be too surprised at the result.”