search

mirage / qubes-mirage-firewall

A Mirage firewall VM for QubesOS
BSD 2-Clause "Simplified" License
211 stars 28 forks source link

fragmented ip handling #73

Closed xaki23 closed 4 years ago

xaki23 commented 5 years ago

it seems there are still some basic problems with the mfw IP stack. todays variant: fragmented packets.

the tests are against a 20190727 (today) build in templated mode. the test commands are run in a (fedora-29) vm below the mirage-vm. the log lines are from mfw-console-logs in dom0. i am not pasting the hex dumps because afaict they dont matter and are easy to reproduce if anyone cares...

$ traceroute -U 8.8.8.8 2000

2019-07-27 18:33:40 -00:00: WRN [client_net] Ignored unknown IPv4 message: Failed to parse UDP packet: UDP header claimed a payload longer than the supplied buffer: 1972 vs 1480. 2019-07-27 18:33:40 -00:00: WRN [client_net] Ignored unknown IPv4 message: Failed to parse UDP packet: UDP header claimed a payload longer than the supplied buffer: 17469 vs 500.

the second line is almost more scary, because that means it tries to parse the payload/data of the second fragment as a header.

when using icmp instead (traceroute with -I instead of -U or "ping -s 2000 8.8.8.8") the failure pattern is mostly the same, except it doesnt complain about the first fragment with either a 20190727 nor 20190226 (pre #31) build.

and proactively pinging @yomimono on this.

note this is the other direction compared to #31, it already falls on its face while the pakets are coming from the inside.

xaki23 commented 5 years ago

also pinging @hannesm because of https://github.com/mirage/mirage-tcpip/pull/375

hannesm commented 5 years ago

hi @xaki23, thanks for your report. unfortunately I don't have a qubesos machine at my hands, so I can't reproduce or fix this issue. from reading the source code, here are my observations:

from my understanding, the flow for packets goes through: Client_net.add_vif calling Netback.listen, parsing received ethernet frames, and then depending on the ethertype input_arp or input_ipv4 in the same module.

input_ipv4 then uses Nat_packet.of_ipv4_packet to parse the IPv4 payload, and could benefit from using a Fragments.t cache (https://github.com/mirage/mirage-tcpip/blob/master/src/ipv4/fragments.mli) before that (which offers a single function process, taking a cache, a timestamp, an IPv4 packet and its payload, and returning optionally an IPv4 packet and its payload). It looks to me that atm nothing takes a look at the offset and more fragments bits (which the Fragments module is for). the cache should be kept at a vif-local data structure (using some reasonable maximum capacity -- MirageOS' IPv4 host stack uses 256kB (in Static_ipv4.connect), and has a limit of 16 IPv4 fragments where the delta between first and last must not exceed 10 seconds).

xaki23 commented 5 years ago

hi @xaki23, thanks for your report. unfortunately I don't have a qubesos machine at my hands, so I can't reproduce or fix this issue. from reading the source code, here are my observations:

fortunately, that excuse is of limited validity when dealing with organized virtualization fanatics. :P

see mail/irc for how to access your dedicated personal qubes-mirage-firewall build-and-test env!

hannesm commented 5 years ago

just fwiw, thanks to @xaki23 https://github.com/hannesm/mirage-nat/tree/fragment and https://github.com/hannesm/qubes-mirage-firewall/tree/fragmentation allow fragmentation (in a rather poor / hackish) way -- I suspect for proper support there should be some API changes in mirage-nat (to avoid reparsing packets) ; and things like mtu being exposed from "class type interface"