Multi-Networked BSD and Linux Systems Expose Private Interface Networked Services using Network Interface Traversing due to Weak Host Model

StenoPlasma

StenoPlasma

Looking for any comments from the community on this issue. After discovering this back in 2012 I reported to a few major Linux distributions but was told there was nothing they could do about it due to the Weak Host Model that is the default for most Linux/BSD based systems and that their only solution was to set up very specific firewall rules (which isn't always done now). I decided to reach out to this community now.

TITLE: Multi-homed (Multi-networked) BSD and Linux Systems Expose Private Interface Networked Services using Network Interface Traversing Without the use of Forwarding due to Weak Host Model

DISCUSSION:
Multi-homed systems that have private services listening on private network interfaces are vulnerable to a network interface traversing vulnerability. This affects all modern BSD and Linux distributions and hardware devices that use the Weak Host Model by default. The issue comes from the way that the stack provides networked services and routes traffic destined for those services once it is already on the host. Attackers that have WAN network segment access can force victim servers to provide access to protected and segmented services (Any type of service, TCP, UDP - Examples: HTTP, SSH, TFTP). This type of attack will allow attackers to gain access to private services running only on back-end private network interfaces. This vulnerability would leave many Internet facing customers/administrators wide open to attacks on services that were believed to be protected by the separation of networks on different network interfaces. Even if forwarding is disabled on the host and firewall rule sets, the victim host still forwards to other network interfaces on the same device. It must be noted that if forwarding is disabled on the host, the traffic will not traverse to the back-end private networks, just to the private services running on the private interfaces. The basic example victim server configuration is as follows:

SAMPLE VICTIM CONFIGURATION:

Victim Linux/BSD Firewall on Internet: DMZ Host/Firewall with with 3 network interfaces.

Network Interfaces:
eth0: Internet (10.0.1.200 on the 10.0.1.0/24 WAN) 10.0.1.200 is not listening on any TCP/UDP ports.
eth1: DMZ (172.16.0.1 on the 172.16.0.0/24 LAN) 172.16.0.1 is not listening on any TCP/UDP ports.
eth2: Internal Network (192.168.1.1 on the 192.168.1.0/24 LAN) 192.168.1.1 is listening on TCP port 443 for the Firewall's administration page and TCP port 80 for the unprotected Wiki.

Firewall:
INPUT Chain has only allow 80 and 443 (If you block inbound 80/443 at the WAN, the traffic will obviously not traverse from the outside. This is what the Linux distributions recommended as their only fix to this issue. Problem is, what if you need 80/443 on the external interface as well?)
INPUT Chain can have block all traffic on Network Interface Cards eth1 and eth2 and this attack will still work
FORWARD Chain is DROP

Proc IPv4 Settings:
IP Forward is Off


Please let me know what you all think and if this is the right forum for this post. This isn't a theoretical issue as I have a fully working POC.

-StenoPlasma
 
Well, I'd appreciate if you could elaborate a bit more, so less-skilled people like me can understand what the problem is and how it works that it is allegedly possible to bypass all sorts of firewalls, as you say?
 
StenoPlasma said:
After discovering this back in 2012
Click to expand...
This has been a known issue for a lot longer than that. There are a lot more known problems with the TCP/IP stack. It's a 50 year old protocol that was never designed with today's security requirements in mind.

StenoPlasma said:
and that their only solution was to set up very specific firewall rules
Click to expand...
You're going to get the same response here.

StenoPlasma said:
Even if forwarding is disabled on the host and firewall rule sets, the victim host still forwards to other network interfaces on the same device.
Click to expand...
Nothing is being forwarded here. The IP address is never really tied to the interface, it's on the host itself. That interface information is lost when a packet traverses the stack so there's no way for the receiving process to know from which interface it came. Thus the process will allow access to its bound IP address, even if that packet came in on a different interface. Because this requires spoofing of the destination IP address careful firewall rules will easily mitigate this risk.

StenoPlasma said:
Please let me know what you all think and if this is the right forum for this post.
Click to expand...
This is a user support forum. Most users probably don't even know what you're talking about. There are very few FreeBSD developers here, try the mailing lists.
 
Oh, after a little bit of research:
Code: 
root@molly:~ # sysctl -d net.inet.ip.check_interface
net.inet.ip.check_interface: Verify packet arrives on correct interface
root@molly:~ # sysctl net.inet.ip.check_interface
net.inet.ip.check_interface: 0
It's set to 0 (weak host model) by default.

As far as I've been able to find out this sysctl was introduced some time during release 4 in 2001.
 
I think your example is flawed. If you set up a DMZ server, then you must configure proper firewall rules, of course, so you can control exactly what packets are allowed to be received and be sent on which interfaces. Actually this isn’t very difficult if you have a little knowledge about how TCP/IP works. If you don’t, you should consult someone who does, or otherwise don’t try to install a DMZ server. The default configuration of the OS won’t help you here, because the actual firewall rules depend on the particular needs in each case (a DMZ can be designed in very different ways).

Apart from that, the attack described in the first post can be mitigated by setting the sysctl net.inet.ip.check_interface=1. There are also several other sysctl variables that you might want to have a close look at, if you’re going to expose a server to the internet.

TL;DR: “UNIX is not supposed to prevent you from shooting yourself in the foot.”
 
Love just grepping through commit messages :)
Code: 
commit 4bc37f9836fb193af285f8712dd39bcd6e215c32
Author: Maxim Konovalov <maxim@FreeBSD.org>
Date:   Fri Sep 24 12:18:40 2004 +0000

    o Turn net.inet.ip.check_interface sysctl off by default.

    When net.inet.ip.check_interface was MFCed to RELENG_4 3+ years ago in
    rev. 1.130.2.17 ip_input.c it was 1 by default but shortly changed to
    0 (accidently?) in rev. 1.130.2.20 in RELENG_4 only.  Among with the
    fact this knob is not documented it breaks POLA especially in bridge
    environment.

    OK'ed by:       andre
    Reviewed by:    -current
Code: 
commit b3e95d4ed09e497b778584ac12ceea158c504e72
Author: Jonathan Lemon <jlemon@FreeBSD.org>
Date:   Fri Mar 2 20:54:03 2001 +0000

    Add a new sysctl net.inet.ip.check_interface, which will verify that
    an incoming packet arrivees on an interface that has an address matching
    the packet's address.  This is turned on by default.

So, the issue was already known a full 11 years (probably more as there's likely been a lengthy discussion on how to mitigate the problem without breaking everything else in the process) before the OP "discovered" it. I'm going to assume "discovered" is lost in translation here and the OP actually means that the OP wasn't aware of it until 2012.
 
You must log in or register to reply here.
Back
Top