iptables fails to parse "-i +" correctly

Bug #2033663 reported by Thomas Sthlm
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
iptables
Unknown
Unknown
iptables (Ubuntu)
In Progress
Undecided
Unassigned
iptables-persistent (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

I recently started to use Ubuntu 22.04 LTS on a server and created a simple ipables firewall for it.
(For Ubuntu 20.04 that I have used before, the below seems fine.)

lsb_release -rd
Description: Ubuntu 22.04.2 LTS
Release: 22.04

# apt-cache policy iptables-persistent
iptables-persistent:
  Installed: 1.0.16
  Candidate: 1.0.16
  Version table:
 *** 1.0.16 500
        500 http://se.archive.ubuntu.com/ubuntu jammy/universe amd64 Packages
        100 /var/lib/dpkg/status

# apt-cache policy iptables
iptables:
  Installed: 1.8.7-1ubuntu5.1
  Candidate: 1.8.7-1ubuntu5.1
  Version table:
 *** 1.8.7-1ubuntu5.1 500
        500 http://se.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     1.8.7-1ubuntu5 500
        500 http://se.archive.ubuntu.com/ubuntu jammy/main amd64 Packages

--------------------------------------------------
ISSUE:
If I enter a simple iptables rule that uses the "-i +" input interface wildcard thing in it, but note that I don't give any interface namestring "prefix" before the "+" - for example:
iptables -A INPUT -i + -d 192.168.1.10 -j DROP
iptables -A INPUT -i + -d 192.168.1.11 -j DROP
iptables -A INPUT -i + -d 192.168.1.12 -j DROP

Then printouts of both iptables-save and iptables -L -n -v will show weird non-ascii/non-printable characters where the interfaces are supposed to be printed!
The result for my rule example above shows as:
-A INPUT -d 192.168.80.10/32 -i ˬP
+ -j DROP
-A INPUT -d 192.168.80.11/32 -i À¨P�+ -j DROP
-A INPUT -d 192.168.80.12/32 -i ˬP + -j DROP
(The garbage chars are in hex \c0\a8\50\0a, \c0\a8\50\0b, \c0\a8\50\0c respectively. Note the \0a newline char breaking up the printout into two lines for the first rule.)

The garbage characters makes
"iptables-save > /etc/iptables/rules.v4"
followed up with
"iptables-restore < /etc/iptables/rules.v4"
to fail!

I discovered that if the rule also includes some "protocol" constraints like "-p tcp -m tcp --dport 123" then iptables parses/prints the rule seemingly ok, but for "simpler" rules iptables gets confused.

Revision history for this message
Oibaf (oibaf) wrote (last edit ):

Hi, I am not a maintainer, but maybe I can help you a bit.

Can you search in iptables bugzilla if your issue was already reported (either still open or already closed)? https://bugzilla.netfilter.org/query.cgi

Also, you may have a look at iptables source ( https://git.netfilter.org/iptables/log/ ) if you find a related fix after 1.8.7 commit release (happened in 2021-01-15).

If not, report it at: https://bugzilla.netfilter.org/enter_bug.cgi?product=iptables

Thanks.

Revision history for this message
Thomas Sthlm (thomas-sthlm) wrote :

@oibaf
Thanx,

Didn't search super-much but I did find a somewhat similar issue:
https://bugzilla.netfilter.org/show_bug.cgi?id=1085

That bug was about letting through -i interface strings with typos/not allowed characters when using the + wildcard, for example: iptables -A INPUT -i "et h+" ...

They have apparently been into that code before to bugfix, but not tested the case with + only / "null-string" interface name as prefix before the + wildcard.

Guess that I will report it to netfilter's bugzilla.

Revision history for this message
Oibaf (oibaf) wrote :

OK, great finding, when you file a bug on netfilter bugzilla report the link here, thanks.

Revision history for this message
Thomas Sthlm (thomas-sthlm) wrote :

@oibaf
Bug now filed with netfilter:
https://bugzilla.netfilter.org/show_bug.cgi?id=1702

Revision history for this message
Oibaf (oibaf) wrote :

Great, if you also want to test newer iptables and iptables-persistent, I backported the versions from Ubuntu mantic (latest development release) to 22.04, you can find them here (ignore the PPA description):
https://launchpad.net/~oibaf/+archive/ubuntu/gallium-nine

Revision history for this message
Oibaf (oibaf) wrote :

It looks it was a problem in iptables, not iptables-persistent.

Changed in iptables-persistent (Ubuntu):
status: New → Invalid
Revision history for this message
Oibaf (oibaf) wrote :

Fixed upstream after 1.8.9.

Changed in iptables (Ubuntu):
status: New → In Progress
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.