From vinnix.bsd at gmail.com Thu Jul 2 20:42:11 2009 From: vinnix.bsd at gmail.com (Vinicius Abrahao) Date: Thu Jul 2 20:42:20 2009 Subject: Recent XSS in joomla 1.5.11 Message-ID: <1e31c7980907021320i164bc5edj32095c9df1f8096e@mail.gmail.com> Hi Fellows, I read that we have a new issue with joomla. http://packetstormsecurity.org/0907-exploits/joomla1512-xss.txt http://www.joomla.org/announcements/release-news/5242-joomla-1512-released.html Thanks, Vin?cius From roberto.nunnari at supsi.ch Fri Jul 3 14:58:56 2009 From: roberto.nunnari at supsi.ch (Roberto Nunnari) Date: Fri Jul 3 14:59:03 2009 Subject: Recent XSS in joomla 1.5.11 In-Reply-To: <1e31c7980907021320i164bc5edj32095c9df1f8096e@mail.gmail.com> References: <1e31c7980907021320i164bc5edj32095c9df1f8096e@mail.gmail.com> Message-ID: <4A4E0E93.5000108@supsi.ch> Hi. Vinicius Abrahao ha scritto: > Hi Fellows, > > I read that we have a new issue with joomla. I submitted the port patch yesterday. See http://www.freebsd.org/cgi/query-pr.cgi?pr=136246 Best regards. Robi From cperciva at freebsd.org Wed Jul 8 00:52:57 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Wed Jul 8 00:53:05 2009 Subject: rumours of openssh vulnerability Message-ID: <4A53EDC1.4040506@freebsd.org> Hi all, There are rumours flying around about a supposed vulnerability in OpenSSH. Two details which I've seen mentioned many times are (a) that this exploit was used to break into a RedHat system running OpenSSH 4.3 plus backported security patches, and (b) that "recent" versions of OpenSSH are not affected; but it's not clear if there is any basis for these rumours. Given the almost complete lack of information here, there obviously will not be a FreeBSD security advisory forthcoming until we know more. As such, I can only recommend that the standard advice be followed: Use a firewall to limit who can access OpenSSH; and make sure that you are running a supported FreeBSD release. If anyone has any concrete information concerning this, please contact the FreeBSD security team at . -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From mozolevsky at gmail.com Wed Jul 8 01:36:20 2009 From: mozolevsky at gmail.com (Igor Mozolevsky) Date: Wed Jul 8 01:36:28 2009 Subject: rumours of openssh vulnerability In-Reply-To: <4A53EDC1.4040506@freebsd.org> References: <4A53EDC1.4040506@freebsd.org> Message-ID: 2009/7/8 FreeBSD Security Officer : > There are rumours flying around about a supposed vulnerability in OpenSSH. [snip] More information is at the Internet Storm Center: http://isc.sans.org/diary.html?storyid=6742 Cheers, -- Igor From nhoughton at sourcefire.com Wed Jul 8 13:58:33 2009 From: nhoughton at sourcefire.com (Nigel Houghton) Date: Wed Jul 8 14:15:21 2009 Subject: rumours of openssh vulnerability In-Reply-To: References: <4A53EDC1.4040506@freebsd.org> Message-ID: <3a88cd320907080636g1e30610ek4de2384abab6f779@mail.gmail.com> On Tue, Jul 7, 2009 at 9:15 PM, Igor Mozolevsky wrote: > 2009/7/8 FreeBSD Security Officer : > >> There are rumours flying around about a supposed vulnerability in OpenSSH. > > [snip] > > More information is at the Internet Storm Center: > http://isc.sans.org/diary.html?storyid=6742 > > > Cheers, > -- > Igor Actually, no, there isn't any more information on the ISC blog. There is actually less information, the logs are truncated (not that there's anything to see in them anyway). Nice to see an appropriate reaction to this "issue" from Colin. -- Nigel Houghton Head Mentalist SF VRT http://vrt-sourcefire.blogspot.com && http://www.snort.org/vrt/ From endian.sign at gmail.com Wed Jul 8 19:52:35 2009 From: endian.sign at gmail.com (rrl) Date: Wed Jul 8 19:52:45 2009 Subject: gzip memory corruption Message-ID: <20090708193339.GA4836@minerva.freedsl.mg> Hi all, > uname -a FreeBSD XXXXX 7.2-RELEASE FreeBSD 7.2-RELEASE #1: Wed Jun 24 10:19:42 EAT 2009 XXXXXXXXX:/usr/obj/usr/src/sys/GENERIC i386 I run Freebsd 7.2 and gzip doesn't handle correctly long suffix name with the -S option. > gzip -S `perl -e 'print "A"x1200'` dummy_file Memory fault (core dumped) The offending code lays in the function file_compress: > /* Add (usually) .gz to filename */ > if ((size_t)snprintf(outfile, outsize, "%s%s", > file, suffixes[0].zipped) >= outsize) > memcpy(outfile - suffixes[0].ziplen - 1, > suffixes[0].zipped, suffixes[0].ziplen + 1); The problem here is that outfile points to a local buffer from the function handle_file which calls file_compress. And given that we give a very long suffix, memcpy does in fact write to memory location out of outfile, overwriting the return address of file_compress. Here's a possible fix: --- /usr/src/usr.bin/gzip/gzip.c 2009-05-17 12:00:16.000000000 +0300 +++ gzip.c 2009-07-08 20:27:22.000000000 +0300 @@ -1219,10 +1219,15 @@ file_compress(char *file, char *outfile, /* Add (usually) .gz to filename */ if ((size_t)snprintf(outfile, outsize, "%s%s", - file, suffixes[0].zipped) >= outsize) + file, suffixes[0].zipped) >= outsize && + (unsigned int)suffixes[0].ziplen < outsize) memcpy(outfile - suffixes[0].ziplen - 1, suffixes[0].zipped, suffixes[0].ziplen + 1); - + else { + maybe_warnx("filename too long %s%s", file, suffixes[0].zipped); + close(in); + return -1; + } #ifndef SMALL if (check_outfile(outfile) == 0) { close(in); Cheers, From rea-fbsd at codelabs.ru Wed Jul 8 20:25:20 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Jul 8 20:25:27 2009 Subject: gzip memory corruption In-Reply-To: <20090708193339.GA4836@minerva.freedsl.mg> References: <20090708193339.GA4836@minerva.freedsl.mg> Message-ID: Wed, Jul 08, 2009 at 10:33:39PM +0300, rrl wrote: > I run Freebsd 7.2 and gzip doesn't handle correctly long suffix name > with the -S option. > > gzip -S `perl -e 'print "A"x1200'` dummy_file > Memory fault (core dumped) > > The offending code lays in the function file_compress: > > /* Add (usually) .gz to filename */ > > if ((size_t)snprintf(outfile, outsize, "%s%s", > > file, suffixes[0].zipped) >= outsize) > > memcpy(outfile - suffixes[0].ziplen - 1, > > suffixes[0].zipped, suffixes[0].ziplen + 1); The memcpy() call looks like a complete madness: it will write before the beginning of the 'outfile', so it will be buffer underflow in any case (unless I am terribly mistaken and missing some obvious point). I'd change the above code to warn and return if snprintf will discard some trailing characters, the patch is attached. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # -------------- next part -------------- A non-text attachment was scrubbed... Name: gzip.c-fix-buffer-underflow.diff Type: text/x-diff Size: 609 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20090708/9f479154/gzip.c-fix-buffer-underflow.bin From rea-fbsd at codelabs.ru Thu Jul 9 03:34:35 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Thu Jul 9 03:34:43 2009 Subject: gzip memory corruption In-Reply-To: <4A553458.70005@delphij.net> References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> Message-ID: Xin, good day. Wed, Jul 08, 2009 at 05:05:44PM -0700, Xin LI wrote: > >>> The offending code lays in the function file_compress: > >>>> /* Add (usually) .gz to filename */ > >>>> if ((size_t)snprintf(outfile, outsize, "%s%s", > >>>> file, suffixes[0].zipped) >= outsize) > >>>> memcpy(outfile - suffixes[0].ziplen - 1, > >>>> suffixes[0].zipped, suffixes[0].ziplen + 1); > >> The memcpy() call looks like a complete madness: it will write before > >> the beginning of the 'outfile', so it will be buffer underflow in any > >> case (unless I am terribly mistaken and missing some obvious point). > > > >> I'd change the above code to warn and return if snprintf will discard > >> some trailing characters, the patch is attached. > > I have attached another possible fix, which catches the problem when > parsing the command line. The point is that, I think we really want to > catch bad input as early as possible. Yes, it is good to catch it here too. > Index: gzip.c > =================================================================== > --- gzip.c (?????? 195435) > +++ gzip.c (????????????) > @@ -372,6 +372,8 @@ > case 'S': > len = strlen(optarg); > if (len != 0) { > + if (len >= PATH_MAX) > + errx(1, "incorrect suffix: '%s'", optarg); > suffixes[0].zipped = optarg; > suffixes[0].ziplen = len; > } else { But the place with the memcpy() should be patched too. Two reasons: - suffix could not (yet) overflow PATH_MAX, but filename + suffix -- can; - I am really worried about the usage of memcpy with underflow; I had tried to study the reasons for it via NetBSD CVS, but it just appeared one day and the reason for going to 'outfile - suffixes[0].ziplen - 1' (with .gz its outfile - 4) are unknown; I am still taking this as the programming error. So, unless you know why we're underflowing the passed pointer, the memcpy block should be patched too, for future safety and code correctness. -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From delphij at delphij.net Thu Jul 9 04:04:55 2009 From: delphij at delphij.net (Xin LI) Date: Thu Jul 9 04:05:10 2009 Subject: gzip memory corruption In-Reply-To: References: <20090708193339.GA4836@minerva.freedsl.mg> Message-ID: <4A553080.5060205@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Wed, Jul 08, 2009 at 10:33:39PM +0300, rrl wrote: >> I run Freebsd 7.2 and gzip doesn't handle correctly long suffix name >> with the -S option. >>> gzip -S `perl -e 'print "A"x1200'` dummy_file >> Memory fault (core dumped) >> >> The offending code lays in the function file_compress: >>> /* Add (usually) .gz to filename */ >>> if ((size_t)snprintf(outfile, outsize, "%s%s", >>> file, suffixes[0].zipped) >= outsize) >>> memcpy(outfile - suffixes[0].ziplen - 1, >>> suffixes[0].zipped, suffixes[0].ziplen + 1); > > The memcpy() call looks like a complete madness: it will write before > the beginning of the 'outfile', so it will be buffer underflow in any > case (unless I am terribly mistaken and missing some obvious point). > > I'd change the above code to warn and return if snprintf will discard > some trailing characters, the patch is attached. Nice catch! I'll take a look at this as soon as possible. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpVMIAACgkQi+vbBBjt66BkrgCePlsfN2Y8+yXkJiI39A2tEmRS CKcAnipqLptYZx2BeuM+7piL0vBF1yzz =9kvD -----END PGP SIGNATURE----- From delphij at delphij.net Thu Jul 9 04:04:56 2009 From: delphij at delphij.net (Xin LI) Date: Thu Jul 9 04:05:11 2009 Subject: gzip memory corruption In-Reply-To: <4A553080.5060205@delphij.net> References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> Message-ID: <4A553458.70005@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Xin LI wrote: > Eygene Ryabinkin wrote: >> Wed, Jul 08, 2009 at 10:33:39PM +0300, rrl wrote: >>> I run Freebsd 7.2 and gzip doesn't handle correctly long suffix name >>> with the -S option. >>>> gzip -S `perl -e 'print "A"x1200'` dummy_file >>> Memory fault (core dumped) >>> >>> The offending code lays in the function file_compress: >>>> /* Add (usually) .gz to filename */ >>>> if ((size_t)snprintf(outfile, outsize, "%s%s", >>>> file, suffixes[0].zipped) >= outsize) >>>> memcpy(outfile - suffixes[0].ziplen - 1, >>>> suffixes[0].zipped, suffixes[0].ziplen + 1); >> The memcpy() call looks like a complete madness: it will write before >> the beginning of the 'outfile', so it will be buffer underflow in any >> case (unless I am terribly mistaken and missing some obvious point). > >> I'd change the above code to warn and return if snprintf will discard >> some trailing characters, the patch is attached. I have attached another possible fix, which catches the problem when parsing the command line. The point is that, I think we really want to catch bad input as early as possible. If there is no objections I would request for approval from re@. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEUEARECAAYFAkpVNFcACgkQi+vbBBjt66AkuQCfSm79QmZC2jPwE8kSEaz5NvH7 V+8Al0zsIfe40Tv0Yu/LrtMpnEK5cok= =OtC/ -----END PGP SIGNATURE----- -------------- next part -------------- Index: gzip.c =================================================================== --- gzip.c (?????? 195435) +++ gzip.c (????????????) @@ -372,6 +372,8 @@ case 'S': len = strlen(optarg); if (len != 0) { + if (len >= PATH_MAX) + errx(1, "incorrect suffix: '%s'", optarg); suffixes[0].zipped = optarg; suffixes[0].ziplen = len; } else { From oliver.pntr at gmail.com Mon Jul 20 17:38:17 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Mon Jul 20 17:38:24 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley Message-ID: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> http://milw0rm.com/exploits/9206 From des at des.no Tue Jul 21 15:58:07 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jul 21 15:58:14 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> (Oliver Pinter's message of "Mon, 20 Jul 2009 19:08:58 +0200") References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> Message-ID: <86zlayvydu.fsf@ds4.des.no> Oliver Pinter writes: > http://milw0rm.com/exploits/9206 Standard procedure is to contact so@freebsd.org directly rather than post an exploit on a public, archived mailing list. DES -- Dag-Erling Sm?rgrav - des@des.no From jmiller at securityfocus.com Tue Jul 21 18:22:36 2009 From: jmiller at securityfocus.com (Jason V. Miller) Date: Tue Jul 21 18:22:43 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <86zlayvydu.fsf@ds4.des.no> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <86zlayvydu.fsf@ds4.des.no> Message-ID: <20090721180413.GA13170@mail.securityfocus.com> On Tue, Jul 21, 2009 at 05:39:25PM +0200, Dag-Erling Sm??rgrav wrote: > Oliver Pinter writes: > > http://milw0rm.com/exploits/9206 > > Standard procedure is to contact so@freebsd.org directly rather than > post an exploit on a public, archived mailing list. To be fair, he didn't post a new exploit to the list, but instead a link to an already-public exploit. J. -- Jason V. Miller From oliver.pntr at gmail.com Tue Jul 21 18:58:23 2009 From: oliver.pntr at gmail.com (Oliver Pinter) Date: Tue Jul 21 18:58:30 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <20090721180413.GA13170@mail.securityfocus.com> References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <86zlayvydu.fsf@ds4.des.no> <20090721180413.GA13170@mail.securityfocus.com> Message-ID: <6101e8c40907211158j29a84b2fl6b343790b698977b@mail.gmail.com> Hi all! Yeah, I found the expolit in milw0rm at Jul 20, 2009. and send this mail, before I never read anything from so@freebsd.org... and from this mail (I think security officer), so then add cperciva to CC. btw: oliver@oliverp src> git grep "so@freebsd.org" sys/dev/usb/ubser.c: * Copyright (c) 2004 Ber{}ter sys/dev/usb/ubser.h: * Copyright (c) 2003 Ber{}ter This git tree is the full freebsd tree, imported to git, and no information from this mail address. On 7/21/09, Jason V. Miller wrote: > On Tue, Jul 21, 2009 at 05:39:25PM +0200, Dag-Erling Sm??rgrav wrote: >> Oliver Pinter writes: >> > http://milw0rm.com/exploits/9206 >> >> Standard procedure is to contact so@freebsd.org directly rather than >> post an exploit on a public, archived mailing list. > > To be fair, he didn't post a new exploit to the list, but instead a link to > an already-public exploit. > > J. > > -- > Jason V. Miller > From des at des.no Tue Jul 21 20:10:33 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jul 21 20:11:40 2009 Subject: 2009-07-20 FreeBSD 7.2 (pecoff executable) Local Denial of Service Exploit 23 R D Shaun Colley In-Reply-To: <6101e8c40907211158j29a84b2fl6b343790b698977b@mail.gmail.com> (Oliver Pinter's message of "Tue, 21 Jul 2009 20:58:21 +0200") References: <6101e8c40907201008n62eeec05r6670a79698bc2ac7@mail.gmail.com> <86zlayvydu.fsf@ds4.des.no> <20090721180413.GA13170@mail.securityfocus.com> <6101e8c40907211158j29a84b2fl6b343790b698977b@mail.gmail.com> Message-ID: <861vo9x0eg.fsf@ds4.des.no> Oliver Pinter writes: > Yeah, I found the expolit in milw0rm at Jul 20, 2009. and send this > mail, before I never read anything from so@freebsd.org... http://www.freebsd.org/security so@ is an alias for security-officer@. DES -- Dag-Erling Sm?rgrav - des@des.no From security-advisories at freebsd.org Wed Jul 29 00:48:36 2009 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Wed Jul 29 00:48:48 2009 Subject: FreeBSD Security Advisory FreeBSD-SA-09:12.bind Message-ID: <200907290048.n6T0mZnk001216@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-09:12.bind Security Advisory The FreeBSD Project Topic: BIND named(8) dynamic update message remote DoS Category: contrib Module: bind Announced: 2009-07-29 Credits: Matthias Urlichs Affects: All supported versions of FreeBSD Corrected: 2009-07-28 23:59:22 UTC (RELENG_7, 7.2-STABLE) 2009-07-29 00:14:14 UTC (RELENG_7_2, 7.2-RELEASE-p3) 2009-07-29 00:14:14 UTC (RELENG_7_1, 7.1-RELEASE-p7) 2009-07-29 00:13:47 UTC (RELENG_6, 6.4-STABLE) 2009-07-29 00:14:14 UTC (RELENG_6_4, 6.4-RELEASE-p6) 2009-07-29 00:14:14 UTC (RELENG_6_3, 6.3-RELEASE-p12) CVE Name: CVE-2009-0696 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . NOTE: Due to this issue being accidentally disclosed early, updated binaries are yet not available via freebsd-update at the time this advisory is being published. Email will be sent to the freebsd-security mailing list when the binaries are available via freebsd-update. I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. Dynamic update messages may be used to update records in a master zone on a nameserver. II. Problem Description When named(8) receives a specially crafted dynamic update message an internal assertion check is triggered which causes named(8) to exit. To trigger the problem, the dynamic update message must contains a record of type "ANY" and at least one resource record set (RRset) for this fully qualified domain name (FQDN) must exist on the server. III. Impact An attacker which can send DNS requests to a nameserver can cause it to exit, thus creating a Denial of Service situation. IV. Workaround No generally applicable workaround is available, but some firewalls may be able to prevent nsupdate DNS packets from reaching the nameserver. NOTE WELL: Merely configuring named(8) to ignore dynamic updates is NOT sufficient to protect it from this vulnerability. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE, or 7-STABLE, or to the RELENG_7_2, RELENG_7_1, RELENG_6_4, or RELENG_6_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 6.3, 6.4, 7.1, and 7.2 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-09:12/bind.patch # fetch http://security.FreeBSD.org/patches/SA-09:12/bind.patch.asc b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/lib/bind # make obj && make depend && make && make install # cd /usr/src/usr.sbin/named # make obj && make depend && make && make install # /etc/rc.d/named restart VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. CVS: Branch Revision Path - ------------------------------------------------------------------------- RELENG_6 src/contrib/bind9/bin/named/update.c 1.1.1.2.2.5 RELENG_6_4 src/UPDATING 1.416.2.40.2.10 src/sys/conf/newvers.sh 1.69.2.18.2.12 src/contrib/bind9/bin/named/update.c 1.1.1.2.2.3.2.1 RELENG_6_3 src/UPDATING 1.416.2.37.2.17 src/sys/conf/newvers.sh 1.69.2.15.2.16 src/contrib/bind9/bin/named/update.c 1.1.1.2.2.2.2.1 RELENG_7 src/contrib/bind9/bin/named/update.c 1.1.1.5.2.3 RELENG_7_2 src/UPDATING 1.507.2.23.2.6 src/sys/conf/newvers.sh 1.72.2.11.2.7 src/contrib/bind9/bin/named/update.c 1.1.1.5.2.2.2.1 RELENG_7_1 src/UPDATING 1.507.2.13.2.10 src/sys/conf/newvers.sh 1.72.2.9.2.11 src/contrib/bind9/bin/named/update.c 1.1.1.5.2.1.4.1 HEAD src/contrib/bind9/bin/named/update.c 1.4 - ------------------------------------------------------------------------- Subversion: Branch/path Revision - ------------------------------------------------------------------------- head/ r195936 stable/6/ r195934 releng/6.4/ r195935 releng/6.3/ r195935 stable/7/ r195933 releng/7.2/ r195935 releng/7.1/ r195935 - ------------------------------------------------------------------------- VII. References https://www.isc.org/node/474 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538975 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0696 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-09:12.bind.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFKb5koFdaIBMps37IRAglLAKCFGXI+MAsksnK5TZB/8L3UFhPS1gCgl7q5 6fCpOeBcf7f83dVfKRDVF0I= =akJW -----END PGP SIGNATURE----- From cperciva at freebsd.org Wed Jul 29 16:34:31 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Wed Jul 29 16:34:39 2009 Subject: FreeBSD Update bits for FreeBSD-SA-09:12.bind Message-ID: <4A707A16.5080309@freebsd.org> Hi all, The freebsd-update bits for FreeBSD-SA-09:12.bind are now on the mirrors for systems running FreeBSD/{i386, amd64} {6.3, 6.4, 7.1, 7.2}-RELEASE. The bits for 8.0-BETA{1, 2} are still building and will be up later today. Sorry about the delay -- it takes approximately 24 hours to build all of the bits on the hardware we're currently using, and as the advisory mentioned, this issue was accidentally disclosed early, so we didn't have a chance to build all the freebsd-update bits ahead of time. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From cperciva at freebsd.org Thu Jul 30 06:53:11 2009 From: cperciva at freebsd.org (FreeBSD Security Officer) Date: Thu Jul 30 06:53:18 2009 Subject: FreeBSD Update bits for FreeBSD-SA-09:12.bind In-Reply-To: <4A707A16.5080309@freebsd.org> References: <4A707A16.5080309@freebsd.org> Message-ID: <4A714356.8060705@freebsd.org> I wrote: > The freebsd-update bits for FreeBSD-SA-09:12.bind are now on the mirrors > for > systems running FreeBSD/{i386, amd64} {6.3, 6.4, 7.1, 7.2}-RELEASE. The > bits > for 8.0-BETA{1, 2} are still building and will be up later today. The bits for 8.0-BETA{1, 2} are now on the freebsd-update mirrors, too. -- Colin Percival Security Officer, FreeBSD | freebsd.org | The power to serve Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid From marquis at roble.com Thu Jul 30 15:15:04 2009 From: marquis at roble.com (Roger Marquis) Date: Thu Jul 30 15:15:11 2009 Subject: DNS probe sources In-Reply-To: <20090730120034.CD75610656CE@hub.freebsd.org> References: <20090730120034.CD75610656CE@hub.freebsd.org> Message-ID: <20090730145817.C45772B2157@mx5.roble.com> These source addresses are likely spoofed, but am still curious whether other FreeBSD admins saw a preponderance of DNS probes originating from Microsoft corp subnets ahead of the recent ISC bind vulnerability announcement? Roger Marquis Jul 28 16:51:23 PDT named[...]: client 94.245.67.253#10546: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:23 PDT named[...]: client 94.245.67.253#10543: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:18 PDT named[...]: client 94.245.67.253#10546: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:18 PDT named[...]: client 94.245.67.253#10543: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:13 PDT named[...]: client 94.245.67.253#10546: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:13 PDT named[...]: client 94.245.67.253#10543: query (cache) 'output.txt/A/IN' denied Jul 28 16:51:08 PDT named[...]: client 94.245.67.253#10370: query (cache) '>/A/IN' denied Jul 28 16:51:08 PDT named[...]: client 94.245.67.253#10366: query (cache) '>/A/IN' denied Jul 28 16:51:03 PDT named[...]: client 94.245.67.253#10370: query (cache) '>/A/IN' denied Jul 28 16:51:03 PDT named[...]: client 94.245.67.253#10366: query (cache) '>/A/IN' denied Jul 28 16:50:58 PDT named[...]: client 94.245.67.253#10370: query (cache) '>/A/IN' denied Jul 28 16:50:58 PDT named[...]: client 94.245.67.253#10366: query (cache) '>/A/IN' denied Jul 28 07:25:45 PDT named[...]: client 207.46.57.240#37973: query (cache) 'output.txt/A/IN' denied Jul 28 07:25:45 PDT named[...]: client 207.46.57.240#37959: query (cache) '>/A/IN' denied ... Jul 27 23:24:47 PDT named[...]: client 94.245.67.253#55561: query (cache) 'output.txt/A/IN' denied Jul 27 23:24:32 PDT named[...]: client 94.245.67.253#55354: query (cache) '>/A/IN' denied Jul 27 15:10:33 PDT named[...]: client 207.46.57.240#17255: query (cache) 'output.txt/A/IN' denied Jul 27 15:10:33 PDT named[...]: client 207.46.57.240#17242: query (cache) '>/A/IN' denied ... Jul 24 07:21:22 PDT named[...]: client 94.245.67.253#15828: query (cache) 'output.txt/A/IN' denied Jul 24 07:21:07 PDT named[...]: client 94.245.67.253#15637: query (cache) '>/A/IN' denied Jul 24 06:10:30 PDT named[...]: client 207.46.57.240#59717: query (cache) 'output.txt/A/IN' denied Jul 24 06:10:30 PDT named[...]: client 207.46.57.240#59707: query (cache) '>/A/IN' denied ... From reichert at numachi.com Thu Jul 30 22:02:03 2009 From: reichert at numachi.com (Brian Reichert) Date: Thu Jul 30 22:02:10 2009 Subject: DNS probe sources In-Reply-To: <20090730145817.C45772B2157@mx5.roble.com> References: <20090730120034.CD75610656CE@hub.freebsd.org> <20090730145817.C45772B2157@mx5.roble.com> Message-ID: <20090730213520.GC2506@numachi.com> On Thu, Jul 30, 2009 at 07:58:17AM -0700, Roger Marquis wrote: > These source addresses are likely spoofed, but am still curious whether > other FreeBSD admins saw a preponderance of DNS probes originating from > Microsoft corp subnets ahead of the recent ISC bind vulnerability > announcement? Running djbdns here... > > Roger Marquis > -- Brian Reichert 55 Crystal Ave. #286 Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large From delphij at delphij.net Thu Jul 30 23:51:28 2009 From: delphij at delphij.net (Xin LI) Date: Thu Jul 30 23:51:35 2009 Subject: gzip memory corruption In-Reply-To: References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> Message-ID: <4A7231A1.2050104@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Eygene, Eygene Ryabinkin wrote: [...] > But the place with the memcpy() should be patched too. Two reasons: > > - suffix could not (yet) overflow PATH_MAX, but filename + suffix -- > can; > > - I am really worried about the usage of memcpy with underflow; > I had tried to study the reasons for it via NetBSD CVS, but > it just appeared one day and the reason for going to > 'outfile - suffixes[0].ziplen - 1' (with .gz its outfile - 4) > are unknown; I am still taking this as the programming error. > > So, unless you know why we're underflowing the passed pointer, > the memcpy block should be patched too, for future safety and > code correctness. Sorry for the late response. I am busy recently. After carefully investigating the code, I have the following observations: - The usage of memcpy() here is wrong. It's definitely a bug. - The intention of it seems to be to make a pathname that fits into MAXPATHLEN, say, if we have /very/long/name which makes /very/long/name.gz longer than MAXPATHLEN, it might truncate it into, i.e. /very/long/n.gz instead. I feel really uncomfortable for the latter case, we should stop for that case instead of proceeding further. Having checked with GNU's gzip, it looks like that they arbitrarily set an upper limit of the suffix length to 30. This is unrelated to the memcpy bug but let's address it here as well. My revised patch would make the memcpy into a fatal errx, and reduce the allowed suffix length to 30 to match GNU behavior. Please let me know if this version looks better, I'll propose it to re@ and commit if they approved it. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpyMaAACgkQi+vbBBjt66DLngCgv+VoeLsZN1NM5qFHX5hc0lPM 5WgAnjTeMukfn8akGrDpz8ozDDG/7AdV =7ywC -----END PGP SIGNATURE----- -------------- next part -------------- Index: gzip.c =================================================================== --- gzip.c (revision 195945) +++ gzip.c (working copy) @@ -150,6 +150,8 @@ }; #define NUM_SUFFIXES (sizeof suffixes / sizeof suffixes[0]) +#define SUFFIX_MAXLEN 30 + static const char gzip_version[] = "FreeBSD gzip 20090621"; #ifndef SMALL @@ -372,6 +374,8 @@ case 'S': len = strlen(optarg); if (len != 0) { + if (len >= SUFFIX_MAXLEN) + errx(1, "incorrect suffix: '%s'", optarg); suffixes[0].zipped = optarg; suffixes[0].ziplen = len; } else { @@ -1236,8 +1240,7 @@ /* Add (usually) .gz to filename */ if ((size_t)snprintf(outfile, outsize, "%s%s", file, suffixes[0].zipped) >= outsize) - memcpy(outfile - suffixes[0].ziplen - 1, - suffixes[0].zipped, suffixes[0].ziplen + 1); + errx(1, "Path name too long"); #ifndef SMALL if (check_outfile(outfile) == 0) { From rea-fbsd at codelabs.ru Fri Jul 31 05:29:26 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jul 31 05:29:34 2009 Subject: gzip memory corruption In-Reply-To: <4A7231A1.2050104@delphij.net> References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> <4A7231A1.2050104@delphij.net> Message-ID: <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> Xin, good day. Thu, Jul 30, 2009 at 04:49:53PM -0700, Xin LI wrote: > Having checked with GNU's gzip, it looks like that they arbitrarily set > an upper limit of the suffix length to 30. This is unrelated to the > memcpy bug but let's address it here as well. My revised patch would > make the memcpy into a fatal errx, and reduce the allowed suffix length > to 30 to match GNU behavior. > > Please let me know if this version looks better, I'll propose it to re@ > and commit if they approved it. Yes, this patch looks much better, thanks! One thing: I would expand the error message here: > + if (len >= SUFFIX_MAXLEN) > + errx(1, "incorrect suffix: '%s'", optarg); say to > + errx(1, "incorrect suffix: '%s': too long", optarg); I will be better, since the reason of incorrectness will be stated: it is not very obvious why the suffix like '.barrhmumbojombofromthemightyuserwhoseemtogonecompletelymad' isn't acceptable ;)) -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From delphij at delphij.net Fri Jul 31 05:44:28 2009 From: delphij at delphij.net (Xin LI) Date: Fri Jul 31 05:44:35 2009 Subject: gzip memory corruption In-Reply-To: <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> <4A7231A1.2050104@delphij.net> <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> Message-ID: <4A72846B.60604@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, After talking with Matthew Green (the author of NetBSD) it seems that it would be more reasonable to fix the bug itself than breaking upon receipt. Here is the patch. Regarding to the suffix prompt, give me some time to think about it. At the beginning I just matched GNU gzip's behavior, but they cover when the -S is specified when decompressing, which we don't care about, so it might be reasonable for us to explicitly say it's too long. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpyhGoACgkQi+vbBBjt66Bk3wCfT0w2DQipG05hksUv9r/CPioo s4IAni8otQHmNOxticY23JqzevzsDeBL =JzTo -----END PGP SIGNATURE----- -------------- next part -------------- Index: gzip.c =================================================================== --- gzip.c (revision 195945) +++ gzip.c (working copy) @@ -150,6 +150,8 @@ }; #define NUM_SUFFIXES (sizeof suffixes / sizeof suffixes[0]) +#define SUFFIX_MAXLEN 30 + static const char gzip_version[] = "FreeBSD gzip 20090621"; #ifndef SMALL @@ -372,6 +374,8 @@ case 'S': len = strlen(optarg); if (len != 0) { + if (len > SUFFIX_MAXLEN) + errx(1, "incorrect suffix: '%s'", optarg); suffixes[0].zipped = optarg; suffixes[0].ziplen = len; } else { @@ -1236,7 +1240,7 @@ /* Add (usually) .gz to filename */ if ((size_t)snprintf(outfile, outsize, "%s%s", file, suffixes[0].zipped) >= outsize) - memcpy(outfile - suffixes[0].ziplen - 1, + memcpy(outfile + outsize - suffixes[0].ziplen - 1, suffixes[0].zipped, suffixes[0].ziplen + 1); #ifndef SMALL From rea-fbsd at codelabs.ru Fri Jul 31 06:52:10 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Fri Jul 31 06:52:17 2009 Subject: gzip memory corruption In-Reply-To: <4A72846B.60604@delphij.net> References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> <4A7231A1.2050104@delphij.net> <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> <4A72846B.60604@delphij.net> Message-ID: Xin, Thu, Jul 30, 2009 at 10:43:07PM -0700, Xin LI wrote: > After talking with Matthew Green (the author of NetBSD) it seems that it > would be more reasonable to fix the bug itself than breaking upon > receipt. Here is the patch. You'll probably want to check that (outsize - suffixes[0].ziplen - 1) is greater than zero. Like this: ----- if ((size_t)snprintf(outfile, outsize, "%s%s", file, suffixes[0].zipped) >= outsize) { size_t sfx_start = outsize - suffixes[0] - 1; if (sfx_start > 0) { memcpy(outfile + sfx_start, suffixes[0].zipped, suffixes[0].ziplen + 1); } else { errx(1, "Can't insert suffix: name buffer is too short"); } } ----- Just now we can garantee that 'outsize' will fit any suffix because of the suffix length check, but when Someone (TM) will modify the code, this could no longer be true and a bug will arise again. So it is better to check this locally and fail loudly if we can't make it happen. I should say that transforming the "/long-path/foo.gz" (that is expected) into "/long-path/f.gz" isn't quite obvious for the end-user. But if the absence of such a transformation will break anything that relies on this behaviour (I can't think about any usages of this behaviour, but who knows), then the code should keep it. What were Mattew's arguments for keeping the old behaviour? -- Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook {_.-``-' {_/ # From delphij at delphij.net Fri Jul 31 08:02:33 2009 From: delphij at delphij.net (Xin LI) Date: Fri Jul 31 08:02:40 2009 Subject: gzip memory corruption In-Reply-To: References: <20090708193339.GA4836@minerva.freedsl.mg> <4A553080.5060205@delphij.net> <4A553458.70005@delphij.net> <4A7231A1.2050104@delphij.net> <856ux8zhn21/d1hDLYeNjC7FQ1Y@xg9dzetjpj18poIU9mNsJ0TqP1U> <4A72846B.60604@delphij.net> Message-ID: <4A72A4D3.1070902@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Eygene Ryabinkin wrote: > Xin, > > Thu, Jul 30, 2009 at 10:43:07PM -0700, Xin LI wrote: >> After talking with Matthew Green (the author of NetBSD) it seems that it >> would be more reasonable to fix the bug itself than breaking upon >> receipt. Here is the patch. > > You'll probably want to check that (outsize - suffixes[0].ziplen - 1) > is greater than zero. Like this: [...] > Just now we can garantee that 'outsize' will fit any suffix because of > the suffix length check, but when Someone (TM) will modify the code, > this could no longer be true and a bug will arise again. So it is > better to check this locally and fail loudly if we can't make it happen. We should probably add an assertion here (e.g. assert outsize > suffixes[0].ziplen]), but no, I don't think it's the right thing to re-check already sanitized input, it is not a good practice for production code to check the same thing everywhere, it's something that should happen during development and testing phase, these should be assertions IMHO. > I should say that transforming the "/long-path/foo.gz" (that is > expected) into "/long-path/f.gz" isn't quite obvious for the end-user. > But if the absence of such a transformation will break anything that > relies on this behaviour (I can't think about any usages of this > behaviour, but who knows), then the code should keep it. What were > Mattew's arguments for keeping the old behaviour? Because GNU gzip do the truncation instead of reporting an error (I think the original intention for the memcpy was to match this behavior as well). There are even worse cases for the problem you have raised, for instance truncating /long/p/a/t/h.gz to /long/p/a/.gz . But for now I think the underflow issue is more serious than that, and it would be probably a better idea if we address the stack underflow now, and have a clear mind to re-think about how we should do it. There is undergoing plan to replace gzip with something more efficient as well, on the other hand. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpypNIACgkQi+vbBBjt66BVlQCdHJC1upV+z29Ex4pb86uDBoPc PwsAni2t0pwuptNuP1uKKyX5LhjSSOKl =Rf8c -----END PGP SIGNATURE-----