3 ms·

What are arguments against user-space TCP?

jeffbee 4y ago
It doesn't work out-of-the-box with any existing software, so it only applies to things you are building from scratch, or that are structured in such a way that adding an alternate network mode, or that would work with a dynamic library that shims the entire sockets API. Your user-mode stack won't be observable by any existing monitoring tools. Also, your process needs to execute with CAP_NET_RAW.
chatmasta 4y ago
One argument is that it requires building on top of a raw socket, which can open you to all sorts of ancient vulnerabilities that have been patched in the battle-tested code running in the kernel, e.g. this recent ICMP remote code execution vulnerability [0] ("An attacker could send a low-level protocol error containing a fragmented IP packet inside another ICMP packet in its header to the target machine. To trigger the vulnerable code path, an application on the target must be bound to a raw socket") [1]. [0] Discussion: https://old.reddit.com/r/netsec/comments/11s80zo/cve202323415_icmp_remote_code_execution/ https://old.reddit.com/r/netsec/comments/11s80zo/cve20232341... [1] Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23415 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...
- ratorx 4y ago
  If you are able, could you explain this in more detail? I find the description unparseable. Reading the words I do understand, the raw socket aspect seems to be irrelevant right? The vulnerable code would be the the parser that incorrectly runs code based on invalid input? It might require raw socket to trigger the vulnerability, but perhaps it would not exist if it was not written in kernel C but rather in user space garbage collected code with a good type system (not sure what the vulnerability actually is).
- harry8 4y ago
  TAPIF=tap0; BR=br0; LOCAL_IP=192.whatever; MASK=24; REAL_IP=eth0 sudo ip tuntap add dev $TAPIF mode tap user $(whoami) sudo ip addr add $LOCAL_IP/$MASK dev $TAPIF sudo ip link set $TAPIF up sudo ip link add $BR type bridge sudo ip link set $TAPIF master $BR sudo ip link set $REAL_IF up sudo ip link set $REAL_IF master $BR Means you don't have to add iptables rules to get the kernel tcp/ip stack to ignore packets meant for your program specific user level stack. Raw sockets require special permissions. sudo setcap cap_net_admin,cap_net_raw=eip my_prog_bin ping needs this, for example. getcap $(which ping) /bin/ping = cap_net_raw+ep But this underscores the real issue we face because enough people won't care about your security if its convenient for their programming that it isn't a barrier to acceptance. You have to get the kernel to do things, probably using root privs, to get out of the way of your programs ip traffic now. The kernel will jump in and reject a syn or synack response meant for your program and its user level stack. You don't have do anything like that if your program calls socket() to get an fd and goes on in the usual manner from there.
ilyt 4y ago
Normally if app opens a port it is not allowed to by firewall or application permissions it will just get error, with RAW sockets kernel would need to parse packet before deciding that. For example normally you will get permission denied when you try to listen on sub-1024 port on normal user. I'd also imagine if kernel is doing any kind of connection tracking (so really anything with firewall), it would be more optimal to have that connection tracked in kernel vs decoding it and adding to conntrack table. I guess some kind of half-RAW could be done in place, like say a socket where you define protocol and port but handle actual packets in userspace ?

It doesn't work out-of-the-box with any existing software, so it only applies to things you are building from scratch, or that are structured in such a way that adding an alternate network mode, or that would work with a dynamic library that shims the entire sockets API. Your user-mode stack won't be observable by any existing monitoring tools. Also, your process needs to execute with CAP_NET_RAW.

chatmasta 4y ago

One argument is that it requires building on top of a raw socket, which can open you to all sorts of ancient vulnerabilities that have been patched in the battle-tested code running in the kernel, e.g. this recent ICMP remote code execution vulnerability [0] ("An attacker could send a low-level protocol error containing a fragmented IP packet inside another ICMP packet in its header to the target machine. To trigger the vulnerable code path, an application on the target must be bound to a raw socket") [1]. [0] Discussion: https://old.reddit.com/r/netsec/comments/11s80zo/cve202323415_icmp_remote_code_execution/ https://old.reddit.com/r/netsec/comments/11s80zo/cve20232341... [1] Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-23415 https://msrc.microsoft.com/update-guide/vulnerability/CVE-20...

ratorx 4y ago
If you are able, could you explain this in more detail? I find the description unparseable. Reading the words I do understand, the raw socket aspect seems to be irrelevant right? The vulnerable code would be the the parser that incorrectly runs code based on invalid input? It might require raw socket to trigger the vulnerability, but perhaps it would not exist if it was not written in kernel C but rather in user space garbage collected code with a good type system (not sure what the vulnerability actually is).
harry8 4y ago
TAPIF=tap0; BR=br0; LOCAL_IP=192.whatever; MASK=24; REAL_IP=eth0 sudo ip tuntap add dev $TAPIF mode tap user $(whoami) sudo ip addr add $LOCAL_IP/$MASK dev $TAPIF sudo ip link set $TAPIF up sudo ip link add $BR type bridge sudo ip link set $TAPIF master $BR sudo ip link set $REAL_IF up sudo ip link set $REAL_IF master $BR Means you don't have to add iptables rules to get the kernel tcp/ip stack to ignore packets meant for your program specific user level stack. Raw sockets require special permissions. sudo setcap cap_net_admin,cap_net_raw=eip my_prog_bin ping needs this, for example. getcap $(which ping) /bin/ping = cap_net_raw+ep But this underscores the real issue we face because enough people won't care about your security if its convenient for their programming that it isn't a barrier to acceptance. You have to get the kernel to do things, probably using root privs, to get out of the way of your programs ip traffic now. The kernel will jump in and reject a syn or synack response meant for your program and its user level stack. You don't have do anything like that if your program calls socket() to get an fd and goes on in the usual manner from there.

ilyt 4y ago

Normally if app opens a port it is not allowed to by firewall or application permissions it will just get error, with RAW sockets kernel would need to parse packet before deciding that. For example normally you will get permission denied when you try to listen on sub-1024 port on normal user. I'd also imagine if kernel is doing any kind of connection tracking (so really anything with firewall), it would be more optimal to have that connection tracked in kernel vs decoding it and adding to conntrack table. I guess some kind of half-RAW could be done in place, like say a socket where you define protocol and port but handle actual packets in userspace ?