There are two main ways by which a corrupted/evil guest VM may hurt its host:
By talking to the host over the network; this is similar to having an evil machine on the same LAN as the host, although there can be details, depending on how networking works in your particular VM.
By "escaping" the virtualization layer, a successful escape granting (for instance) read/write access to the VM process on the host, or hypervisor hijack, or anything of the same level.
The second way is what "vendor security flaws" are about. If the VM implementation is secure, then it ought to prevent such occurrences.
Firewalls act on the network side of things, so that is relevant for the first way only. However, if you are working with potentially hostile VM, then you must, indeed, do something about network-based attacks, and that may involve firewalls.
In a typical VM, the host provides network services to the guest. These services are configurable. For instance, if you look at what Virtualbox provides, then the guest may:
- have no network at all (the VM engine does not provide the guest with a virtual network interface);
- have a network interface linked with other VM under the same engine, but separate from the actual Internet;
- have a network interface linked with other VM and with the host, but otherwise separate from the Internet;
- have a network interface that the host sees, and for which the host provides NAT service (but this does not correspond to an actual ethernet card on the host).
- have a bridged network interface, allowing the VM to send and receive ethernet frames as if it was another physical machine connected to the LAN.
In the first two cases, the VM cannot talk to the host and that's final. In the cases 3 and 5, the VM can talk to the host through what the host sees as a network card (a new, software-based card in case 3; its actual physical card in case 5). In case 4, the host OS does not see the packets from the guest as packets; they are array of bytes in the VM engine process, but that process translates them as connections to other machines, which may be the host itself.
Firewalls have nothing to do with cases 1 and 2. A firewall may work with cases 3 and 5, albeit on distinct ethernet interfaces; beware that in those cases the hostile guest sends arbitrary ethernet frames, which may not necessarily show up on the link as relevant to the IP address you believe the guest should use. You should handle these situations in the same way as you would for an hostile machine linked to the LAN -- if you prefer, assume that your host is on an open WiFi in a fast food restaurant. For case 4, firewalls are irrelevant, because any connection to either the host or any other machine will appear to the host OS to come from the VM engine process itself.
The above is about what happens with Virtualbox; details may vary with other virtualization solutions.