MaxDB 'vserver' Lets Remote Users Execute Arbitrary Code
SecurityTracker Alert ID: 1019571|
SecurityTracker URL: http://securitytracker.com/id/1019571
(Links to External Site)
Date: Mar 11 2008
Execution of arbitrary code via network, User access via network|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 184.108.40.206; possibly other versions|
A vulnerability was reported in MaxDB in the 'vserver' process. A remote user can execute arbitrary code on the target system.|
A remote user can send specially crafted data to TCP port 7210 to trigger a signedness error in 'vserver', overflowing the heap and potentially executing arbitrary code on the target system. The code will run with the privileges of the target service.
The remote user must supply the name of an active database on the server as part of the request.
The vendor was notified on December 6, 2007.
iDefense reported this vulnerability.
A remote user can execute arbitrary code on the target system.|
The vendor has issued a fix (see SAP note 1140135).|
Vendor URL: www.sdn.sap.com/irj/sdn/maxdb (Links to External Site)
|Underlying OS: Linux (Any), UNIX (AIX), UNIX (HP/UX), UNIX (Solaris - SunOS), UNIX (Tru64)|
Source Message Contents
Subject: iDefense Security Advisory 03.10.08: SAP MaxDB Signedness Error Heap|
iDefense Security Advisory 03.10.08
Mar 10, 2008
SAP's MaxDB is a database software product. MaxDB was released as open
source from version 7.5 up to version 7.6.00. Later versions are no
longer open source but are available for download from the SAP SDN
website (sdn.sap.com) as a community edition with free community
support for public use beyond the scope of SAP applications. The
"vserver" program is responsible for accepting and handling
communication with remote database clients. For more information, visit
the product's website at the following URL.
Remote exploitation of a signedness error in the "vserver" component of
SAP AG's MaxDB could allow attackers to execute arbitrary code.
After accepting a connection, the "vserver" process forks and reads
parameters from the client into various structures. When doing so, it
trusts values sent from the client to be valid. By sending a specially
crafted request, an attacker can cause heap corruption. This leads to a
potentially exploitable memory corruption condition.
Exploitation allows an attacker to execute arbitrary code in the context
of the running service. In order to exploit this vulnerability, an
attacker must be able to establish a TCP session on port 7210 with the
target host. Additionally, the attacker must know the name of an active
database on the server.
Since this service uses the fork() system call once a connection has
been accepted, an attacker can repeatedly attempt to exploit this
vulnerability. Some exploitation attempts may result in the database
process ceasing to run, in which case further exploitation attempts
will not be possible.
iDefense has confirmed the existence of this vulnerability in SAP AG's
MaxDB version 220.127.116.11 on Linux. Other versions may also be affected.
Employing firewalls to limit access to the affected service will
mitigate exposure to this vulnerability.
VI. VENDOR RESPONSE
SAP AG has addressed this vulnerability by releasing a new version of
MaxDB. For more information, consult SAP note 1140135.
VII. CVE INFORMATION
The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CVE-2008-0307 to this issue. This is a candidate for inclusion in
the CVE list (http://cve.mitre.org/), which standardizes names for
VIII. DISCLOSURE TIMELINE
12/06/2007 Initial vendor notification
12/10/2007 Initial vendor response
03/10/2008 Coordinated public disclosure
The discoverer of this vulnerability wishes to remain anonymous.
Get paid for vulnerability research
Free tools, research and upcoming events
X. LEGAL NOTICES
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDefense. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically,
please e-mail firstname.lastname@example.org for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct,
indirect, or consequential loss or damage arising from use of, or
reliance on, this information.
To unsubscribe, go here: