2 ms·

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 battl

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.

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.