Multiple Vulnerabilities In Micro Focus VisiBroker C++


Multiple vulnerabilities


Micro Focus VisiBroker C++

Vulnerable Version

8.5 SP2

Fixed Version

8.5 SP4 HF3

CVE Number

CVE-2017-9281, CVE-2017-9282, CVE-2017-9283






W. Ettlinger (Office Vienna) | SEC Consult Vulnerability Lab

Multiple vulnerabilities in VisiBroker C++, a CORBA middleware, allow an attacker to conduct a denial-of-service attack or potentially execute arbitrary code by sending manipulated CORBA requests.


Vendor Description

“VisiBroker(TM) is a comprehensive CORBA environment for developing, deploying, and managing distributed applications. Built on open industry standards and a high-performance architecture, VisiBroker is especially suited to low-latency, complex, data-oriented, transaction-intensive, mission-critical environments. Using VisiBroker(R), organizations can develop, connect, and deploy complex distributed applications that have to meet very high performance and reliability standards. With more than 30 million licenses in use, VisiBroker is the world’s most widely deployed CORBA Object Request Broker (ORB) infrastructure.”


Business Recommendation

During a superficial fuzzing test, SEC Consult found several memory corruption vulnerabilities that allow denial of service attacks or potentially arbitrary code execution. Although the fuzzing test only had a very limited coverage, several vulnerabilities have been identified. Assuming the code quality is homogenous, it is possible that other parts of the application exhibit similar issues.

SEC Consult did not attempt to fully evaluate the potential impact of the identified vulnerabilities.

SEC Consult recommends to decommission any VisiBroker C++ component that communicates with untrusted entities until a full security audit has been performed. Moreover, SEC Consult recommends to restrict network access to all CORBA services that utilize the VisiBroker C++ environment.

Vulnerability Overview / Description

1) Integer Overflow / Out of Bounds Read (Denial of Service) [CVE-2017-9281]

By specifying a large value for a length field, an integer overflow occurs. As a result, the application reads memory until a non-mapped memory region is reached. This causes the application to encounter a segmentation fault.

2) Integer Overflow (Heap Overwrite) [CVE-2017-9282]

By specifying a manipulated value for a length field an attacker can cause an integer overflow. This causes the application to allocate too little memory. When the application attempts to write to this memory buffer, heap memory is overwritten leading to denial of service or potentially arbitrary code execution.

3) Out of Bounds Read [CVE-2017-9283]

By specifying a manipulated value for a length field, an attacker can cause the application to read past an allocated memory region.

4) Use after Free

SEC Consult found that the application under certain circumstances tries to access a memory region that has been deallocated before. It is unclear whether Micro Focus fixed the root cause of this behaviour. As the vendor was unable to reproduce the vulnerability in the current version, Micro Focus believes that the vulnerability was fixed with a previous update.

Since SEC Consult is unsure whether Micro Focus found the root cause of the vulnerability, we refrain from releasing proof of concept code.

Proof Of Concept

A service implementing the following IDL was used to identify the vulnerabilities listed here:

module Bank {
interface Account {
float balance(in string test);
interface AccountManager {
Account open(in string name);

The implemented service was based on the Visibroker example project “bank_agent”.

1) Integer Overflow / Out of Bounds Read (Denial of Service)

The method

CORBA_MarshalOutBuffer *__cdecl CORBA_MarshalOutBuffer::put(
CORBA_MarshalOutBuffer *this,
const char *src,
unsigned int size)

is used to copy/append a char[] into a buffer. If the size of the data that is stored in the buffer plus the size of the char[] to be appended exceeds the allocated size, the method reallocates the buffer. By choosing the size of the char[] as e.g. 0xffffffff (on 32 bit systems) an integer overflow can be caused. The method then continues without allocating additional memory.

However, the application then expects that the source buffer contains 0xffffffff bytes of memory. Since this would exceed the available process memory on 32 bit systems, the application’s attempt to copy data to the destination buffer fails with an out of bounds read.

The following binary request demonstrates this issue for the IDL above:


2) Integer Overflow (Heap Overwrite)

The method

int __cdecl CORBA::string_alloc(unsigned int size)

is used to allocate buffers for strings. Since it allocates size + 1 bytes of heap memory, specifying 0xffffffff causes an integer overflow leading to the allocation of 0 bytes. This causes heap memory to be overwritten.

SEC Consult was able to use the following request to cause corruption of heap structures:


3) Out of Bounds Read

The constructor

int __cdecl VISServiceId::VISServiceId(
VISServiceId *this,
CORBA_MarshalInBuffer *a2,
unsigned __int32 a3,
unsigned __int8 *a4)

parses the GIOP key address. The VisiBroker key address consists of two strings. Before each string, a long (32 bit) value specifies the length of the string. To calculate the offset of the second string, the size of the first string is used. If this value is chosen so that the offset of the second string is outside of the GIOP message, an out of bounds read occurs.

The following binary request demonstrates this issue for the IDL above:


4) Use after Free / Denial of Service

Micro Focus did not clearly state that the root cause of the vulnerability has been fixed. As a precaution we refrain from releasing proof of concept code.


At least VisiBroker C++ 8.5 SP2 has been found to be vulnerable. According to the vendor VisiBroker 8.5 prior to SP4 HF3 are vulnerable to issues #1 – #3.

Vendor Contact Timeline

2017-05-03 Contacting vendor through, attaching encrypted security advisory
2017-05-03 Vendor: will inform us about the timeframe once the findings have been reproduced
2017-05-26 Vendor: were able to reproduce first 3 issues; requested further information for vulnerability #4
2017-05-30 Providing further information for vulnerability #4
2017-06-21 Requesting status update
2017-06-28 Vendor: First three issues have been fixed by the development team, “They have reproduced the fourth and are working on it now.”
2017-06-30 Vendor: Patch will be available in a few weeks
2017-07-28 Requesting status update
2017-08-02 Vendor: There is no fixed release date for the patch yet
2017-08-28 Vendor: Initial test run found an issue that has been fixed
2017-09-15 Requesting status update
2017-09-15 Vendor: “The patches were just released on the 12th and 13th”
2017-09-18 Asking for further information about CVEs, affected versions
2017-09-21 Vendor: Issue #4 has not been fixed since the team was unable to reproduce it (the vendor stated that the issue has been reproduced, see 2017-06-26). “They [the team] believe it was already fixed by an earlier modification.”
2017-09-27 Requesting clarification for issue #4
2017-09-27 Vendor: The team initially thought they had reproduced the issue; this was an unrelated issue that was fixed as well.
2017-10-16 Public release of the advisory;


Upgrade to version 8.5 Service Pack 4 Hotfix 3. The release notes with information on how to obtain this hotfix can be obtained here:



Advisory URL


EOF W. Ettlinger / @2017


Interested to work with the experts of SEC Consult? Send us your application.
Want to improve your own cyber security with the experts of SEC Consult? Contact our local offices.