VirtualBox

Ticket #7792 (closed defect: obsolete)

Opened 3 years ago

Last modified 3 months ago

Bug in host side network driver - vboxnetflt

Reported by: mikevm Owned by:
Priority: major Component: network/hostif
Version: VirtualBox 3.2.12 Keywords:
Cc: Guest type: other
Host type: other

Description (last modified by frank) (diff)

This bug has existed for quite a long time and is a subtle thing that may have been easily missed by many, but here goes:

If on the host you have a network interface - say, eth0 in this example - and you configure an IP address on this interface on the host. If you then start a guest that is bridged to this adapter, packets going from the guest to the host's IP behave as expected, but reply packets from the host to the guest are sent out the physical medium instead of just being bridged internally.

The result is the following:

Packets flowing from the host to the guest, hit the physical media, which typically is a network switch. If the guest is not talking to any host on the network other that the host it's running on, the switch will flood the packets to all ports in the lan since the switch doesn't know where the source is (inside the host in this case).

I have been able to verify this in 3.2.12 and the test is pretty simple, as follows:

Set up 2 pc's with a network crossover cable between them. The first PC will be the 'host', and running virtualbox. The second will simply run TCPDUMP to inspect traffic sent over the ethernet cable.

Give the host's ethernet in this test and IP address, say 10.1.1.1.

Setup a guest instance on the host and give it an ethernet that is bridged to this adaptor. Log into the guest and configure an ip on it's interface, such as 10.1.1.2

From the guest, start a ping - ping 10.1.1.1

Over on the second PC running tcpdump, you will observe the initial arp request (correct operation), and then you will see ICMP echo replys sourced from the host directed at the guest (incorrect operation). These packets are flooded to the network when in reality, the should not be since the destination mac address is a local guest.

I have tried putting the hosts's ethernet into a bridge interface, thinking that would stop the frames from leaving the host, but I was suprised to learn that they are still sent out of the physical ethernet despite the bridge knowing the mac of the guest.

Thank you for virtualbox.

Change History

comment:1 Changed 3 years ago by Technologov

It is interesting of this affects only Linux hosts, or all hosts.

-Technologov

comment:2 Changed 3 years ago by frank

  • Component changed from network to network/hostif

comment:3 follow-up: ↓ 4 Changed 3 years ago by aleksey

Thank you for the report. The problem affects Linux hosts only. We will address it in the next major release of VirtualBox.

comment:4 in reply to: ↑ 3 Changed 3 years ago by mikevm

Replying to aleksey:

Thank you for the report. The problem affects Linux hosts only. We will address it in the next major release of VirtualBox.

I should also point out this is a serious security problem because the lan flooding effectively allows anyone to sniff the host -> guest traffic. Example, if the host is an nfs or database server, and the guest is a client, the flooded traffic will effectively be the raw filesystem data and raw sql query replies.

comment:5 Changed 3 years ago by frank

The problem should be fixed in 4.0. But note that for some devices the new mechanism does not work. So you might still experience this problem if you have the "wrong" hardware :)

comment:6 Changed 3 months ago by frank

  • Status changed from new to closed
  • Resolution set to obsolete
  • Description modified (diff)
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use