 |
» |
|
|
|
|
|
|
|
A security vulnerability has been reported, affecting all
recent versions of the HP TCP/IP Services for OpenVMS
product. Only systems where the Finger service is
enabled are at risk. The service is disabled by default,
and many HP customers choose to leave it that way, either
because they do not require Finger or because they view
the Finger service itself as a threat to security.
Because the purpose and intent of Finger is to disclose
information about who is using your system and what they
are doing, HP recommends that Finger be disabled in all
but the most isolated and friendly network environments.
If Finger is already disabled on your system, or you
choose to disable it now, no further action is needed to
protect yourself from this vulnerability. In order to
disable the service, execute the TCPIP$CONFIG.COM
utility, select the Server Components menu (choice 3),
and then select Finger (choice 4).
For those who wish to continue using Finger, several
options are available.
The Finger client can continue to be used, with certain
limitations, even when the service is not enabled. It is
also possible to start the service but immediately
deinstall the client image (TCPIP$FINGER.EXE), which is
sufficient to protect against the reported vulnerability
on systems prior to OpenVMS V8.3, when symbolic link
support was introduced.
A final option is to obtain updated images for Finger.
New images are available for TCPIP V5.4 ECO 7, V5.5 ECO 3,
and V5.6 ECO 2. (The fix is already included in the
forthcoming V5.6 ECO 3 kit.) Choose either the Alpha or
the Integrity ZIP file, and extract the contents. Copy
the appropriate TCPIP$FINGER and TCPIP$FINGER_SERVER
images to the SYS$COMMON:[SYSEXE] directory, changing the
extension to simply .EXE, and restart the Finger service.
For I64: tcpip_finger.zipexe_i64 (301KB)
For Alpha: tcpip_finger.zipexe_alpha (171KB)
|
|
|
|
|
|
Some HP TCP/IP versions contain a DNS cache poisoning vulnerability.
One class of attack against a DNS nameserver is known as
a "cache poisoning" attack. The attacker finds a way to
introduce forged entries into the cache of a DNS server
so that later, when other clients resolve a particular
target (usually a host name), they will get the wrong
information (usually an IP address). Such attacks have
been known for years, along with various improvements in
the design of DNS software implementations to resist the
attacks. Like much of the industry, HP TCP/IP Services
for OpenVMS uses the BIND implementation of DNS, and we
thus share both the same vulnerabilities and the same
fixes as many UNIX and Linux platforms.
In recent weeks, a new and more dangerous variant on the
cache poisoning attack has been announced, receiving a
remarkable level of publicity. As usual, OpenVMS shares
both the vulnerability and the fix with many other
platforms. More information is available from many
sources including the US-CERT Vulnerability Note at
http://www.kb.cert.org/vuls/id/800113 . As suggested in
that note, cryptographic security using DNSsec is a good
long-term approach to preventing such attacks, and we
continue to support DNSsec on OpenVMS.
Before hastening to obtain and install a patch for this
vulnerability, you should determine the extent to which
your OpenVMS systems are affected. While systems running
the BIND server are possible targets, most systems run
only the BIND resolver. If your system is not acting as
a nameserver, you do not need this update.
Among systems that do run the BIND server, two
ingredients are necessary for a successful attack: the
ability for an attacker to reach your system to poison
the cache, and consumption of the forged data by other
clients. If your nameserver is behind a firewall, that
would make it more difficult for an outside attacker to
poison its cache. Once poisoned, the success of the
attack hinges upon someone else resolving information
from that same nameserver. For example, if there are no
clients using a particular nameserver other than the
OpenVMS system itself, the effect of the attack would be
limited to that single host. The nameservers most
vulnerable to a cache poisoning attack would be the main
servers for a large organization, assuming they were
connected directly to the Internet and used by many
client hosts within the organization and its customers or
affiliates.
We will be including an updated version of this fix in
the TCPIP V5.6 ECO 3 kit; that release is expected soon.
Meanwhile, customers who urgently need a fix for TCPIP
V5.4 ECO 7, V5.5 ECO 3, or V5.6 ECO 2 can obtain a new
image here. Choose your target platform (Alpha or
Integrity), then copy the self-extracting ZIP file. Once
the images are extracted, pick the appropriate one for
your version (V5.4, V5.5, or V5.6), and copy it to
SYS$COMMON:[SYSEXE]TCPIP$BIND_SERVER.EXE. Restart your
BIND server, and you will be running the updated version.
For Integrity: TCPIP_BIND_SERVER.ZIPEXE_I64 (3 MB)
For Alpha: TCPIP_BIND_SERVER.ZIPEXE_ALPHA (3 MB)
|
|
|
