On Wednesday 2022-03-30 17:58, Phil Sutter wrote: >When parsing (parts of) a port spec, if it doesn't start with a digit, >try to find the largest substring getservbyname() accepts. > -p tcp -j DNAT --to-destination 1.1.1.1:1000-2000/65536;;FAIL > -p tcp -j DNAT --to-destination 1.1.1.1:ssh;-p tcp -j DNAT --to-destination 1.1.1.1:22;OK > -p tcp -j DNAT --to-destination 1.1.1.1:ftp-data;-p tcp -j DNAT --to-destination 1.1.1.1:20;OK >+-p tcp -j DNAT --to-destination 1.1.1.1:ftp-data-ssh;-p tcp -j DNAT --to-destination 1.1.1.1:20-22;OK >+-p tcp -j DNAT --to-destination 1.1.1.1:echo-ftp-data;-p tcp -j DNAT --to-destination 1.1.1.1:7-20;OK >+-p tcp -j DNAT --to-destination 1.1.1.1:ftp-data-ssh/echo;-p tcp -j DNAT --to-destination 1.1.1.1:20-22/7;OK >+-p tcp -j DNAT --to-destination 1.1.1.1:echo-ftp-data/ssh;-p tcp -j DNAT --to-destination 1.1.1.1:7-20/22;OK > -j DNAT;;FAIL This looks dangerous. It is why I originally never allowed service names in port ranges that use dash as the range character. a-b-c could mean a..b-c today, and could mean a-b..c tomorrow, either because someone managed to inject a-b into the service list. The "solution" would be to use : as the range character, but that would require a new --dport option for reasons of command-line compatibility.
