[Security] caclmgrd always allows all control plane traffic which arrives with TTL < 2

[Zmegolaz]

Description

There are iptables rules that permits tools like tcptraceroute to work, by allowing incoming packets with a TTL (or hop limit) of 1 or lower. This rule only looks at TTL, which the source can control and set to a value which will be decremented to 1 by intermediate routers by the time it reaches the control plane filters. This makes it trivial for an attacker to bypass all filters.

iptables -A INPUT -m ttl --ttl-lt 2 -j ACCEPT
ip6tables -A INPUT -p tcp -m hl --hl-lt 2 -j ACCEPT

Steps to reproduce the issue:

1. Use SONiC and apply control plane ACLs

Describe the results you received:

Packets with TTL = 1 are permitted:

$ nc 172.18.0.154 22 -M 2
^C
$ nc 172.18.0.154 22 -M 1
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
^C

Works with one router hop as well:

$ nc 172.18.0.154 22 -M 1 -v
nc: connect to 172.18.0.154 port 22 (tcp) failed: No route to host
$ nc 172.18.0.154 22 -M 2 -v
Connection to 172.18.0.154 22 port [tcp/ssh] succeeded!
SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2
^C
$ nc 172.18.0.154 22 -M 3 -v
^C

Describe the results you expected:

No connection, regardless of TTL. In my opinion there shouldn't be any special rule for TCP traceroute. If someone is not permitted to connect to a specific port, then that someone shouldn't receive any reply at all with a TCP traceroute to that port. Legit troubleshooters will match the "permit SSH" rule when doing a TCP traceroute to port 22, for example.

Output of show version:

SONiC Software Version: SONiC.202012-kamel.33-8c613addb
Distribution: Debian 10.11
Kernel: 4.19.0-12-2-amd64
Build commit: 8c613addb
Build date: Sun Jan 30 00:29:18 UTC 2022
Built by: AzDevOps@sonicbldw00000T

Platform: x86_64-mlnx_msn2700-r0
HwSKU: Mellanox-SN2700-Kamel
ASIC: mellanox
ASIC Count: 1
Serial Number: MT2012X27569
Uptime: 09:53:04 up 2 days, 10:52,  1 user,  load average: 0.45, 1.11, 1.24

Docker images:
REPOSITORY                    TAG                         IMAGE ID            SIZE
docker-sonic-mgmt-framework   202012-kamel.33-8c613addb   31838567dc59        787MB
docker-sonic-mgmt-framework   latest                      31838567dc59        787MB
docker-platform-monitor       202012-kamel.33-8c613addb   9108e0c69405        667MB
docker-platform-monitor       latest                      9108e0c69405        667MB
docker-orchagent              202012-kamel.33-8c613addb   4582c69c4e7d        403MB
docker-orchagent              latest                      4582c69c4e7d        403MB
docker-sonic-telemetry        202012-kamel.33-8c613addb   9e4894867e98        463MB
docker-sonic-telemetry        latest                      9e4894867e98        463MB
docker-snmp                   202012-kamel.33-8c613addb   7da6c8b805c8        416MB
docker-snmp                   latest                      7da6c8b805c8        416MB
docker-fpm-frr                202012-kamel.33-8c613addb   98df8e9f723c        403MB
docker-fpm-frr                latest                      98df8e9f723c        403MB
docker-teamd                  202012-kamel.33-8c613addb   e52e7287835f        384MB
docker-teamd                  latest                      e52e7287835f        384MB
docker-nat                    202012-kamel.33-8c613addb   6fdff4dca514        387MB
docker-nat                    latest                      6fdff4dca514        387MB
docker-lldp                   202012-kamel.33-8c613addb   f90c365eba44        414MB
docker-lldp                   latest                      f90c365eba44        414MB
docker-sflow                  202012-kamel.33-8c613addb   e89c861139eb        385MB
docker-sflow                  latest                      e89c861139eb        385MB
docker-mux                    202012-kamel.33-8c613addb   b463a884300d        426MB
docker-mux                    latest                      b463a884300d        426MB
docker-dhcp-relay             202012-kamel.33-8c613addb   d64845ec8107        387MB
docker-dhcp-relay             latest                      d64845ec8107        387MB
docker-database               202012-kamel.33-8c613addb   47bffcab8c8e        374MB
docker-database               latest                      47bffcab8c8e        374MB
docker-router-advertiser      202012-kamel.33-8c613addb   febd08cc1e7a        374MB
docker-router-advertiser      latest                      febd08cc1e7a        374MB
docker-syncd-mlnx             202012-kamel.33-8c613addb   7e57d86864ae        952MB
docker-syncd-mlnx             latest                      7e57d86864ae        952MB

Additional information you deem important (e.g. issue happens only occasionally):

Control plane ACL used:

{
        "ACL_RULE": {
                "ACL-CTRLPLANE-SSH-V4|PERMIT-BLACKBOX": {
                        "IP_TYPE": "ipv4any",
                        "SRC_IP": "172.18.0.251/32",
                        "PACKET_ACTION": "ACCEPT",
                        "PRIORITY": "1000"
                }
        },
        "ACL_TABLE": {
                "ACL-CTRLPLANE-SSH-V4": {
                        "policy_desc": "ACL for control plane, SSH specific IPv4",
                        "services": ["SSH"],
                        "type": "CTRLPLANE"
                }
        }
}

[zhangyanzhao]

@prsunny will work with @bluecmd on the fix.

[prsunny]

Question: This rule is currently after all the IP2ME drop rules, so how is this impacting?

[bluecmd]

Question: This rule is currently after all the IP2ME drop rules, so how is this impacting?

Correct, this is in the best case less severe than e.g. #9916. But it's still troublesome.

For scenarios without any custom control plane ACLs installed this rule does nothing, so there is no issue.

However the final DROP that is enabled when you install custom control plane ACLs are after this ACCEPT - so essentially this allows any explicitly undefined traffic to be accepted.

Put in another way, for an attacker it is if the final DROP wasn't there.

This fact also of course compounds with the IP2ME logic producing an ineffective result (for uninitiated readers; see #9826) for a lot of configurations resulting in that it is quite easy to generate traffic that is not blocked by any previous rule and then finally be accepted by this TTL one.

https://github.com/Azure/sonic-buildimage/blob/d5404928345ba2690d8f6cce0095f57d0a89c671/src/sonic-host-services/scripts/caclmgrd#L629-L638