[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bad press again...



On Tue, Aug 30, 2005 at 12:17:22AM +0200, Florian Weimer wrote:
I think this part of the diff is pretty instructive, together with
upstream's explanation:

Frankly, no, it's not.
	if [ -n "$MACLIST_TTL" ]; then
	    chain1=$(macrecent_target $interface)
	    createchain $chain1 no
-	    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j $chain1
-	    run_iptables -A $chain1 -m recent --update                        --name $chain -j ACCEPT
-	    run_iptables -A $chain1 -m recent --set                           --name $chain -j ACCEPT
+	    run_iptables -A $chain  -m recent --rcheck --seconds $MACLIST_TTL --name $chain -j RETURN
+	    run_iptables -A $chain                                                          -j $chain1
+	    run_iptables -A $chain  -m recent --update                        --name $chain -j RETURN
+	    run_iptables -A $chain  -m recent --set                           --name $chain
	fi

I still have no idea what "chain1=$(macrecent_target $interface)" means.
I'm not sure why there's both an "update" and an "rcheck"--the man page
says they're equivalent, except that update has an additional side
effect. But if that's the case, why put the update in at all, since
there's a return after the rcheck and you'll never get to the update.
Presumably that has something to do with the mysterious chain1.  If we
pull up the full source we find that macrecent_target
is defined as macrecent_target() # $1 - interface
{
   [ -n "$MACLIST_TTL" ] && echo $(chain_base $1)_rec || echo RETURN
}
and we enter a maze of twisty functions, all alike. (Side note, this is
why I create my firewall rules by hand :-)  At any rate, this is why we
have package maintainers, who are presumably conversant with the code,
and with whom the security team can work to understand the issues at
hand.
I already outlined some of the questions and their rationales, which
your answer doesn't address (questions about interface and expectations
and possible unintended uses). There are some other things that are
quite vague in the original advisory. It says that if "a client is
positively identified through its MAC address, it bypasses all other
policies/rules in place, thus gaining access to all open services on the
firewall". What is "a client"? If you put in your router's mac address,
is any non-local ip granted access to anything?  The answer to these
questions isn't in a 4 line diff, the answer lies in a conversation with
someone who has spent time with the code and has actually used the
program. (And FWIW, I don't think that this list is the right place for
that conversation; if you have something else to add, send it to the BTS
and CC the security team.) Yeah, a careful look at the code could
probably answer these questions, but there are a lot of issues on the
queue...

Mike Stone



Reply to: