possible bug in firewall transparent proxy port redirection for UDP

kutek@raven.cybercomm.net
Wed, 8 Jul 1998 14:26:00 -0400


As part of my persoanl "no daemons shall run as root " campaign, I have
seized on the port redirection capabilities of the linux fireall transparent
proxy to run various historically problematical daemons from non privileged
ports.In doing so i think i have found a bug in the UDP port redirection
code.

here's the situation with sendmail , which is here running on port 2225:

the redirection rule is ipfwadm -I -P tcp -a accept -r 2225 -S 0/0 -D 0/0 25

the following is tcpdump output processed with tcpshow-here i am telnetting
to localhost port 25, the telnet port is 4719:

-----------------------------------------------------------------
127.0.0.1.25 -> 127.0.0.1.4719 over TCP
220 prism ESMTP Sendmail 8.9.0/8.6.9 ready at Wed, 8 Jul 1998 13:01:14 -0400.

-----------------------------------------------------------------
127.0.0.1.4719 -> 127.0.0.1.25 over TCP
helo prism.

-----------------------------------------------------------------
127.0.0.1.25 -> 127.0.0.1.4719 over TCP
<No data>
-----------------------------------------------------------------
127.0.0.1.25 -> 127.0.0.1.4719 over TCP
<No data>
-----------------------------------------------------------------
127.0.0.1.25 -> 127.0.0.1.4719 over TCP
250 prism Hello root@prism [127.0.0.1], pleased to meet you.

-----------------------------------------------------------------

note that data is flowing in both directions over port 25 (recall that
sendmail is actuall sitting on port 2225).

Everything is working OK.

now we try this with named, which is sitting on port 1153.

the redirection rule is :
ipfwadm -I -P udp -a accept -r 1153 -S 0/0 -D 0/0 53

I now do a dns query using nslookup, this is nslookup starting up:

-----------------------------------------------------------------
127.0.0.1.1071 -> 127.0.0.1.domain over UDP
.............1.0.0.127.in-addr.arpa.....
-----------------------------------------------------------------
127.0.0.1.1153 -> 127.0.0.1.1071 over UDP
.............1.0.0.127.in-addr.arpa.............Q... localhost..0.0.127.in-addr.arpa.......Q....g.root-servers.net.._.....6.....p$.

nslookup is using port 1071.note that domain is talking to nslookup
directly from port 1153 rather than 53 which is unexpected. but
nslookup doesn't seem to mind (query umn.edu):

127.0.0.1.1073 -> 127.0.0.1.domain over UDP
.............umn.edu.....
-----------------------------------------------------------------
127.0.0.1.1153 -> 127.0.0.1.1073 over UDP
.............umn.edu..............h...^...........h...^...........h...^............. .ns.nts...............nss.X.............hanna.cac
washington.edu..U...........eee.j...........TTT.|......Q.....#.
-----------------------------------------------------------------

However, ftp ( and telnet and almost all other net apps)
DO MIND, wanting an answer from port 53: (ftp ftp.kernel.org):

-----------------------------------------------------------------
127.0.0.1.1086 -> 127.0.0.1.domain over UDP
.~...........ftp.kernel.org.....
-----------------------------------------------------------------
127.0.0.1.1153 -> 127.0.0.1.1086 over UDP
.~...........ftp.kernel.org.............M+...linux.kernel.org..,......M+.....".2...........NS TRANSMETA.COM..2...........NS1.BEST.g.2...........NS2.|.2...........NS3.|.Z...............x.............)..............f................*
-----------------------------------------------------------------
127.0.0.1 -> 127.0.0.1 ICMP
destination-unreachable because port-unreachable
....E...j...@..............>..rf.~...........ftp.kernel.org.............M+...linux.kernel.org..,......M+.....".2...........NS TRANSMETA.COM..2...........NS1.BEST.g.2...........NS2.|.2...........NS3.|.Z...............x.............)..............f................*
-----------------------------------------------------------------

ftp and telnet fail with "unknown host" ,but named has the answer cached,
so it IS working,as seen from nslookup output:

> ftp.kernel.org
Server: localhost
Address: 127.0.0.1

Non-authoritative answer:
Name: linux.kernel.org
Address: 206.184.214.34
Aliases: ftp.kernel.org

Thus the firewall fails to redirect packets bidirectionally for UDP,
which it successfully does for tcp.

using the -b parameter to ipfwadm in the rules gets the same result,
answers still come directly from port 1153 rather than 53-net apps will
not accept these answers from named.

the kernel is 2.0.34

btw, did someone forget to put the ioport.c fix in 34 ?

I was unable to run X or any svgalib progs until i recompiled using a 2.1.X
ioport.c. hopefully this will be included in 2.0.35.

fractoid

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu