[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 07 Oct 2020 10:32:05 +0000
From: caveman رجل الكهف <toraboracaveman@...tonmail.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: Re: [CVE-2019-14899] Inferring and hijacking VPN-tunneled TCP connections.
hi. following this:
https://seclists.org/oss-sec/2019/q4/122
i think using rp filtering won't be a neat
solution as it is technically incorrect in my
view. my reason is as follows:
- rp filtering assumes that my path to reach
others is also the path that others would
use to reach me.
that assumption is either false, or
unsubstantiated. hence, either way, there is no
reason to assume that it is true (occam's razor).
even if it is usually true, there is no reason why
this is always true, and there are cases where
this can be false.
in fact, cases exist where this is not true. e.g.
a linux box in a LAN with 2 gateways can itself
choose a different default gateway than the one
the network uses to send it packets.
therefore i think using rp filtering is a dirty
hack that is going to create another problem.
in my view, the real problem is that while vpns
are offering a kind of partitioning over the wire,
such partitioning is lost when it comes to
in-kernel connection states.
therefore, i suggest the real fix is to export
vpn's partitioning into the connection states
table by using some in-kernel tags, as follows:
- packets entering a linux box from any
interface, will inherit such specified tags
from the connection.
- the connection states table will have an
extra "tag" column that will store such
tag.
- connection states are invisible from each
other if they do not have the same tag.
- for backwards compatibility, all interfaces
will use "default" tag. so, by default,
everything feels normal.
- for wireguard, it may use the added API to
set a different tag for its packets, such as
"wireguard". the user could also manually
set other tags by `wg set states-tag newtag`
if they want to have different states
partitions across different wireguard
tunnels.
this way, in the same way that the vpn paritions
packets on the wire, connection states with
different tags will remain invisible from each
other.
in a sense similar to how VLAN IDs create the
effect of separate physical switches using the
same physical switch. not an accurate analogy,
but i thought it may help. VLANs also communicate
their IDs over trunk links (so the analogy is not
too bad i guess).
regards,
cm
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
