Date: Thu, 15 Feb 2001 16:50:02 -0800 (PST) From: Brian Somers <brian@Awfulhak.org> To: freebsd-bugs@FreeBSD.org Subject: Re: misc/25107: natd (and others?) segfault caused by error in libalias Message-ID: <200102160050.f1G0o2n05024@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/25107; it has been noted by GNATS.
From: Brian Somers <brian@Awfulhak.org>
To: jcole@3lefties.com
Cc: freebsd-gnats-submit@FreeBSD.ORG, brian@Awfulhak.org
Subject: Re: misc/25107: natd (and others?) segfault caused by error in libalias
Date: Fri, 16 Feb 2001 00:42:40 +0000
> >Number: 25107
> >Category: misc
> >Synopsis: natd (and others?) segfault caused by error in libalias
[.....]
> >Description:
> line 2622 of alias_db.c in libalias declares a varable to hold "The first firewall entry free for our use" when poking holes in the firewall for ftp data and irc dcc connections. It's declared as int. FreeBSD's ipfw firewall uses rule numbers up to 65535, so this variable should be declared as unsigned int. When natd is set up to use this feature and the firewall "base" number is greater than 32767, natd happily segfaults when an ftp data connection is natted, and natd tries to generate the firewall h ole. I'm sure other software based on libalias is affected.
I'm a little confused here. An int is 32 bits - maxint is just above
2,000,000,000. I don't understand what's wrapping at 32768...
> >How-To-Repeat:
> Simply fire up natd with the -punch_fw basenumber:count option and the basenumber set greater than 32767 and try and establish an ftp data connection through the nat.
> >Fix:
> Change line 2622 of alias_db.c to read "unsigned int" instead of "int". Note also that natd uses an unsigned int internally and when passing the base value to libalias routines.
This looks dangerous. Just paging down the code a bit shows things
like fireWallNumNums and fileWallActiveNum should also probably be
unsigned. This also implies that ``fwhole'' (local and in struct
tcp_dat) should be unsigned - but that breaks in at least one place
(namely the ``if (fwhole < 0)'' bit in ClearFWHole().
I'm not saying that your suggestion is wrong, but that it looks a bit
dangerous to me :-/
--
Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org>
<http://www.Awfulhak.org>; <brian@[uk.]OpenBSD.org>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200102160050.f1G0o2n05024>