From: [email protected]
To: [email protected], [email protected]Subject: TSRT-06-14: IBM Tivoli Storage Manager Mutiple Buffer Overflow
Vulnerabilities
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004
Sender: [email protected]
Message-ID: <OF5F5FDC47.EB67E77A-ON8825723A.0082D0A0-8825723A.008337E8@3com.com.>
Date: Mon, 4 Dec 2006 15:53:15 -0800
X-MIMETrack: Serialize by Router on USDB001/US/3Com(Release 6.5.4FP3|January 09, 2006) at
12/04/2006 03:53:23 PM,
Serialize complete at 12/04/2006 03:53:23 PM
Content-Type: text/plain; charset="US-ASCII"
X-Virus-Scanned: antivirus-gw at tyumen.ru
TSRT-06-14: IBM Tivoli Storage Manager Mutiple Buffer Overflow
Vulnerabilities
http://www.tippingpoint.com/security/advisories/TSRT-06-14.html
December 4, 2006
-- CVE ID:
CVE-2006-5855
-- Affected Vendor:
IBM
-- Affected Products:
Tivoli Storage Manager <5.2.9
Tivoli Storage Manager <5.3.4
-- TippingPoint(TM) IPS Customer Protection:
TippingPoint IPS customers have been protected against this
vulnerability since April 3, 2006 by Digital Vaccine protection
filter ID 4248. For further product information on the TippingPoint IPS:
http://www.tippingpoint.com
-- Vulnerability Details:
These vulnerabilities allow attackers to execute arbitrary code on
vulnerable installations of IBM Tivoli Storage Manager. Authentication
is not required to exploit these vulnerabilities.
The specific flaws are similar and exist in the processing of messages
by the Tivoli Storage Manager service, bound on TCP port 1500. The
messages are structured in the form [index][size]. The 'index' field
specifies an integer offset into the body of the message for a specific
field, and the 'size' field specifies the size of the indexed field.
As no validation is done on the index fields, an attacker can force the
service to look beyond the end of the packet, often landing in
unallocated memory and resulting in a denial of service.
The size fields are often checked to ensure they do not exceed the
bounds of the destination buffers that data is being copied to.
However, we have found the following four instances where the size
files are left unchecked:
Overflow 1
The initial sign-on request contains a field to specify the language.
In normal cases we've seen, this string is dscenu.txt. Typically the
server will validate that the language string is no longer than 0x100
bytes. However, if the first byte of the language string is 0x18, this
check will not occur, and a fixed sized buffer will be overrun.
Overflows 2 and 3
There is an overflow vulnerability in messages processed by the
SmExecuteWdsfSession function. There are two fields in this request,
both are copied into fixed sized buffers, without any validation of
their lengths.
Overflow 4
There is an overflow in the open registration message due to an
unchecked copy into a fixed size buffer for the contact field of the
registration.
All four of the above detailed overflows can lead to arbitrary code
execution under the context of the Tivoli service.
-- Vendor Response:
IBM has issued an update to correct this vulnerability. More details can
be found at:
http://www-1.ibm.com/support/docview.wss?uid=swg21250261
-- Disclosure Timeline:
2006.04.03 - Digital Vaccine released to TippingPoint customers
2006.05.09 - Vulnerability reported to vendor
2006.12.04 - Coordinated public release of advisory
-- Credit:
This vulnerability was discovered by the TippingPoint Security Research
Team.
-- About the Zero Day Initiative (ZDI):
Established by TippingPoint, a division of 3Com, The Zero Day Initiative
(ZDI) represents a best-of-breed model for rewarding security
researchers for responsibly disclosing discovered vulnerabilities.
Researchers interested in getting paid for their security research
through the ZDI can find more information and sign-up at:
http://www.zerodayinitiative.com
The ZDI is unique in how the acquired vulnerability information is used.
3Com does not re-sell the vulnerability details or any exploit code.
Instead, upon notifying the affected product vendor, 3Com provides its
customers with zero day protection through its intrusion prevention
technology. Explicit details regarding the specifics of the
vulnerability are not exposed to any parties until an official vendor
patch is publicly available. Furthermore, with the altruistic aim of
helping to secure a broader user base, 3Com provides this vulnerability
information confidentially to security vendors (including competitors)
who have a vulnerability protection or mitigation product.
