Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-05-31 Thread Alberto Molina Coballes
This bug has been fixed upstream and it will go in 1.8.5 release.

Thanks for reporting.

Alberto



Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-18 Thread Christoph Martin
Hi Alberto,
hi Jamie,

Am 17.02.20 um 18:06 schrieb Alberto Molina Coballes:
> 
> These rules were not generated by ufw. The current released version of
> ufw does not do any management of the nat table. Furthermore,
> iptables-restore rules in /etc/ufw/*rules do not contain any '-F's.
> 

I made these rules myself and had to add the -F's because ufw does not
flush the nat table on reload and I would otherwise end up with
duplicate nat rules.

> The man page does *not* document use of -F in these files and instead
> has examples like:
> 
>   *nat
>   :POSTROUTING ACCEPT [0:0]
>   -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
>   COMMIT
> 
> So I suspect what happened is the reporter used this mechanism to
> customize the firewall and accidentally added the second, errant -F.
> [/quote]

> After some test, it seems that the problem is related to the flush of
> the rules after adding some of them (do you really want to do that?),
> because the next ruleset works well:
>

The second -F is for the POSTROUTING rules. The difference is here:

*nat
-F PREROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-F POSTROUTING
-A POSTROUTING -o eth0 -p tcp --sport 222 -j SNAT --to-source 10.10.10.10
COMMIT

results in a crash.

*nat
-F PREROUTING
-F POSTROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-A POSTROUTING -o eth0 -p tcp --sport 222 -j SNAT --to-source 10.10.10.10
COMMIT

does not crash.

> Because the default iptables-restore behaviour is to flush (delete)
> all previous contents of the respective tables.

If I remove the -F's, every 'ufw reload' will add another set of the
POSTROUTING and PREROUTING rules.

> 
> I think you can workaround the bug rewriting your rules with special
> care in the inclusion of '-F' rules.

The workaround is to have both -F rules at the beginning. But I can't
omit them.

Christoph



signature.asc
Description: OpenPGP digital signature


Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-17 Thread Alberto Molina Coballes
Control: forwarded -1 https://bugzilla.netfilter.org/show_bug.cgi?id=1407
Control: severity -1 normal

Hi Christoph,

I'm quoting a email from Jamie Strandboge, who is both the
maintainer in Debian and the creator of ufw, and has kindly replied my
question about this bug:

[quote]
...

These rules were not generated by ufw. The current released version of
ufw does not do any management of the nat table. Furthermore,
iptables-restore rules in /etc/ufw/*rules do not contain any '-F's.

...

Now, the 'ufw-framework' man page documents how someone can adjust
/etc/ufw/{before,after}{,6}.rules files to customize the firewall with
iptables-restore directives for things that the ufw cli command does not
expose and it is not uncommon for people to add things to other tables.
The man page does *not* document use of -F in these files and instead
has examples like:

  *nat
  :POSTROUTING ACCEPT [0:0]
  -A POSTROUTING -s 10.0.0.0/8 -o eth0 -j MASQUERADE
  COMMIT

So I suspect what happened is the reporter used this mechanism to
customize the firewall and accidentally added the second, errant -F.
[/quote]

In any case, the bug exists and it has been reported upstream.

After some test, it seems that the problem is related to the flush of
the rules after adding some of them (do you really want to do that?),
because the next ruleset works well:

*nat
-F PREROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-F POSTROUTING
COMMIT

And the same result will be obtained with:

*nat
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
COMMIT

Because the default iptables-restore behaviour is to flush (delete)
all previous contents of the respective tables.

I think you can workaround the bug rewriting your rules with special
care in the inclusion of '-F' rules.

I think it is correct that the error was initially reported with grave
severity, but after this analysis I think it is appropriate to lower
the severity to normal unless the segfault is discovered in a more
general case.

Regards,

Alberto



Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-13 Thread Alberto Molina Coballes
On Thu, Feb 13, 2020 at 11:05:13AM +0100, Christoph Martin wrote:
> 
> I choose the grave severity because the bug makes a reload of ufw fail
> and then the firewall is off !
> 

Yes, I agree with you that it's a serious situation, but we have to
determine if it's a general case of iptables (which it seems it's not)
or if it's a problem with a specific ruleset. We need to determine if
it's a grave severity in the iptables package in the stable branch.

I'll contact with ufw maintainers to obtain more info.

Thanks!

Alberto



Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-13 Thread Christoph Martin
Hil Alberto,

Am 13.02.20 um 10:11 schrieb Alberto Molina Coballes:
> 
> Is this ruleset a real one obtained from ufw? I ask because the next one
> doesn't result in segfault:
> 
> *nat
> -F PREROUTING
> -F POSTROUTING
> -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
> COMMIT
> 
> I don't understand the rule "-F PREROUTING" after a "-A ..." one. It
> seems that the segfault happens in this specific case (it's a bug of
> course, but not a bug with grave severity).

Actually I stripped it down to these lines, because this is the minimum
set of rules which makes it crash.

In my UFW before.rules files I have several PREROUTING and POSTROUTING
rules with a -F before the -A rules block in the nat table.

Christoph



signature.asc
Description: OpenPGP digital signature


Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-13 Thread Christoph Martin
Hi Alberto,

Am 13.02.20 um 10:11 schrieb Alberto Molina Coballes:
> I don't understand the rule "-F PREROUTING" after a "-A ..." one. It
> seems that the segfault happens in this specific case (it's a bug of
> course, but not a bug with grave severity).

I choose the grave severity because the bug makes a reload of ufw fail
and then the firewall is off !

Christoph



signature.asc
Description: OpenPGP digital signature


Bug#950535: [pkg-netfilter-team] Bug#950535: iptables-restore segfaults on nat table

2020-02-13 Thread Alberto Molina Coballes
Control: tag -1 moreinfo

Hi Christoph,

Is this ruleset a real one obtained from ufw? I ask because the next one
doesn't result in segfault:

*nat
-F PREROUTING
-F POSTROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
COMMIT

I don't understand the rule "-F PREROUTING" after a "-A ..." one. It seems
that the segfault happens in this specific case (it's a bug of course, but
not a bug with grave severity).

After some tests I found this ruleset segfaults with iptables-nft-restore
in several iptables releases (1.8.2-4, 1.8.3-2~bpo10+1 and 1.8.4-2) while
iptables-legacy-restore executes as expected.

Please, provide more info or a general ruleset to inform upstream and/or
lower the severity.

Thanks for reporting!

Alberto


Bug#950535: iptables-restore segfaults on nat table

2020-02-11 Thread Bernhard Übelacker
Dear Maintainer,
I tried to collect some more information and got
the following backtrace with the restore command
from the submitter.

It looks like "expr->ops" contains a null pointer
that gets dereferenced.

Unfortunately I still see the same crash after
upgrading to the versions in backports in my test VM.

Also this crash is still visible in a minimal
Bullseye/testing VM.

Kind regards,
Bernhard


(gdb) bt
#0  0x7fd480466793 in nftnl_expr_build_payload (nlh=0x7fd47fc7a178, 
expr=0x55fe70704f40) at expr.c:210
#1  0x7fd480461783 in nftnl_rule_nlmsg_build_payload (nlh=0x7fd47fc7a178, 
r=0x55fe70705650) at rule.c:320
#2  0x55fe6e793c66 in nft_compat_rule_batch_add (h=, 
type=, flags=, seq=, 
rule=) at nft.c:2579
#3  0x55fe6e79493e in nft_action (h=0x7fff14b33560, action=0) at nft.c:2673
#4  0x55fe6e790555 in xtables_restore_parse (h=h@entry=0x7fff14b33560, 
p=p@entry=0x7fff14b33540, cb=cb@entry=0x55fe6e7b8140 , 
argc=argc@entry=1, argv=argv@entry=0x7fff14b336e8) at xtables-restore.c:143
#5  0x55fe6e790f90 in xtables_restore_main (family=2, progname=, argc=1, argv=0x7fff14b336e8) at xtables-restore.c:474
#6  0x7fd47fcf709b in __libc_start_main (main=0x55fe6e78bfb0 , 
argc=1, argv=0x7fff14b336e8, init=, fini=, 
rtld_fini=, stack_end=0x7fff14b336d8) at ../csu/libc-start.c:308
#7  0x55fe6e78bfea in _start ()

(gdb) print expr
$3 = (struct nftnl_expr *) 0x55fe70704f40

(gdb) print expr->ops
$4 = (struct expr_ops *) 0x0

(gdb) list expr.c:210
205
206 void nftnl_expr_build_payload(struct nlmsghdr *nlh, struct nftnl_expr 
*expr)
207 {
208 struct nlattr *nest;
209
210 mnl_attr_put_strz(nlh, NFTA_EXPR_NAME, expr->ops->name);
211
212 if (!expr->ops->build)
213 return;
214

https://sources.debian.org/src/libnftnl/1.1.2-2/src/expr.c/#L210

# Buster/stable amd64 qemu VM 2020-02-11


apt update
apt dist-upgrade


apt install systemd-coredump mc git fakeroot strace gdb iptables-dbgsym 
libnftnl11-dbgsym
apt build-dep iptables libnftnl11



mkdir /home/benutzer/source/libnftnl11/orig -p
cd/home/benutzer/source/libnftnl11/orig
apt source libnftnl11
cd

mkdir /home/benutzer/source/iptables/orig -p
cd/home/benutzer/source/iptables/orig
apt source iptables
cd

mkdir /home/benutzer/source/iptables/git -p
cd/home/benutzer/source/iptables/git
git clone git://git.netfilter.org/iptables
cd





iptables-restore < *nat
> -F PREROUTING
> -A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
> -F PREROUTING
> -F POSTROUTING
> COMMIT
> EOF
Speicherzugriffsfehler (Speicherabzug geschrieben)


# journalctl --no-pager
Feb 11 13:34:26 debian kernel: iptables-restor[1104]: segfault at 0 ip 
7fd480466793 sp 7fff14b30530 error 4 in 
libnftnl.so.11.0.0[7fd48045b000+17000]
Feb 11 13:34:26 debian kernel: Code: 0c 25 28 00 00 00 75 05 48 83 c4 18 c3 e8 
b5 4a ff ff 0f 1f 44 00 00 41 54 55 48 89 fd 53 48 8b 46 18 48 89 f3 be 01 00 
00 00 <48> 8b 10 e8 b5 51 ff ff 48 8b 43 18 48 83 78 30 00 74 32 48 89 ef
Feb 11 13:34:26 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Feb 11 13:34:26 debian systemd[1]: Started Process Core Dump (PID 1105/UID 0).
Feb 11 13:34:26 debian systemd-coredump[1106]: Process 1104 (iptables-restor) 
of user 0 dumped core.
   
   Stack trace of thread 1104:
   #0  0x7fd480466793 n/a 
(libnftnl.so.11)
   #1  0x7fd480461783 
nftnl_rule_nlmsg_build_payload (libnftnl.so.11)
   #2  0x55fe6e79493e n/a 
(xtables-nft-multi)
   #3  0x55fe6e790555 n/a 
(xtables-nft-multi)
   #4  0x55fe6e790f90 n/a 
(xtables-nft-multi)
   #5  0x7fd47fcf709b 
__libc_start_main (libc.so.6)
   #6  0x55fe6e78bfea n/a 
(xtables-nft-multi)
Feb 11 13:34:26 debian systemd[1]: systemd-coredump@0-1105-0.service: Succeeded.



root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2020-02-11 13:34:26 CET1104 0 0  11 present   
/usr/sbin/xtables-nft-multi





root@debian:~# coredumpctl gdb 1104
   PID: 1104 (iptables-restor)
   UID: 0 (root)
   GID: 0 (root)
Signal: 11 (SEGV)
 Timestamp: Tue 2020-02-11 13:34:26 CET (2min 44s ago)
  Command Line: iptables-restore
Executable: /usr/sbin/xtables-nft-multi
 Control Group: /user.slice/user-1000.slice/session-1.scope
  Unit: session-1.scope
 Slice: user-1000.slice
   Session: 1
 Owner UID: 1000 (benutzer)
   Boot ID: 07b3a6dc70ab428eb2a3fb217276c015
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   

Bug#950535: iptables-restore segfaults on nat table

2020-02-03 Thread Christoph Martin
Package: iptables
Version: 1.8.2-4
Severity: grave

Dear Maintainer,

after updateing from stretch to buster ufw failed to work.

we have nat-table entries for PREROUTING and POSTROUTING . iptables-restore
segfaults on these rules. The following rules lead to the error:

*nat
-F PREROUTING
-A PREROUTING -i eth0 -p tcp --dport 22 -j REDIRECT --to-ports 1194
-F PREROUTING
-F POSTROUTING
COMMIT

The version from backports: 1.8.3-2~bpo10+1 does not have this problem.
Please bring this fix to the stable release. The ufw firewall ist disabled
after this error. So I consider this a security problem

Christoph

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:\
en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables depends on:
ii  libc62.28-10
ii  libip4tc01.8.2-4
ii  libip6tc01.8.2-4
ii  libiptc0 1.8.2-4
ii  libmnl0  1.0.4-2
ii  libnetfilter-conntrack3  1.0.7-1
ii  libnfnetlink01.0.1-3+b1
ii  libnftnl11   1.1.2-2
ii  libxtables12 1.8.2-4

Versions of packages iptables recommends:
ii  nftables  0.9.0-2

Versions of packages iptables suggests:
ii  kmod  26-1



signature.asc
Description: OpenPGP digital signature