VBoxManage Segmentation Fault - VirtualBox 6.1.6 on macOS/Linux => fixed in svn/VBox.next

[cemonatk]

VBoxManage Segmentation Fault - VirtualBox 6.1.6 on macOS/Linux

Greetings,

Oracle VM VirtualBox software has a “Null Pointer Dereference” vulnerability on version 6.1.6. Hence it gives "Segmentation Fault" output.

poc.cpp and strace_output.txt and strace_output.png files are shared below: ​https://drive.google.com/open?id=1vUK6qdqQdNb89iG9_WhDyUpXZeGeXp7I

Steps to reproduce this vulnerability:

1. Install Oracle VM VirtualBox on *nix
2. Run the command below:
   1. VBoxManage internalcommands repairhd -format karray fireh
3. You will see “Segmentation Fault: 11”.
4. You can see a detailed one with following command:
   1. sudo strace -i /usr/bin/VBoxManage internalcommands repairhd -format karray fireh

Reproduction steps of our “poc.cpp” Proof of Concept code which is also shared above.

1. Download the latest source code from “https://www.virtualbox.org/svn/vbox/trunk/”. You can use wget for this:
   1. wget -m -np virtualbox.org/svn/vbox/trunk/
2. Add one of the following macro on the top of the “/include/iprt/cdefs.h” file:
   1. #define IN_RING3
   2. #define IN_RING0
   3. or #define IN_RC
3. Compile our “poc.cpp” with following commands:
   1. gcc -o poc poc.cpp -I ./include
4. Run compiled binary with strace:
   1. sudo strace -i ./poc
5. You will see the following output on terminal:

… [0000000000400619] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x168} --- ???????????????? +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)

You can compare the output with the output that we have below:

Command: sudo strace -i /usr/bin/VBoxManage internalcommands repairhd -format karray fireh

Output: … [00007fa0b6f7b3d7] close(9) = 0 [00007fa0b81c7a69] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x168} --- ???????????????? +++ killed by SIGSEGV (core dumped) +++ Segmentation fault (core dumped)

As you can see on output, the error is as same as we have on “VBoxManage” binary application.

Root Cause of The Issue:

Design Logic of RT_SUCCESS macros in the following header file: https://www.virtualbox.org/browser/vbox/trunk/include/iprt/errcore.h

1. The "rc" value which is passed into the following line is NULL:

67 #define RT_SUCCESS(rc) ( RT_LIKELY(RT_SUCCESS_NP(rc)) )

2. Then "rc" is passed into "RT_SUCCESS_NP" as seen in the following lines:

77 #ifdef RTERR_STRICT_RC 78 # define RT_SUCCESS_NP(rc) ( RTErrStrictType(rc).success() ) 79 #else 80 # define RT_SUCCESS_NP(rc) ( (int)(rc) >= VINF_SUCCESS ) 81 #endif

The part above has 2 conditions:

When the "rc" variable which was NULL converted to integer, then it is set to zero "0": " (int)(rc) "

2.1. If it was defined before then the following defines:

The following part calls success() method: RTErrStrictType(rc).success()

In the constructer of "RTErrStrictType", it sets the value to m_rc(rc).

120 class RTErrStrictType ... 145 RTErrStrictType(int32_t rc) 146 : m_rc(rc) 147 {

It is initalized as 0 (zero) in the following part since it is int32_t: 122 protected: 123 int32_t m_rc;

The source-code of success() which was called before is below: 165 bool success() const 166 { 167 return m_rc >= 0; 168 }

Therefore, this condition returns always True since it is 0>=0.

2.2. If it was not defined before then the following defines:

The code part which shows the "VINF_SUCCESS" is 0: https://www.virtualbox.org/browser/vbox/trunk/include/iprt/err.mac 28 %define VINF_SUCCESS 0

Then the macro became as follows: # define RT_SUCCESS_NP(rc) True

Then following code returns also always returns True since it is always 0>=0: (int)(rc) >= VINF_SUCCESS

Reference: CWE-476: NULL Pointer Dereference - ​https://cwe.mitre.org/data/definitions/476.html

Finders of this vulnerability: Cem Onat Karagun of Diesec and Fatih Erdogan of Zemana.

[cemonatk]

poc.cpp

[cemonatk]

Strace output

[cemonatk]

Strace output - txt

[Klaus Espenlaub]

This is definitely a bug, and like any non-cosmetic bug worth a fix. It is not a (security) vulnerability, because there is absolutely no impact on the confidentiality, integrity or availabilty dimensions, so the CVSS would always be 0.

Shouldn't take that much effort to fix.

[cemonatk]

Dear Klaus,

We partially agree, just wanted to have a public POC. Many thanks for calculating the CVSS point, we appreciate it.

Yes, it shouldn't take that much effort to fix. Just after creating this ticket, we searched online (site:www.virtualbox.org "Segmentation fault" "VBoxManage") and saw similar Segmentation fault reports. One of them was opened 12 years ago: https://www.virtualbox.org/ticket/2184

We are glad to spot a null pointer dereference in a header file of VirtualBox, hope someone can spot that thing in our report (:

• Cem / Fatih

[paulson]

Thanks for the detailed bug report and analysis. As you discovered, the 'VBoxManage internalcommands repairhd' command dereferences a NULL pointer in VD.cpp:VDRepair() due to VDPlugin.cpp:vdFindImageBackend() returning RT_SUCCESS even when no backend descriptor was found.

This issue has been addressed in revision r138005 of the development branch of VirtualBox and will be available in any development snapshot Testbuilds which includes that revision. The fix has also been backported to the 6.1 branch of VirtualBox as of revision r138033, to the 6.0 branch of VirtualBox as of revision r138034, and to the 5.2 branch of VirtualBox as of revision r138035 and will be available in any corresponding Testbuilds containing these revisions. The fix will thus also be part of the next maintenance release of VirtualBox for the 5.2.x, 6.0.x, and 6.1.x branches.