From ivangrvr299 at gmail.com Tue Jul 8 10:31:55 2008 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Tue Jul 8 10:32:02 2008 Subject: OPIE Challenge sequence Message-ID: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> Hi , Iam trying to choose OPIE as my OTP implementation for authenticating the clients. I have the following queries, could anyone please let me know these -- why does the challenge in OPIE are in predetermined form.. is it for determining the decryption key for the encrypted passphrase(stored in opiekeys). -- is it possible to generate random challenges using opiechallenge Any pointers/links will be very much helpful. Regards, Ivan From des at des.no Tue Jul 8 11:41:52 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jul 8 11:41:59 2008 Subject: OPIE Challenge sequence In-Reply-To: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> (Ivan Grover's message of "Tue\, 8 Jul 2008 15\:46\:37 +0530") References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> Message-ID: <86abgs7h86.fsf@ds4.des.no> "Ivan Grover" writes: > Iam trying to choose OPIE as my OTP implementation for authenticating the > clients. I have the following queries, could anyone please let me know these > -- why does the challenge in OPIE are in predetermined form.. > is it for determining the decryption key for the encrypted passphrase(stored > in opiekeys). There is no encryption involved; OPIE is based on a one-way hash function (usually MD5). I'm not sure what you mean by "predetermined form", but one of the features of OPIE is that you should be able to use it even when you don't have a key calculator, by pre-generating and printing a list of responses. > -- is it possible to generate random challenges using opiechallenge No. There is a random seed, but it remains the same until you either run out of keys or generate a new series. > Any pointers/links will be very much helpful. The opie(4) man page describes the algorithm. DES -- Dag-Erling Sm?rgrav - des@des.no From ivangrvr299 at gmail.com Tue Jul 8 13:41:37 2008 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Tue Jul 8 13:41:49 2008 Subject: OPIE Challenge sequence In-Reply-To: <20080708113030.GN62764@server.vk2pj.dyndns.org> References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> Message-ID: <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> Thank you so much for your responses. By "predetermined ", i meant the challenges appear sequentially in decremented fashion, so are we aware of any security hole with this. I ask this because usually the challenge/response implementations consider generating random challenges( i think here they have a weakness where the passphrase need to be in clear text). My problem is to determine the best challenge/response implementation for authenticating the clients. Please correct me if i missed something. Thanks and Regards, Ivan On Tue, Jul 8, 2008 at 5:00 PM, Peter Jeremy wrote: > On 2008-Jul-08 15:46:37 +0530, Ivan Grover wrote: > >Iam trying to choose OPIE as my OTP implementation for authenticating the > >clients. I have the following queries, could anyone please let me know > these > >-- why does the challenge in OPIE are in predetermined form.. > >is it for determining the decryption key for the encrypted > passphrase(stored > >in opiekeys). > > The passphrase is not encrypted - it is hashed and cannot be "decrypted". > Basically, the passphrase and seed are concatenated and the result is > hashed (using MD5) the number of times specified by the iteration count > and the seed, count and final hash are stored in /etc/opiekeys. > > The supplied response is easily verified because when you run it thru > MD5, you should get the hash in /etc/opiekeys. You then replace that > hash with the one the user supplied. > > >-- is it possible to generate random challenges using opiechallenge > > No. The seed has to match the seed that was used to generate the > hash with opiepasswd. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From des at des.no Tue Jul 8 15:37:28 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Jul 8 15:37:35 2008 Subject: OPIE Challenge sequence In-Reply-To: <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> (Ivan Grover's message of "Tue\, 8 Jul 2008 19\:11\:35 +0530") References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> Message-ID: <8663rg5qvd.fsf@ds4.des.no> "Ivan Grover" writes: > Thank you so much for your responses. By "predetermined ", i meant the > challenges appear sequentially in decremented fashion, so are we aware of > any security hole with this. There is no way to deduce the next challenge from the current one. This is documented in the opie(4) man page. Here's the only advisory I could find for OPIE: http://security.freebsd.org/advisories/FreeBSD-SA-06:12.opie.asc > I ask this because usually the challenge/response implementations > consider generating random challenges( i think here they have a > weakness where the passphrase need to be in clear text). OPIE cannot use random challenges, because one of the requirements is that it should be possible to print a list of pre-generated responses. The advantage of OPIE over traditional passwords is that OPIE is not vulnerable to replay attacks, but this is not as relevant these days as it was back when S/Key (on which OPIE is based) was designed. Replay attacks aren't very effective against encrypted protocols such as SSH. > My problem is to determine the best challenge/response implementation > for authenticating the clients. Systems like OPIE, where the challenge is actually issued to the user and not just to the user's software, require the user to have access to a response calculator, or to carry a sheet of precalculated responses. The former is difficult unless the users always log in from their own desktop or laptop computer, and the latter is usually a bad idea since someone might steel the sheet. On the bright side, it should be fairly easy to write an OTP calculator that run on a cell phone, such as an S60-based Nokia phones or an iPhone. I'd say that the only advantage of OPIE today is that it's free. DES -- Dag-Erling Sm?rgrav - des@des.no From astorms at ncircle.com Tue Jul 8 18:50:10 2008 From: astorms at ncircle.com (Andrew Storms) Date: Tue Jul 8 18:50:26 2008 Subject: BIND update? Message-ID: Are going to expect a update for BIND today? http://www.isc.org/index.pl?/sw/bind/bind-security.php From freebsd-security at dfmm.org Tue Jul 8 19:54:02 2008 From: freebsd-security at dfmm.org (Jason Stone) Date: Tue Jul 8 19:54:15 2008 Subject: OPIE Challenge sequence In-Reply-To: <8663rg5qvd.fsf@ds4.des.no> References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> <8663rg5qvd.fsf@ds4.des.no> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > On the bright side, it should be fairly easy to write an OTP calculator > that run on a cell phone These already exist for J2ME-enabled mobiles (which is most of them?): http://tanso.net/j2me-otp/ http://otp-j2me.sourceforge.net/ > Systems like OPIE, where the challenge is actually issued to the user > and not just to the user's software, require the user to have access to > a response calculator, or to carry a sheet of precalculated responses. There exist apps (i.e., browsers, FTP clients, mailers, etc) that integrate OPIE and can transparently respond to challenges. The user just puts in his password, and he doesn't worry about plaintext or OPIE or whatever; the app just does the right thing. Fetch, an FTP client for the Mac, is one such app. One could argue that this encourages users to just punch in their password and not understand if it's going to go over the wire in the clear or be used to answer a challenge, but it's very useful when you have users who are incapable of making such distinction in the first place and you just need to make sure their password is secure for _your_ service. -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFIc7+YswXMWWtptckRAoaAAJkBnis9pNHnwuXCc6zjqESrDh8zGwCfTYWC 41JZRoD12LhIpG3QK7cfhMU= =w11K -----END PGP SIGNATURE----- From astorms at ncircle.com Tue Jul 8 21:22:14 2008 From: astorms at ncircle.com (Andrew Storms) Date: Tue Jul 8 21:22:21 2008 Subject: BIND update? In-Reply-To: <520b058cebc3f1931fc0b1f66f89c0e0.squirrel@galain.elvandar.org> Message-ID: I agree Remko. I meant this more as of a timing and planning question than a "the sky is falling!". Was curious to know if/when an update might be available so schedules could be set. Thanks. On 7/8/08 2:19 PM, "Remko Lodder" wrote: > > On Tue, July 8, 2008 8:34 pm, Andrew Storms wrote: >> Are going to expect a update for BIND today? >> >> http://www.isc.org/index.pl?/sw/bind/bind-security.php >> >> _______________________________________________ > > Hello, > > I think it's important that we do not overstretch things instantly. The > FreeBSD Security Team is aware of this situation and will investigate how > to do plan and act upon this. > > Thanks, > Remko From remko at elvandar.org Tue Jul 8 21:31:31 2008 From: remko at elvandar.org (Remko Lodder) Date: Tue Jul 8 21:31:38 2008 Subject: BIND update? In-Reply-To: References: Message-ID: <386291aa73945a1cc3559aab7c0a6bb3.squirrel@galain.elvandar.org> On Tue, July 8, 2008 11:22 pm, Andrew Storms wrote: > I agree Remko. I meant this more as of a timing and planning question > than > a "the sky is falling!". Was curious to know if/when an update might be > available so schedules could be set. > > Thanks. > I cannot tell anything yet about a schedule or a plan for updates yet. We (Security Team) first need to investigate what actions are required before we can get to this step. I am sure we will try to resolve this as soon as possible (and send out the word, if needed by an advisory). Thanks, Remko (hat: Secteam) -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From remko at elvandar.org Tue Jul 8 22:00:03 2008 From: remko at elvandar.org (Remko Lodder) Date: Tue Jul 8 22:00:10 2008 Subject: BIND update? In-Reply-To: References: Message-ID: <520b058cebc3f1931fc0b1f66f89c0e0.squirrel@galain.elvandar.org> On Tue, July 8, 2008 8:34 pm, Andrew Storms wrote: > Are going to expect a update for BIND today? > > http://www.isc.org/index.pl?/sw/bind/bind-security.php > > _______________________________________________ Hello, I think it's important that we do not overstretch things instantly. The FreeBSD Security Team is aware of this situation and will investigate how to do plan and act upon this. Thanks, Remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From wxs at FreeBSD.org Tue Jul 8 23:42:55 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Tue Jul 8 23:43:03 2008 Subject: BIND update? In-Reply-To: <386291aa73945a1cc3559aab7c0a6bb3.squirrel@galain.elvandar.org> References: <386291aa73945a1cc3559aab7c0a6bb3.squirrel@galain.elvandar.org> Message-ID: <20080708232946.GB74886@atarininja.org> On Tue, Jul 08, 2008 at 11:31:28PM +0200, Remko Lodder wrote: > > On Tue, July 8, 2008 11:22 pm, Andrew Storms wrote: > > I agree Remko. I meant this more as of a timing and planning question > > than > > a "the sky is falling!". Was curious to know if/when an update might be > > available so schedules could be set. > > > > Thanks. > > > > I cannot tell anything yet about a schedule or a plan for updates yet. We > (Security Team) first need to investigate what actions are required before > we can get to this step. I am sure we will try to resolve this as soon as > possible (and send out the word, if needed by an advisory). It's worth noting the measures mentioned in the advisory. Specifically, restrict recursive queries to only hosts you control. That will help cut down your exposure while work goes forward on addressing this however the security team sees fit. -- WXS From ivangrvr299 at gmail.com Wed Jul 9 06:55:43 2008 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Wed Jul 9 06:55:50 2008 Subject: OPIE Challenge sequence In-Reply-To: <8663rg5qvd.fsf@ds4.des.no> References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> <8663rg5qvd.fsf@ds4.des.no> Message-ID: <670f29e20807082355j590a23aax6335ee3d6480d96b@mail.gmail.com> On Tue, Jul 8, 2008 at 9:07 PM, Dag-Erling Sm?rgrav wrote: > "Ivan Grover" writes: > > Thank you so much for your responses. By "predetermined ", i meant the > > challenges appear sequentially in decremented fashion, so are we aware of > > any security hole with this. > > There is no way to deduce the next challenge from the current one. This > is documented in the opie(4) man page. Just to clarify, I think you are trying to say the next response from the current one, since the challenges are generated somehting like otp-md5 60 lo0245 ext, otp-md5 59 lo0245 ext, otp-md5 58 lo0245 ext,... so on. > > Here's the only advisory I could find for OPIE: > > http://security.freebsd.org/advisories/FreeBSD-SA-06:12.opie.asc > > > I ask this because usually the challenge/response implementations > > consider generating random challenges( i think here they have a > > weakness where the passphrase need to be in clear text). > > OPIE cannot use random challenges, because one of the requirements is > that it should be possible to print a list of pre-generated responses. > > The advantage of OPIE over traditional passwords is that OPIE is not > vulnerable to replay attacks, but this is not as relevant these days as > it was back when S/Key (on which OPIE is based) was designed. Replay > attacks aren't very effective against encrypted protocols such as SSH. > > > My problem is to determine the best challenge/response implementation > > for authenticating the clients. > > Systems like OPIE, where the challenge is actually issued to the user > and not just to the user's software, require the user to have access to > a response calculator, or to carry a sheet of precalculated responses. > The former is difficult unless the users always log in from their own > desktop or laptop computer, and the latter is usually a bad idea since > someone might steel the sheet. On the bright side, it should be fairly > easy to write an OTP calculator that run on a cell phone, such as an > S60-based Nokia phones or an iPhone. > > I'd say that the only advantage of OPIE today is that it's free. > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > From ivangrvr299 at gmail.com Wed Jul 9 08:18:38 2008 From: ivangrvr299 at gmail.com (Ivan Grover) Date: Wed Jul 9 08:18:45 2008 Subject: OPIE Challenge sequence In-Reply-To: References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> <8663rg5qvd.fsf@ds4.des.no> Message-ID: <670f29e20807090118x1f7c4f65v74373fb43b8fe799@mail.gmail.com> Thanks all for your valuable response. Regards, Ivan On Wed, Jul 9, 2008 at 12:57 AM, Jason Stone wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On the bright side, it should be fairly easy to write an OTP calculator >> that run on a cell phone >> > > These already exist for J2ME-enabled mobiles (which is most of them?): > > http://tanso.net/j2me-otp/ > http://otp-j2me.sourceforge.net/ > > > Systems like OPIE, where the challenge is actually issued to the user >> and not just to the user's software, require the user to have access to >> a response calculator, or to carry a sheet of precalculated responses. >> > > There exist apps (i.e., browsers, FTP clients, mailers, etc) that integrate > OPIE and can transparently respond to challenges. The user just puts in his > password, and he doesn't worry about plaintext or OPIE or whatever; the app > just does the right thing. Fetch, an FTP client for the Mac, is one such > app. > > One could argue that this encourages users to just punch in their password > and not understand if it's going to go over the wire in the clear or be used > to answer a challenge, but it's very useful when you have users who are > incapable of making such distinction in the first place and you just need to > make sure their password is secure for _your_ service. > > > -Jason > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (FreeBSD) > Comment: See https://private.idealab.com/public/jason/jason.gpg > > iD8DBQFIc7+YswXMWWtptckRAoaAAJkBnis9pNHnwuXCc6zjqESrDh8zGwCfTYWC > 41JZRoD12LhIpG3QK7cfhMU= > =w11K > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org > " > From des at des.no Wed Jul 9 08:29:18 2008 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Jul 9 08:29:25 2008 Subject: OPIE Challenge sequence In-Reply-To: <670f29e20807082355j590a23aax6335ee3d6480d96b@mail.gmail.com> (Ivan Grover's message of "Wed\, 9 Jul 2008 12\:25\:40 +0530") References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> <20080708113030.GN62764@server.vk2pj.dyndns.org> <670f29e20807080641wb6f76cctfacfbb2af2f4f7e9@mail.gmail.com> <8663rg5qvd.fsf@ds4.des.no> <670f29e20807082355j590a23aax6335ee3d6480d96b@mail.gmail.com> Message-ID: <86od574g0z.fsf@ds4.des.no> "Ivan Grover" writes: > Dag-Erling Sm?rgrav writes: > > There is no way to deduce the next challenge from the current one. > > This is documented in the opie(4) man page. > Just to clarify, I think you are trying to say the next response from > the current one, since the challenges are generated somehting like > otp-md5 60 lo0245 ext, otp-md5 59 lo0245 ext, otp-md5 58 lo0245 > ext,... so on. Yes. DES -- Dag-Erling Sm?rgrav - des@des.no From olli at lurza.secnetix.de Wed Jul 9 10:54:06 2008 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Jul 9 11:36:09 2008 Subject: BIND update? In-Reply-To: Message-ID: <200807091054.m69As4eH065391@lurza.secnetix.de> Andrew Storms wrote: > http://www.isc.org/index.pl?/sw/bind/bind-security.php I'm just wondering ... ISC's patches cause source ports to be randomized, thus making it more difficult to spoof response packets. But doesn't FreeBSD already randomize source ports by default? So, do FreeBSD systems require to be patched at all? Best regards Oliver PS: $ sysctl net.inet.ip.portrange.randomized net.inet.ip.portrange.randomized: 1 $ sysctl -d net.inet.ip.portrange.randomized net.inet.ip.portrange.randomized: Enable random port allocation -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd It's trivial to make fun of Microsoft products, but it takes a real man to make them work, and a God to make them do anything useful. From kimkof at gmail.com Wed Jul 9 12:27:09 2008 From: kimkof at gmail.com (Thomas Beugin) Date: Wed Jul 9 12:27:15 2008 Subject: subsribe Message-ID: <61857c840807090502l4fdcfc93gf4f7470eb0a388d9@mail.gmail.com> -- Cordialement, Beugin Thomas From jille at hexon.cx Wed Jul 9 12:16:17 2008 From: jille at hexon.cx (Jille Timmmermans) Date: Wed Jul 9 12:28:30 2008 Subject: BIND update? In-Reply-To: <200807091054.m69As4eH065391@lurza.secnetix.de> References: <200807091054.m69As4eH065391@lurza.secnetix.de> Message-ID: <4874A864.3080909@hexon.cx> Those sysctl apply to sockets that don't get bind(2), or bind(2) to port 0. (Wild guess ahead!) BIND probably always binds to the same port, or uses the same socket, etc -- Jille Oliver Fromme wrote: > Andrew Storms wrote: > > http://www.isc.org/index.pl?/sw/bind/bind-security.php > > I'm just wondering ... > > ISC's patches cause source ports to be randomized, thus > making it more difficult to spoof response packets. > > But doesn't FreeBSD already randomize source ports by > default? So, do FreeBSD systems require to be patched > at all? > > Best regards > Oliver > > PS: > $ sysctl net.inet.ip.portrange.randomized > net.inet.ip.portrange.randomized: 1 > $ sysctl -d net.inet.ip.portrange.randomized > net.inet.ip.portrange.randomized: Enable random port allocation > > From mike at sentex.net Wed Jul 9 12:38:51 2008 From: mike at sentex.net (Mike Tancsa) Date: Wed Jul 9 12:38:59 2008 Subject: BIND update? In-Reply-To: <200807091054.m69As4eH065391@lurza.secnetix.de> References: <200807091054.m69As4eH065391@lurza.secnetix.de> Message-ID: <200807091209.m69C9Gsl030319@lava.sentex.ca> At 06:54 AM 7/9/2008, Oliver Fromme wrote: >Andrew Storms wrote: > > http://www.isc.org/index.pl?/sw/bind/bind-security.php > >I'm just wondering ... > >ISC's patches cause source ports to be randomized, thus >making it more difficult to spoof response packets. > >But doesn't FreeBSD already randomize source ports by >default? So, do FreeBSD systems require to be patched >at all? It doesnt seem to do a very good job of it with bind for some reason... Perhaps because it picks a port and reuses it ? Doing the following % cat s host 1iatest.yahoo.com host 1iatest2.yahoo.co.uk host 1iatest3.yahoo.com host 1iatest4.yahoo.com host 1iatest4.yahoo.com shows the same source port being used 08:05:44.269507 IP 64.7.134.1.51761 > 203.84.197.239.53: 814% [1au] A? 1iatest.yahoo.com. (46) 08:05:44.595674 IP 203.84.197.239.53 > 64.7.134.1.51761: 814 NXDomain*- 0/1/1 (107) 08:05:44.596251 IP 64.7.134.1.51761 > 199.212.134.1.53: 38272% [1au] A? 1iatest.yahoo.com.sentex.ca. (56) 08:05:44.649672 IP 199.212.134.1.53 > 64.7.134.1.51761: 38272 NXDomain* 0/1/1 (116) 08:05:44.654444 IP 64.7.134.1.51761 > 68.142.196.63.53: 20277% [1au] A? 1iatest2.yahoo.co.uk. (49) 08:05:44.743687 IP 68.142.196.63.53 > 64.7.134.1.51761: 20277*- 1/13/1 CNAME[|domain] 08:05:44.749325 IP 64.7.134.1.51761 > 68.142.255.16.53: 32407% [1au] A? 1iatest3.yahoo.com. (47) 08:05:44.825666 IP 68.142.255.16.53 > 64.7.134.1.51761: 32407 NXDomain*- 0/1/1 (108) 08:05:44.826291 IP 64.7.134.1.51761 > 199.212.134.2.53: 59918% [1au] A? 1iatest3.yahoo.com.sentex.ca. (57) 08:05:44.881667 IP 199.212.134.2.53 > 64.7.134.1.51761: 59918 NXDomain* 0/1/1 (117) 08:05:44.886352 IP 64.7.134.1.51761 > 217.12.4.104.53: 56112% [1au] A? 1iatest4.yahoo.com. (47) 08:05:45.021655 IP 217.12.4.104.53 > 64.7.134.1.51761: 56112 NXDomain*- 0/1/1 (108) 08:05:45.022213 IP 64.7.134.1.51761 > 64.7.153.49.53: 14304% [1au] A? 1iatest4.yahoo.com.sentex.ca. (57) 08:05:45.075656 IP 64.7.153.49.53 > 64.7.134.1.51761: 14304 NXDomain* 0/1/1 (117) and a few min later with new requests, # tcpdump -ni tun0 port 53 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type NULL (BSD loopback), capture size 96 bytes 08:08:00.273502 IP 64.7.134.1.51761 > 68.142.255.16.53: 37470% [1au] A? 21iatest.yahoo.com. (47) 08:08:00.350026 IP 68.142.255.16.53 > 64.7.134.1.51761: 37470 NXDomain*- 0/1/1 (108) 08:08:00.350565 IP 64.7.134.1.51761 > 199.212.134.1.53: 31976% [1au] A? 21iatest.yahoo.com.sentex.ca. (57) 08:08:00.406013 IP 199.212.134.1.53 > 64.7.134.1.51761: 31976 NXDomain* 0/1/1 (117) 08:08:00.410993 IP 64.7.134.1.51761 > 68.142.196.63.53: 2704% [1au] A? 21iatest2.yahoo.co.uk. (50) 08:08:00.500032 IP 68.142.196.63.53 > 64.7.134.1.51761: 2704*- 1/13/1 CNAME[|domain] 08:08:00.505356 IP 64.7.134.1.51761 > 68.142.255.16.53: 33992% [1au] A? 21iatest3.yahoo.com. (48) 08:08:00.582006 IP 68.142.255.16.53 > 64.7.134.1.51761: 33992 NXDomain*- 0/1/1 (109) 08:08:00.582565 IP 64.7.134.1.51761 > 199.212.134.2.53: 18776% [1au] A? 21iatest3.yahoo.com.sentex.ca. (58) 08:08:00.638004 IP 199.212.134.2.53 > 64.7.134.1.51761: 18776 NXDomain* 0/1/1 (118) 08:08:00.642684 IP 64.7.134.1.51761 > 68.142.255.16.53: 54964% [1au] A? 21iatest4.yahoo.com. (48) 08:08:00.720000 IP 68.142.255.16.53 > 64.7.134.1.51761: 54964 NXDomain*- 0/1/1 (109) 08:08:00.720529 IP 64.7.134.1.51761 > 64.7.153.49.53: 11657% [1au] A? 21iatest4.yahoo.com.sentex.ca. (58) 08:08:00.773998 IP 64.7.153.49.53 > 64.7.134.1.51761: 11657 NXDomain* 0/1/1 (118) # sysctl -a net.inet.ip.portrange net.inet.ip.portrange.randomtime: 45 net.inet.ip.portrange.randomcps: 10 net.inet.ip.portrange.randomized: 1 net.inet.ip.portrange.reservedlow: 0 net.inet.ip.portrange.reservedhigh: 1023 net.inet.ip.portrange.hilast: 65535 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.last: 65535 net.inet.ip.portrange.first: 49152 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.lowfirst: 1023 ---Mike >Best regards > Oliver > >PS: >$ sysctl net.inet.ip.portrange.randomized >net.inet.ip.portrange.randomized: 1 >$ sysctl -d net.inet.ip.portrange.randomized >net.inet.ip.portrange.randomized: Enable random port allocation > >-- >Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. >Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: >secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- >chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart > >FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd > >It's trivial to make fun of Microsoft products, >but it takes a real man to make them work, >and a God to make them do anything useful. >_______________________________________________ >freebsd-security@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-security >To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From remko at elvandar.org Wed Jul 9 15:27:45 2008 From: remko at elvandar.org (Remko Lodder) Date: Wed Jul 9 15:28:01 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> Message-ID: <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> On Wed, July 9, 2008 5:19 pm, Josh Mason wrote: > Remko Lodder wrote: >> On Tue, July 8, 2008 8:34 pm, Andrew Storms wrote: >>> Are going to expect a update for BIND today? >>> >>> http://www.isc.org/index.pl?/sw/bind/bind-security.php >>> >>> _______________________________________________ >> >> Hello, >> >> I think it's important that we do not overstretch things instantly. The >> FreeBSD Security Team is aware of this situation and will investigate >> how >> to do plan and act upon this. >> >> Thanks, >> Remko >> Hello Josh, > Right, lets not act swiftly. That would be too much to ask. Is there any > reason why FreeBSD is one of the last vendors to release patches for the > vulnerability? Thanks for taking the time to reply to the thread. Sadly the tone you are using makes me feel a bit sad. There is a deeper reply in the reply you send, and I do not like it. We as the Security Team do our best to act as soon as possible on things. Items like these tend to take up a lot of time and resources, we need to test things properly, make sure all the bits and bytes are OK, so that we don't make people grumpy about things we overlook. I am sure you can understand that and leave away the attitude. > > I apologize, perhaps I should simply do it myself as has been the common > response as of late, or perhaps install from source retrieved from > isc.orgshould be the expected answer? If you want to do that, no one will be stopping you. We as the security team will be working as hard as possible to try and understand the problem, wrap up the correct response and make sure it gets fixed where needed, these things just take time. > > Most other vendors seem to have taken this seriously, yet FreeBSD seems to > be sitting on their hands for some unknown reason while its users remain > vulnerable. We also take this seriously, I think you are short-visioned by telling something like this. There is a mitigation strategy for the BIND issue as already reported on the list. Given your response you must be clever enough to find it. > > Thanks for all the hard work, Thanks for the deeper attitude and the email. I hope you can understand that we are a volunteer organisation which does not have paid people working on items 24/7 which other vendors might have. If you want to have that, I am sure we can get some people so far for getting payed for their normal wages so that we can do that as well. Till that time you should understand volunteer organisations better, or come up with a better proposal you simply don't know how much is involved here. > > Your incredibly loyal follower > Sarcastic. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From wtf.matters at gmail.com Wed Jul 9 15:33:09 2008 From: wtf.matters at gmail.com (Josh Mason) Date: Wed Jul 9 15:48:46 2008 Subject: BIND update? Message-ID: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> Remko Lodder wrote: > On Tue, July 8, 2008 8:34 pm, Andrew Storms wrote: >> Are going to expect a update for BIND today? >> >> http://www.isc.org/index.pl?/sw/bind/bind-security.php >> >> _______________________________________________ > > Hello, > > I think it's important that we do not overstretch things instantly. The > FreeBSD Security Team is aware of this situation and will investigate how > to do plan and act upon this. > > Thanks, > Remko > Right, lets not act swiftly. That would be too much to ask. Is there any reason why FreeBSD is one of the last vendors to release patches for the vulnerability? I apologize, perhaps I should simply do it myself as has been the common response as of late, or perhaps install from source retrieved from isc.orgshould be the expected answer? Most other vendors seem to have taken this seriously, yet FreeBSD seems to be sitting on their hands for some unknown reason while its users remain vulnerable. Thanks for all the hard work, Your incredibly loyal follower From wtf.matters at gmail.com Wed Jul 9 16:09:58 2008 From: wtf.matters at gmail.com (Josh Mason) Date: Wed Jul 9 16:15:22 2008 Subject: BIND update? In-Reply-To: <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> Message-ID: <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> On 7/9/08, Remko Lodder wrote: > > > something like this. There is a mitigation strategy for the BIND issue as > already reported on the list. Given your response you must be clever > enough to find it. Yes, because turning off my name servers is really a solution. This service is already filtered but nothing prevents the thousands of "authorized" hosts from exploiting this vulnerabilty. I'm sure this is true for many other users providing similar services. > > > > Thanks for all the hard work, > > Thanks for the deeper attitude and the email. I hope you can understand > that we are a volunteer organisation which does not have paid people > working on items 24/7 which other vendors might have. If you want to have > that, I am sure we can get some people so far for getting payed for their > normal wages so that we can do that as well. Till that time you should > understand volunteer organisations better, or come up with a better > proposal you simply don't know how much is involved here. So when all else fails claim that we should expect nothing more from volunteers. Message received and understood. We all know how the rest of the opensource operating system community has legions of paid developers. Poor FreeBSD. > > > > Your incredibly loyal follower > > > > Sarcastic. Only in recent months could that be taken sarcastically. You can thank the new direction of the project for that. Josh From peter.thoenen at yahoo.com Wed Jul 9 16:12:59 2008 From: peter.thoenen at yahoo.com (Peter Thoenen) Date: Wed Jul 9 16:15:52 2008 Subject: BIND update? In-Reply-To: <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> Message-ID: <4874DD4B.5020608@yahoo.com> >> Right, lets not act swiftly. That would be too much to ask. Is there any >> reason why FreeBSD is one of the last vendors to release patches for the >> vulnerability? Actually IIRC all the press releases from the *alliance* stated 30 days and as this is a fundamental flaw that has known for the past 6 months and doesn't provide any sort of elevated privileges (or effect those smart enough to run DNSSEC like you should be IIRC) its really not a CRITICAL patch .. its more of a when you get around to it seriously. Let the Security Team do their job and quit pestering them on your now now now next day patch wants for a trivial issue. From wtf.matters at gmail.com Wed Jul 9 16:26:30 2008 From: wtf.matters at gmail.com (Josh Mason) Date: Wed Jul 9 16:35:24 2008 Subject: BIND update? In-Reply-To: <4874DD4B.5020608@yahoo.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <4874DD4B.5020608@yahoo.com> Message-ID: <17cd1fbe0807090926g21ef35e7l10e4a6e38ad3d10@mail.gmail.com> On 7/9/08, Peter Thoenen wrote: > > > > > > Right, lets not act swiftly. That would be too much to ask. Is there any > > > reason why FreeBSD is one of the last vendors to release patches for the > > > vulnerability? > > > > > > > Actually IIRC all the press releases from the *alliance* stated 30 days and as this is a fundamental flaw that has known for the past 6 months and doesn't provide any sort of elevated privileges (or effect those smart enough to run DNSSEC like you should be IIRC) its really not a CRITICAL patch .. its more of a when you get around to it seriously. Let the Security Team do their job and quit pestering them on your now now now next day patch wants for a trivial issue. > Somehow this totally unimportant vulnerability caught the attention of all major vendors to issue a synchronized release of the fix. Yet, it's not worth our time to implement expeditiously... ? Sure. I agree, I should definitely enable DNSSEC. If for nothing other than the fact that it was vulnerable ~6 months ago - let me give myself yet another thing to wait for a fix on. Hurm,.. turn off DNSSEC while you wait for a patch,.. turn on DNSSEC while you wait for a patch. And lastly - you're absolutely correct. My servers won't be compromised directly by this bug so I shouldn't care when I implement the fix. Thanks for your input. Josh P.S. It almost seemed as though you were saying that because something has been known for months but the fix was just released means that there's little importance to implement it swiftly. I like your logic - or did I miss understand you somehow? From remko at elvandar.org Wed Jul 9 16:52:47 2008 From: remko at elvandar.org (Remko Lodder) Date: Wed Jul 9 16:52:55 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> Message-ID: <4874ECDA.60202@elvandar.org> Josh Mason wrote: Thanks, you really showed how you are by sending these replies. I wish you goodluck with your quest, perhaps someday someone can help you. Goodbye. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From killing at multiplay.co.uk Wed Jul 9 16:59:29 2008 From: killing at multiplay.co.uk (Steven Hartland) Date: Wed Jul 9 16:59:37 2008 Subject: BIND update? References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com><3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org><4874DD4B.5020608@yahoo.com> <17cd1fbe0807090926g21ef35e7l10e4a6e38ad3d10@mail.gmail.com> Message-ID: <10E6A49CB7E7499589E03D92390A8129@multiplay.co.uk> ----- Original Message ----- From: "Josh Mason" > P.S. It almost seemed as though you were saying that because something > has been known for months but the fix was just released means that > there's little importance to implement it swiftly. I like your logic - > or did I miss understand you somehow? Can we stop the sniping and just let the sec team do their job without the snide comments. If you want a fix urgently you have options, if not just sit tight and wait for the announcement. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From tevans.uk at googlemail.com Wed Jul 9 17:18:55 2008 From: tevans.uk at googlemail.com (Tom Evans) Date: Wed Jul 9 17:19:02 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> Message-ID: <1215622380.35536.71.camel@localhost> On Wed, 2008-07-09 at 12:09 -0400, Josh Mason wrote: > So when all else fails claim that we should expect nothing more from > volunteers. Message received and understood. > > We all know how the rest of the opensource operating system community > has legions of paid developers. Poor FreeBSD. Are you ignoring the large number of full time developers employed by redhat and their ilk? This means they are a company delivering a product, supported by full time developers, who are paid out of support contracts. This is why redhat is described as a 'vendor'; they sell you stuff. FreeBSD is a volunteer project. This means that there is no-one at all who is paid by FreeBSD to write code for FreeBSD. If this doesn't fit your needs, perhaps you need to re-evaluate your choices. My 2 cents.. Tom Evans -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080709/73f5f86b/attachment.pgp From wxs at FreeBSD.org Wed Jul 9 17:41:16 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jul 9 17:41:27 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807090926g21ef35e7l10e4a6e38ad3d10@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <4874DD4B.5020608@yahoo.com> <17cd1fbe0807090926g21ef35e7l10e4a6e38ad3d10@mail.gmail.com> Message-ID: <20080709174341.GF92109@atarininja.org> On Wed, Jul 09, 2008 at 12:26:29PM -0400, Josh Mason wrote: > On 7/9/08, Peter Thoenen wrote: > > > > > > > > > Right, lets not act swiftly. That would be too much to ask. Is > > > > there any reason why FreeBSD is one of the last vendors to > > > > release patches for the vulnerability? > > > > > > > > > > > Actually IIRC all the press releases from the *alliance* stated 30 > > days and as this is a fundamental flaw that has known for the past 6 > > months and doesn't provide any sort of elevated privileges (or > > effect those smart enough to run DNSSEC like you should be IIRC) its > > really not a CRITICAL patch .. its more of a when you get around to > > it seriously. Let the Security Team do their job and quit pestering > > them on your now now now next day patch wants for a trivial issue. > > > > Somehow this totally unimportant vulnerability caught the attention of > all major vendors to issue a synchronized release of the fix. Yet, > it's not worth our time to implement expeditiously... ? Sure. Given the tone of your words, it seems you are fixated on getting people to work _against_ you rather than _with_ you on this issue. I'd like to point out the list of vendors/projects (as someone has pointed out the difference between the two later in this thread) is available at http://www.kb.cert.org/vuls/id/800113. Total entries on that list: 81 Total entries marked as "unknown": 70 That means 11 out of 81 entries were able to determine the status of their product/code before the advisory went public. Here's that list, please note I trimmed the vulnerable/not vulnerable status: Cisco Systems, Inc. Debian GNU/Linux Foundry Networks, Inc. Infoblox Internet Software Consortium Juniper Networks, Inc. Microsoft Corporation Nominum PowerDNS Red Hat, Inc. Sun Microsystems, Inc. With the (possible?) exception of Debian, every one of the 11 listed there have people who are paid to do these things. I think people have jumped on you enough about that fact so I'll leave it alone. What's more important is that we not panic, especially since _public_ details are very sparse. There are mitigations that are mentioned in that report, along with elsewhere. Putting these mitigations in place, if necessary, is your best option while those entrusted to do the work are doing said work to make sure we have a co-ordinated and accurate response. Please, find a way to contribute in a meaningful manner since the tone of your statements is only serving to harm your cause. -- WXS From wtf.matters at gmail.com Wed Jul 9 17:27:07 2008 From: wtf.matters at gmail.com (Josh Mason) Date: Wed Jul 9 17:58:43 2008 Subject: BIND update? In-Reply-To: <4874F149.1040101@FreeBSD.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> Message-ID: <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> On 7/9/08, Remko Lodder wrote: > Remko Lodder wrote: > > Josh Mason wrote: > > > > Thanks, you really showed how you are by sending these replies. I wish you > goodluck with your quest, perhaps someday someone can help you. > > > > Goodbye. > > > > > > Hi, > > I am sorry for this reply, it was an expression of my frustation towards > you. The frustation is just easily generated by people demanding support > from volunteers, that are trying to service you and others in their own > spare time. Time that they can also spend on different items, yet we > crazy people decide to work on a Free Operating System, getting nothing > payed for it, only happy users (Where possible) around us. > > I think you can understand my frustration, because I think you would reply > the same if someone demanded even more free time from you. > > I hope you can understand this. > > //Remko > I completely understand and took no offence from your previous email - I know I am being confrontational. I myself have been in that position many a time before and know exactly how it feels. Unfortunately that doesn't negate the responsibility of the security team to produce patches quickly. The initial response of "the sec team is aware of the situation and will investigate" was basically just fluff. If you weren't already aware of it you aren't much of a sec team. What is needed is an expected delivery. I would say considering the nature of the exploit but honestly that shouldn't change anything at all. If the delivery isn't going to be immediate there should always be an ETA provided. If for nothing else other than so your users can plan around it (i.e. "this is too long I need to take action myself" - "or X time or date is sufficient I'll wait for the official release and apply it then"). Without that people are twiddling their thumbs wondering if there is ever going to be one. Josh From remko at FreeBSD.org Wed Jul 9 17:30:02 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Wed Jul 9 17:58:52 2008 Subject: BIND update? In-Reply-To: <4874ECDA.60202@elvandar.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> Message-ID: <4874F149.1040101@FreeBSD.org> Remko Lodder wrote: > Josh Mason wrote: > > Thanks, you really showed how you are by sending these replies. I wish > you goodluck with your quest, perhaps someday someone can help you. > > Goodbye. > Hi, I am sorry for this reply, it was an expression of my frustation towards you. The frustation is just easily generated by people demanding support from volunteers, that are trying to service you and others in their own spare time. Time that they can also spend on different items, yet we crazy people decide to work on a Free Operating System, getting nothing payed for it, only happy users (Where possible) around us. I think you can understand my frustration, because I think you would reply the same if someone demanded even more free time from you. I hope you can understand this. //Remko From wxs at FreeBSD.org Wed Jul 9 18:12:50 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jul 9 18:12:57 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> Message-ID: <20080709181515.GG92109@atarininja.org> On Wed, Jul 09, 2008 at 01:27:06PM -0400, Josh Mason wrote: > On 7/9/08, Remko Lodder wrote: > > Remko Lodder wrote: > > > Josh Mason wrote: > > > > > > Thanks, you really showed how you are by sending these replies. I wish you > > goodluck with your quest, perhaps someday someone can help you. > > > > > > Goodbye. > > > > > > > > > > Hi, > > > > I am sorry for this reply, it was an expression of my frustation towards > > you. The frustation is just easily generated by people demanding support > > from volunteers, that are trying to service you and others in their own > > spare time. Time that they can also spend on different items, yet we > > crazy people decide to work on a Free Operating System, getting nothing > > payed for it, only happy users (Where possible) around us. > > > > I think you can understand my frustration, because I think you would reply > > the same if someone demanded even more free time from you. > > > > I hope you can understand this. > > > > //Remko > > > > I completely understand and took no offence from your previous email - > I know I am being confrontational. I myself have been in that position > many a time before and know exactly how it feels. Unfortunately that > doesn't negate the responsibility of the security team to produce > patches quickly. > > The initial response of "the sec team is aware of the situation and > will investigate" was basically just fluff. If you weren't already > aware of it you aren't much of a sec team. What is needed is an > expected delivery. I would say considering the nature of the exploit > but honestly that shouldn't change anything at all. If the delivery > isn't going to be immediate there should always be an ETA provided. If > for nothing else other than so your users can plan around it (i.e. > "this is too long I need to take action myself" - "or X time or date > is sufficient I'll wait for the official release and apply it then"). > Without that people are twiddling their thumbs wondering if there is > ever going to be one. You have a good point there. I'm not aware of any page which describes the current issues under investigation by the security team. If such a thing does not exist I think it would be a good thing to have, especially if it details rough timelines for things. By that I mean recording historic information and expected information (we received notification on this date, we expect to have a final advisory on this date). In the security world there is a balance which must be maintained between providing information to consumers so that they may plan accordingly, and not providing too much information so that the attackers can write exploits; this is the sensitive nature of the information which often leads to opaque processes by security teams around the world. There is the case where full details are released without advance notice to the vendors/projects, in which case the balance has been lost from the start. Remko, do you - or anyone else - on the security team have any thoughts on this? I'd be willing to step up and keep a wiki page (or something else) up to date with the information. -- WXS From remko at FreeBSD.org Wed Jul 9 18:17:16 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Wed Jul 9 18:20:18 2008 Subject: BIND update? In-Reply-To: <20080709181515.GG92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> Message-ID: <487500A6.2030001@FreeBSD.org> Wesley Shields wrote: > On Wed, Jul 09, 2008 at 01:27:06PM -0400, Josh Mason wrote: >> On 7/9/08, Remko Lodder wrote: >>> Remko Lodder wrote: >>>> Josh Mason wrote: >>>> >>>> Thanks, you really showed how you are by sending these replies. I wish you >>> goodluck with your quest, perhaps someday someone can help you. >>>> Goodbye. >>>> >>>> >>> Hi, >>> >>> I am sorry for this reply, it was an expression of my frustation towards >>> you. The frustation is just easily generated by people demanding support >>> from volunteers, that are trying to service you and others in their own >>> spare time. Time that they can also spend on different items, yet we >>> crazy people decide to work on a Free Operating System, getting nothing >>> payed for it, only happy users (Where possible) around us. >>> >>> I think you can understand my frustration, because I think you would reply >>> the same if someone demanded even more free time from you. >>> >>> I hope you can understand this. >>> >>> //Remko >>> >> I completely understand and took no offence from your previous email - >> I know I am being confrontational. I myself have been in that position >> many a time before and know exactly how it feels. Unfortunately that >> doesn't negate the responsibility of the security team to produce >> patches quickly. >> >> The initial response of "the sec team is aware of the situation and >> will investigate" was basically just fluff. If you weren't already >> aware of it you aren't much of a sec team. What is needed is an >> expected delivery. I would say considering the nature of the exploit >> but honestly that shouldn't change anything at all. If the delivery >> isn't going to be immediate there should always be an ETA provided. If >> for nothing else other than so your users can plan around it (i.e. >> "this is too long I need to take action myself" - "or X time or date >> is sufficient I'll wait for the official release and apply it then"). >> Without that people are twiddling their thumbs wondering if there is >> ever going to be one. > > You have a good point there. I'm not aware of any page which describes > the current issues under investigation by the security team. If such a > thing does not exist I think it would be a good thing to have, > especially if it details rough timelines for things. By that I mean > recording historic information and expected information (we received > notification on this date, we expect to have a final advisory on this > date). > > In the security world there is a balance which must be maintained > between providing information to consumers so that they may plan > accordingly, and not providing too much information so that the > attackers can write exploits; this is the sensitive nature of the > information which often leads to opaque processes by security teams > around the world. There is the case where full details are released > without advance notice to the vendors/projects, in which case the > balance has been lost from the start. > > Remko, do you - or anyone else - on the security team have any thoughts > on this? I'd be willing to step up and keep a wiki page (or something > else) up to date with the information. > > -- WXS There will be no such page with information about pending items. Sometimes we are bound to non-disclosures etc. We handle this internally and will continue to do so. If people cannot live with that (like Josh) then that's their challenge. Note I speak largely for myself in this case. I am not going to support a wiki page or something. I do not know what the other secteam members think about that, but I expect something like my opinion. //Remko -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From wxs at FreeBSD.org Wed Jul 9 18:28:25 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jul 9 18:28:32 2008 Subject: BIND update? In-Reply-To: <487500A6.2030001@FreeBSD.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <487500A6.2030001@FreeBSD.org> Message-ID: <20080709183051.GH92109@atarininja.org> On Wed, Jul 09, 2008 at 08:17:10PM +0200, Remko Lodder wrote: > Wesley Shields wrote: > > On Wed, Jul 09, 2008 at 01:27:06PM -0400, Josh Mason wrote: > >> On 7/9/08, Remko Lodder wrote: > >>> Remko Lodder wrote: > >>>> Josh Mason wrote: > >>>> > >>>> Thanks, you really showed how you are by sending these replies. I wish you > >>> goodluck with your quest, perhaps someday someone can help you. > >>>> Goodbye. > >>>> > >>>> > >>> Hi, > >>> > >>> I am sorry for this reply, it was an expression of my frustation towards > >>> you. The frustation is just easily generated by people demanding support > >>> from volunteers, that are trying to service you and others in their own > >>> spare time. Time that they can also spend on different items, yet we > >>> crazy people decide to work on a Free Operating System, getting nothing > >>> payed for it, only happy users (Where possible) around us. > >>> > >>> I think you can understand my frustration, because I think you would reply > >>> the same if someone demanded even more free time from you. > >>> > >>> I hope you can understand this. > >>> > >>> //Remko > >>> > >> I completely understand and took no offence from your previous email - > >> I know I am being confrontational. I myself have been in that position > >> many a time before and know exactly how it feels. Unfortunately that > >> doesn't negate the responsibility of the security team to produce > >> patches quickly. > >> > >> The initial response of "the sec team is aware of the situation and > >> will investigate" was basically just fluff. If you weren't already > >> aware of it you aren't much of a sec team. What is needed is an > >> expected delivery. I would say considering the nature of the exploit > >> but honestly that shouldn't change anything at all. If the delivery > >> isn't going to be immediate there should always be an ETA provided. If > >> for nothing else other than so your users can plan around it (i.e. > >> "this is too long I need to take action myself" - "or X time or date > >> is sufficient I'll wait for the official release and apply it then"). > >> Without that people are twiddling their thumbs wondering if there is > >> ever going to be one. > > > > You have a good point there. I'm not aware of any page which describes > > the current issues under investigation by the security team. If such a > > thing does not exist I think it would be a good thing to have, > > especially if it details rough timelines for things. By that I mean > > recording historic information and expected information (we received > > notification on this date, we expect to have a final advisory on this > > date). > > > > In the security world there is a balance which must be maintained > > between providing information to consumers so that they may plan > > accordingly, and not providing too much information so that the > > attackers can write exploits; this is the sensitive nature of the > > information which often leads to opaque processes by security teams > > around the world. There is the case where full details are released > > without advance notice to the vendors/projects, in which case the > > balance has been lost from the start. > > > > Remko, do you - or anyone else - on the security team have any thoughts > > on this? I'd be willing to step up and keep a wiki page (or something > > else) up to date with the information. > > > > -- WXS > > There will be no such page with information about pending items. > Sometimes we are bound to non-disclosures etc. We handle this internally > and will continue to do so. If people cannot live with that (like Josh) > then that's their challenge. > > Note I speak largely for myself in this case. I am not going to support > a wiki page or something. I do not know what the other secteam members > think about that, but I expect something like my opinion. That's certainly a fair statement. I understand the non-disclosure aspect of the situation, but I also feel a more transparent process where ever possible is a good idea. I suspect more thought on the matter is necessary. -- WXS From booloo at ucsc.edu Wed Jul 9 18:29:08 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Wed Jul 9 18:29:14 2008 Subject: BIND update? Message-ID: <20080709182906.GA67970@root.ucsc.edu> I hope I can distance myself from Josh in terms of tone. I think he's completely out of line with his snotty posts. That said, I think there is a legitimate question here. I'm interested in this issue, because it sounds as if FreeBSD folk didn't become aware of this problem until the announcement. I would have expected ISC to notify you ahead of the announcement. The patched code has been available to some for several weeks (at least). I was anticipating seeing everyone pushing patched code out on the same day. > That means 11 out of 81 entries were able to determine the status of > their product/code before the advisory went public. Here's that list, > please note I trimmed the vulnerable/not vulnerable status: Of course, any vendor running vanilla BIND would be vulnerable. > What's more important is that we not panic, especially since _public_ > details are very sparse. There are mitigations that are mentioned in > that report, along with elsewhere. Putting these mitigations in place, > if necessary, is your best option while those entrusted to do the work > are doing said work to make sure we have a co-ordinated and accurate > response. There really aren't any effective mitigations for folks running resolvers. Patched code to implement source port randomization is our only hope. Of course, that code exists and is available from ISC, and it will work fine under FreeBSD, so there is clearly a path forward. I think it might have been helpful (and still might be) if the security officer had pushed out a notification of 'work underway' with some possible indication as to when a fix might be available. I realize that providing a date might be extraordinarily difficult, but it helps inform planning for FreeBSD users (and, of course, gives us something to kvetch about when the date slips :-) I appreciate the FreeBSD security team efforts and will happily buy you guys beer (or other beverage of choice) any time we're in the same room together. mark From tedm at ipinc.net Wed Jul 9 18:22:17 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed Jul 9 18:29:49 2008 Subject: Here is how to fix your nameserver - was Re: BIND update? Message-ID: Hi All, First, knock off the goddam posturing. Second, named is statically linked, so there is NO BIG FRAGGING DEAL with upgrading your nameserver. Here is how you do it: System: FreeBSD 6.3-RELEASE used as a nameserver Login and su to root cd /usr/ports/distfiles mkdir manual-build cd manual-build fetch http://ftp.isc.org/isc/bind9/9.3.5-P1/bind-9.3.5-P1.tar.gz gunzip bind-9.3.5-P1.tar tar xf bind-9.3.5-P1.tar cd bind-9.3.5-P1 ./configure --disable-openssl-version-check (NOTE: The OpenSSL included with FreeBSD 6.3-RELEASE is vulnerable to 4 security notifications, you should have patched it already) make rndc stop cd ./bin/named chmod u-w named mv /usr/sbin/named /usr/sbin/named.original mv named /usr/sbin/named cd .. cd rndc mv /usr/sbin/rndc /usr/sbin/rndc.original mv rndc /usr/sbin/rndc /usr/sbin/named -4 -c /etc/namedb/named.conf -t /var/named -u root tail /var/log/messages make sure messages has: starting BIND 9.3.5-P1 -4 -c /etc/namedb/named.conf -t /var/named -u root in it nslookup www.freebsd.org (tests) your done! named and rndc are both compiled with static libraries: liblwres.a libdns.a libbind9.a libisccfg.a libisccc.a libisc.a so there is no need to go replacing all of the resolver libraries and recompiling all the applications. The bug DOES NOT affect client applications that use the resolver libraries. This will get you going until FBSD 6.4 is out. Ted Mittelstaedt Author: The FreeBSD Corporate Networker's Guide From booloo at ucsc.edu Wed Jul 9 18:30:40 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Wed Jul 9 18:30:47 2008 Subject: BIND update? In-Reply-To: <20080709174341.GF92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <4874DD4B.5020608@yahoo.com> <17cd1fbe0807090926g21ef35e7l10e4a6e38ad3d10@mail.gmail.com> <20080709174341.GF92109@atarininja.org> Message-ID: <20080709181519.GA67356@root.ucsc.edu> I hope I can distance myself from Josh in terms of tone. I think he's completely out of line with his snotty posts. That said, I think there is a legitimate question here. I'm interested in this issue, because it sounds as if FreeBSD folk didn't become aware of this problem until the announcement. I would have expected ISC to notify you ahead of the announcement. The patched code has been available to some for several weeks (at least). I was anticipating seeing everyone pushing patched code out on the same day. > That means 11 out of 81 entries were able to determine the status of > their product/code before the advisory went public. Here's that list, > please note I trimmed the vulnerable/not vulnerable status: Of course, any vendor running vanilla BIND would be vulnerable. > What's more important is that we not panic, especially since _public_ > details are very sparse. There are mitigations that are mentioned in > that report, along with elsewhere. Putting these mitigations in place, > if necessary, is your best option while those entrusted to do the work > are doing said work to make sure we have a co-ordinated and accurate > response. There really aren't any effective mitigations for folks running resolvers. Patched code to implement source port randomization is our only hope. Of course, that code exists and is available from ISC, and it will work fine under FreeBSD, so there is clearly a path forward. I think it might have been helpful (and still might be) if the security officer had pushed out a notification of 'work underway' with some possible indication as to when a fix might be available. I realize that providing a date might be extraordinarily difficult, but it helps inform planning for FreeBSD users (and, of course, gives us something to kvetch about when the date slips :-) I appreciate the FreeBSD security team efforts and will happily buy you guys beer (or other beverage of choice) any time we're in the same room together. mark From chris at noncombatant.org Wed Jul 9 18:38:30 2008 From: chris at noncombatant.org (Chris Palmer) Date: Wed Jul 9 18:38:37 2008 Subject: BIND update? In-Reply-To: <20080709181515.GG92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> Message-ID: <20080709183325.GE55473@noncombatant.org> Wesley Shields writes: > In the security world there is a balance which must be maintained between > providing information to consumers so that they may plan accordingly, and > not providing too much information so that the attackers can write > exploits; this is the sensitive nature of the information which often > leads to opaque processes by security teams around the world. http://en.wikipedia.org/wiki/Kerckhoffs'_principle Malware authors create exploits based on information they gleaned by reverse engineering the binary patches released by Microsoft. They are able to get these exploits into the wild before everyone has even had a chance to apply the patches, even though the patching is (semi-)automated. Not only is there no security through obscurity, there isn't even any obscurity. :) From remko at FreeBSD.org Wed Jul 9 18:29:32 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Wed Jul 9 18:42:05 2008 Subject: BIND update? In-Reply-To: <20080709183051.GH92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <487500A6.2030001@FreeBSD.org> <20080709183051.GH92109@atarininja.org> Message-ID: <48750387.60002@FreeBSD.org> Wesley Shields wrote: >> There will be no such page with information about pending items. >> Sometimes we are bound to non-disclosures etc. We handle this internally >> and will continue to do so. If people cannot live with that (like Josh) >> then that's their challenge. >> >> Note I speak largely for myself in this case. I am not going to support >> a wiki page or something. I do not know what the other secteam members >> think about that, but I expect something like my opinion. > > That's certainly a fair statement. I understand the non-disclosure > aspect of the situation, but I also feel a more transparent process > where ever possible is a good idea. I suspect more thought on the > matter is necessary. > > -- WXS I think we can better spend time on improving VuXML entries then spending more time on considerations of this topic. Please close it and move along. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From chris at noncombatant.org Wed Jul 9 18:43:30 2008 From: chris at noncombatant.org (Chris Palmer) Date: Wed Jul 9 18:43:51 2008 Subject: BIND update? In-Reply-To: <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> Message-ID: <20080709182340.GD55473@noncombatant.org> Okay everybody, take a step back, take a deep breath, and count to ten. :) DNS has never provided any security guarantees, and so a marginal increase or decrease in the difficulty of spoofing responses is not a huge issue in the grand scheme of things. Even if the 16 bits were somehow pure delicious entropy, it would still only be 16 bits. If you want to provide DNS service yet minimize the risk to the server, BIND should never have been your first choice. It has a rough history, and there are more secure alternatives. Some people like BIND anyway. Cool. They accept that risk. DNSSEC is not widely deployed; and if it were, would that matter? Would you securely resolve important.example.com, only to talk to that host via HTTP? HTTP, like DNS, has never provided any security guarantees. It's not clear that, given correct authentication of important.example.com via X509 cert and a trusted third party (or by careful examination of the known-good fingerprint), "secure" DNS would provide any additional server authentication. Granted, I say "given correct authentication of important.example.com via X509 cert" as if that were easy. ;) In any case, that is all we have in the real world today. See also: SSH host keys. So I'm not too worried about the lack of urgency from the FreeBSD security team on this particular issue. It's not news that DNS is insecure and that BIND has a bug. Nobody should have been depending on the security of DNS or on a bulletproof BIND. From wxs at FreeBSD.org Wed Jul 9 18:51:39 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jul 9 18:51:45 2008 Subject: BIND update? In-Reply-To: <20080709183325.GE55473@noncombatant.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <20080709183325.GE55473@noncombatant.org> Message-ID: <20080709185405.GJ92109@atarininja.org> On Wed, Jul 09, 2008 at 11:33:25AM -0700, Chris Palmer wrote: > Wesley Shields writes: > > > In the security world there is a balance which must be maintained between > > providing information to consumers so that they may plan accordingly, and > > not providing too much information so that the attackers can write > > exploits; this is the sensitive nature of the information which often > > leads to opaque processes by security teams around the world. > > http://en.wikipedia.org/wiki/Kerckhoffs'_principle > > Malware authors create exploits based on information they gleaned by reverse > engineering the binary patches released by Microsoft. They are able to get > these exploits into the wild before everyone has even had a chance to apply > the patches, even though the patching is (semi-)automated. I'm well aware of that, as I have many friends who do this for a living (legitimate businesses). I'm also not sure how this applies since the project is open source - the fix is published at the time of the patch, so there's no reverse engineering to do. If anything this illustrates that patches should be applied in a timely manner in an open source project, since the window you are describing is effectively zero. > Not only is there no security through obscurity, there isn't even any > obscurity. :) The point is to not give hints about where in the code the problem lies while at least being able to give the consumers of FreeBSD a chance to plan around any potential bugs. Given the sensitive nature of the issue, and the fact that some things are under NDA, I'm not entirely sure it is a good idea. I'd like to see a more transparent process without causing any harm to it, but I'm not sure how to do that right now. Despite me wanting to see this happen I think these issues are too big to overcome without more thought. I'm considering this issue closed for now. -- WXS From tedm at ipinc.net Wed Jul 9 18:46:10 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed Jul 9 18:52:20 2008 Subject: Here is how to fix your nameserver - was Re: BIND update? Message-ID: <26A784931556478F8BB9615AA6408FFA@tedsdesk> Hi All, OK, slight addition to this: > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm@ipinc.net] > Sent: Wednesday, July 09, 2008 10:59 AM > To: 'freebsd-security@freebsd.org' > Subject: Here is how to fix your nameserver - was Re: BIND update? > > > > > System: FreeBSD 6.3-RELEASE used as a nameserver > > Login and su to root > > cd /usr/ports/distfiles > > mkdir manual-build > > cd manual-build > > fetch http://ftp.isc.org/isc/bind9/9.3.5-P1/bind-9.3.5-P1.tar.gz > > gunzip bind-9.3.5-P1.tar > > tar xf bind-9.3.5-P1.tar > > cd bind-9.3.5-P1 > > ./configure --disable-openssl-version-check (NOTE: The > OpenSSL included with FreeBSD 6.3-RELEASE is vulnerable to 4 > security notifications, you should have patched it already) > > make > > rndc stop > > cd ./bin/named > > chmod u-w named > > mv /usr/sbin/named /usr/sbin/named.original > > mv named /usr/sbin/named > > cd .. > > cd rndc > > mv /usr/sbin/rndc /usr/sbin/rndc.original > mv rndc /usr/sbin/rndc > cd /var/named/etc cp /var/named/etc/namedb/rndc.key . > /usr/sbin/named -4 -c /etc/namedb/named.conf -t /var/named -u root > > tail /var/log/messages > > make sure messages has: > starting BIND 9.3.5-P1 -4 -c /etc/namedb/named.conf -t > /var/named -u root in it > > nslookup www.freebsd.org > (tests) > > your done! > > named and rndc are both compiled with static libraries: > liblwres.a libdns.a libbind9.a libisccfg.a libisccc.a libisc.a > > so there is no need to go replacing all of the resolver > libraries and recompiling all the applications. The bug DOES > NOT affect client applications that use the resolver libraries. > > This will get you going until FBSD 6.4 is out. > > > Ted Mittelstaedt > Author: The FreeBSD Corporate Networker's Guide > > From wxs at FreeBSD.org Wed Jul 9 18:55:07 2008 From: wxs at FreeBSD.org (Wesley Shields) Date: Wed Jul 9 18:55:14 2008 Subject: BIND update? In-Reply-To: <20080709185405.GJ92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <20080709183325.GE55473@noncombatant.org> <20080709185405.GJ92109@atarininja.org> Message-ID: <20080709185732.GK92109@atarininja.org> On Wed, Jul 09, 2008 at 02:54:05PM -0400, Wesley Shields wrote: > On Wed, Jul 09, 2008 at 11:33:25AM -0700, Chris Palmer wrote: > > Wesley Shields writes: > > > > > In the security world there is a balance which must be maintained between > > > providing information to consumers so that they may plan accordingly, and > > > not providing too much information so that the attackers can write > > > exploits; this is the sensitive nature of the information which often > > > leads to opaque processes by security teams around the world. > > > > http://en.wikipedia.org/wiki/Kerckhoffs'_principle > > > > Malware authors create exploits based on information they gleaned by reverse > > engineering the binary patches released by Microsoft. They are able to get > > these exploits into the wild before everyone has even had a chance to apply > > the patches, even though the patching is (semi-)automated. > > I'm well aware of that, as I have many friends who do this for a living > (legitimate businesses). I'm also not sure how this applies since the > project is open source - the fix is published at the time of the patch, > so there's no reverse engineering to do. If anything this illustrates > that patches should be applied in a timely manner in an open source > project, since the window you are describing is effectively zero. > > > Not only is there no security through obscurity, there isn't even any > > obscurity. :) > > The point is to not give hints about where in the code the problem lies > while at least being able to give the consumers of FreeBSD a chance to > plan around any potential bugs. Given the sensitive nature of the > issue, and the fact that some things are under NDA, I'm not entirely > sure it is a good idea. I'd like to see a more transparent process > without causing any harm to it, but I'm not sure how to do that right > now. > > Despite me wanting to see this happen I think these issues are too big > to overcome without more thought. I'm considering this issue closed for > now. Oh, and as I've stated to Remko privately: I think the security team is doing a good job. I, in no way, mean to suggest otherwise. I'm just trying to allow the consumers of FreeBSD a bit of wiggle room with regards to planning. ;) -- WXS From jason at shalott.net Wed Jul 9 18:49:26 2008 From: jason at shalott.net (Jason Stone) Date: Wed Jul 9 19:29:57 2008 Subject: BIND update? In-Reply-To: <4874DD4B.5020608@yahoo.com> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <4874DD4B.5020608@yahoo.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't agree with the criticism of the security team; it takes a lot of time to test things and make sure that changes and patches work within the larger context of a complete system. And what I like about FreeBSD is that it's a complete system, not just a collection of disjoint parts like some other popular unix-like systems out there.... However, I also don't agree with this: > its really not a CRITICAL patch .. its more of a when you get around to > it seriously. CERT and others have been saying for years that protecting DNS infrastructure is a critical component in protecting the security of the entire internet, and I strongly agree. DNS spoofing and cache poisoning are an big part of how Windows boxes get rooted, and a more robust DNS infrastructure might go a long way in slowing the spread of the zombie armies. Many folks in the hosting world use BIND on FreeBSD to provide DNS resolvers for their clients, and this is _not_ a trivial issue for them. -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFIdQOFswXMWWtptckRAlgBAJ9fyqJomRiszRJuub6blvV+uXv4RgCg8Q3E wVqCrYVcKV7PjTHSyGuCyGY= =ZU6f -----END PGP SIGNATURE----- From remko at FreeBSD.org Wed Jul 9 19:05:32 2008 From: remko at FreeBSD.org (Remko Lodder) Date: Wed Jul 9 19:42:18 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] Message-ID: <48750BF7.5040402@FreeBSD.org> Dear all, Doug just updated the ports tree with the updated BIND ports. If you urgently want to upgrade and really cannot wait for the advisory. Please use the ports system to get up to speed. Thanks Doug for working on this on such short notice! Cheers, remko -------- Original Message -------- Subject: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo Date: Wed, 9 Jul 2008 19:02:01 +0000 (UTC) From: Doug Barton To: ports-committers@FreeBSD.org, cvs-ports@FreeBSD.org, cvs-all@FreeBSD.org dougb 2008-07-09 19:02:01 UTC FreeBSD ports repository Modified files: dns/bind9 Makefile distinfo dns/bind94 Makefile distinfo dns/bind95 Makefile distinfo Log: Upgrade to the -P1 versions of each port, which add stronger randomization of the UDP query-source ports. The server will still use the same query port for the life of the process, so users for whom the issue of cache poisoning is highly significant may wish to periodically restart their server using /etc/rc.d/named restart, or other suitable method. In order to take advantage of this randomization users MUST have an appropriate firewall configuration to allow UDP queries to be sent and answers to be received on random ports; and users MUST NOT specify a port number using the query-source[-v6] option. The avoid-v[46]-udp-ports options exist for users who wish to eliminate certain port numbers from being chosen by named for this purpose. See the ARM Chatper 6 for more information. Also please note, this issue applies only to UDP query ports. A random ephemeral port is always chosen for TCP queries. This issue applies primarily to name servers whose main purpose is to resolve random queries (sometimes referred to as "caching" servers, or more properly as "resolving" servers), although even an "authoritative" name server will make some queries, primarily at startup time. This update addresses issues raised in: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience Revision Changes Path 1.82 +2 -2 ports/dns/bind9/Makefile 1.44 +6 -6 ports/dns/bind9/distinfo 1.85 +2 -3 ports/dns/bind94/Makefile 1.47 +6 -6 ports/dns/bind94/distinfo 1.87 +2 -2 ports/dns/bind95/Makefile 1.49 +6 -6 ports/dns/bind95/distinfo _______________________________________________ cvs-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-ports To unsubscribe, send any mail to "cvs-ports-unsubscribe@freebsd.org" -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From peterjeremy at optushome.com.au Wed Jul 9 19:54:28 2008 From: peterjeremy at optushome.com.au (Peter Jeremy) Date: Wed Jul 9 19:54:36 2008 Subject: OPIE Challenge sequence In-Reply-To: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> References: <670f29e20807080316s6cf57612jf5135bfd340e3328@mail.gmail.com> Message-ID: <20080708113030.GN62764@server.vk2pj.dyndns.org> On 2008-Jul-08 15:46:37 +0530, Ivan Grover wrote: >Iam trying to choose OPIE as my OTP implementation for authenticating the >clients. I have the following queries, could anyone please let me know these >-- why does the challenge in OPIE are in predetermined form.. >is it for determining the decryption key for the encrypted passphrase(stored >in opiekeys). The passphrase is not encrypted - it is hashed and cannot be "decrypted". Basically, the passphrase and seed are concatenated and the result is hashed (using MD5) the number of times specified by the iteration count and the seed, count and final hash are stored in /etc/opiekeys. The supplied response is easily verified because when you run it thru MD5, you should get the hash in /etc/opiekeys. You then replace that hash with the one the user supplied. >-- is it possible to generate random challenges using opiechallenge No. The seed has to match the seed that was used to generate the hash with opiepasswd. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080709/a7fee300/attachment-0001.pgp From astorms at ncircle.com Wed Jul 9 20:04:12 2008 From: astorms at ncircle.com (Andrew Storms) Date: Wed Jul 9 20:04:23 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <48750BF7.5040402@FreeBSD.org> Message-ID: Nice. Thanks Doug! On 7/9/08 12:05 PM, "Remko Lodder" wrote: > Dear all, > > Doug just updated the ports tree with the updated BIND ports. If you > urgently want to upgrade and really cannot wait for the advisory. Please > use the ports system to get up to speed. > > Thanks Doug for working on this on such short notice! > > Cheers, > remko From chris at noncombatant.org Wed Jul 9 20:30:08 2008 From: chris at noncombatant.org (Chris Palmer) Date: Wed Jul 9 20:30:17 2008 Subject: BIND update? In-Reply-To: <20080709185405.GJ92109@atarininja.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709181515.GG92109@atarininja.org> <20080709183325.GE55473@noncombatant.org> <20080709185405.GJ92109@atarininja.org> Message-ID: <20080709203008.GF55473@noncombatant.org> Wesley Shields writes: > > Malware authors create exploits based on information they gleaned by > > reverse > > (legitimate businesses). I'm also not sure how this applies since the > project is open source - the fix is published at the time of the patch, My implicit (sorry about that) point was that if closed source software has no obscurity, there's no way open source software can have any. So we should not pretend that there is any, nor that it can help. The best course is to provide users full information about the risks they face and to respond with timely and correct fixes to those issues that introduce unnecessary risk. In this case, the BIND bug is already patched and publicly available anyway. From marquis at roble.com Wed Jul 9 22:04:02 2008 From: marquis at roble.com (Roger Marquis) Date: Wed Jul 9 22:04:13 2008 Subject: BIND update? Message-ID: <20080709215308.C4A662B7C00@mx5.roble.com> Jason Stone wrote: >I don't agree with the criticism of the security team; it takes a lot of >time to test things and make sure that changes and patches work within the >larger context of a complete system. There's that, but you also have to consider ISC's role. They certainly put a lot into testing named on all the common platforms. I'm pretty sure FreeBSD is still one of their test platforms. Not so sure it will continue to be though, given the resources our polished OS seems to be limited to. > And what I like about FreeBSD is that it's a complete system, > not just a collection of disjoint parts like some other popular > unix-like systems out there.... Don't know if I agree given the way dozens of port versions were unnecessarily incremented recently. http://unix.derkeiler.com/Newsgroups/comp.unix.bsd.freebsd.misc/2008-06/msg00231.html At least we _can_ easily update bind ports, I mean without waiting for maintainers or QA. But the real issue here is FreeBSD's response in comparison with other Unix/Linux operating systems. This is a critical time for FreeBSD. If we can't keep up, response-time-wise, patch-wise, finance-wise, or otherwise, our OS won't last long. The competition has gotten too good. Question is, OT but very relevant, how can FreeBSD get some decent corporate sponsorship? Roger Marquis From stef-list at memberwebs.com Wed Jul 9 21:01:53 2008 From: stef-list at memberwebs.com (Stef) Date: Wed Jul 9 22:16:25 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] References: Message-ID: <20080709204114.471A2F1835D@mx.npubs.com> Thanks! Here are simple steps to use this instead of the base named (and easily go back later): # cd /usr/ports/dns/bind9 # make && make install # ln -s /etc/namedb/named.conf /usr/local/etc/named.conf # echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf # /etc/rc.d/named restart LMK if I missed something. Cheers, Stef Andrew Storms wrote: > Nice. Thanks Doug! > > > On 7/9/08 12:05 PM, "Remko Lodder" wrote: > >> Dear all, >> >> Doug just updated the ports tree with the updated BIND ports. If you >> urgently want to upgrade and really cannot wait for the advisory. Please >> use the ports system to get up to speed. >> >> Thanks Doug for working on this on such short notice! >> >> Cheers, >> remko > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > From MH at kernel32.de Wed Jul 9 23:41:23 2008 From: MH at kernel32.de (Marian Hettwer) Date: Wed Jul 9 23:41:30 2008 Subject: BIND update? In-Reply-To: <20080709182340.GD55473@noncombatant.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709182340.GD55473@noncombatant.org> Message-ID: <4875481E.4000100@kernel32.de> Hi Chris, Chris Palmer schrieb: > So I'm not too worried about the lack of urgency from the FreeBSD security > team on this particular issue. It's not news that DNS is insecure and that > BIND has a bug. Nobody should have been depending on the security of DNS or > on a bulletproof BIND. > > True words! However, since the SecTeam of FreeBSD always did a great job, in this specific case, which had quite a huge coverage in the "press", at least a Heads Up to freebsd-security@ saying something like "Stay tuned for a patch folks, we're investigating" would have been appropriate. When everybody tries to get mad, and that's what happened, a statement like that could have calmed things done in the first place. But maybe I missed that heads up, 'cause I jumped into this discussion quite late... Well, anyway, SecTeam, keep up the good work :) Cheers, ./Marian From Mark_Andrews at isc.org Wed Jul 9 23:45:24 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Wed Jul 9 23:45:31 2008 Subject: BIND update? In-Reply-To: Your message of "Wed, 09 Jul 2008 14:53:08 MST." <20080709215308.C4A662B7C00@mx5.roble.com> Message-ID: <200807092345.m69NjNgf091485@drugs.dv.isc.org> Well as a developer of BIND I will tell you that my development platform is FreeBSD. FreeBSD drugs.dv.isc.org 6.3-STABLE FreeBSD 6.3-STABLE #19: Fri Apr 25 13:07:00 EST 2008 marka@drugs.dv.isc.org:/usr/obj/usr/src/sys/DRUGS i386 If Doug hasn't already updated the ports to use the -P1 I would expect him to do so shortly. Or you could all do it yourselves. It really is not that hard. Just check the PGP signatures on the tarball when you make the new checksums for the port. As for updating the base. There is still time to do this without panicing. Dan's method has not been released. Remember the only real solution to cache poisoning is to deploy DNSSEC. You can go out and do your part of that today. If you really cared about DNS security you would have done it already. It isn't that hard. Just use the defaults. http://www.isc.org/sw/bind/docs/DNSSEC_in_6_minutes.pdf Talk to your member(s) of parliment about getting the root signed and your cctld signed (only 4 have been signed last time I checked). If .SE and .BR can do it then your cctld can do it. ORG is in the process of getting DNSSEC added. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From booloo at ucsc.edu Wed Jul 9 23:52:07 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Wed Jul 9 23:52:17 2008 Subject: BIND update? In-Reply-To: <4875481E.4000100@kernel32.de> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709182340.GD55473@noncombatant.org> <4875481E.4000100@kernel32.de> Message-ID: <20080709235204.GB72293@root.ucsc.edu> > > Nobody should have been depending on the security of DNS or > > on a bulletproof BIND. Everyone that uses the Internet depends on the security of DNS. From chris at noncombatant.org Thu Jul 10 00:27:49 2008 From: chris at noncombatant.org (Chris Palmer) Date: Thu Jul 10 00:29:06 2008 Subject: BIND update? In-Reply-To: <20080709235204.GB72293@root.ucsc.edu> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709182340.GD55473@noncombatant.org> <4875481E.4000100@kernel32.de> <20080709235204.GB72293@root.ucsc.edu> Message-ID: <20080710002749.GK55473@noncombatant.org> Mark Boolootian writes: > Everyone that uses the Internet depends on the security of DNS. That's too bad, because DNS never made any security guarantees. When you ask to resolve www.google.com, the answer does not mean "www.google.com is on the network at 74.125.19.104." It means "As far as we can tell at the moment, www.google.com might be on the network at 74.125.19.104, or that might be a total lie. Good luck! P.S.: Lying is very easy." There are no guarantees of authentication, authorization, or integrity. When I need to verify the identity of a host (really, the identity of an application server -- which is more relevant anyway), I use things like SSL certificates and SSH host keys. After all, you were going to need authentication and integrity -- and likely confidentiality, too -- at the application layer anyway. Right? From freebsd-security at dfmm.org Thu Jul 10 04:59:34 2008 From: freebsd-security at dfmm.org (Jason Stone) Date: Thu Jul 10 04:59:41 2008 Subject: BIND update? In-Reply-To: <20080710002749.GK55473@noncombatant.org> References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709182340.GD55473@noncombatant.org> <4875481E.4000100@kernel32.de> <20080709235204.GB72293@root.ucsc.edu> <20080710002749.GK55473@noncombatant.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Everyone that uses the Internet depends on the security of DNS. > That's too bad, because DNS never made any security guarantees. When you > ask to resolve www.google.com, the answer does not mean "www.google.com > is on the network at 74.125.19.104." It means "As far as we can tell at > the moment, www.google.com might be on the network at 74.125.19.104, or > that might be a total lie. Good luck! P.S.: Lying is very easy." > > There are no guarantees of authentication, authorization, or integrity. Yes, yes, DNS makes no security guarantees, it's always been vulnerable, this is old old news. But answer truthfully: have you never launched a browser and typed "www.google.com" into it? I suspect that you have. So this affects you too. So you say, "But I don't send important information over that connection, nor do I trust the information I get back?" Maybe. I think that the AOL data leak fiasco proved that, while people don't generally think of search queries as sensitive, they really kind of are. And you almost certainly place _some_ trust in the results you get back; I mean, you're not reading them purely as fiction. But let's leave that aside for a second and assume it's true: you genuinely don't care about privacy or tampering while you're just casually surfing. That's not what's at issue; what's at issue is that you're choosing to let unknown and untrusted sites inject arbitrary data into your web browser. And your browser has more exploitable bugs in it than you can shake a stick at. It doesn't matter which browser you use -- IE, Firefox, Safari, Opera, Lynx, w3m -- I guarantee you, it has more holes than you can shake a stick at. You could run it in a chroot, or with a different UID from your normal user... but you don't. So, if your DNS resolver is vulnerable to cache poisoning, then every time you casually surf the web, you're allowing for the possibility that you will get spoofed, surf to some malware site, get served a browser exploit, and get 0wned. This is not just theoretical; check old CERT advisories, attackers have been exploiting DNS cache vulnerabilities in home/soho routers/WAPs/firewalls for a while now. So a DNS vulnerability that would make it easy to poison the resolvers of very large numbers of clients is a huge deal. I agree that DNSSEC is the real solution. I also think that making it easy (or even possible) to sandbox the browsers is a real solution. I think that using strong crypto everywhere and making fine-grained capabilities and MAC systems ubiquitous is also a real solution. But that's just not the reality we have today. And having the reality we have today, it's absolutely critical to make the existing, insecure DNS system as secure as it can be. -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFIdZc1swXMWWtptckRAtFqAKCA++pDoal7FEr13hXIWJ9h+iYA2gCfTVyQ 5AXA7BRSqX0ToHayLgGB0PA= =c7gM -----END PGP SIGNATURE----- From silby at silby.com Thu Jul 10 05:08:37 2008 From: silby at silby.com (Mike Silbersack) Date: Thu Jul 10 05:08:45 2008 Subject: BIND update? In-Reply-To: <200807091209.m69C9Gsl030319@lava.sentex.ca> References: <200807091054.m69As4eH065391@lurza.secnetix.de> <200807091209.m69C9Gsl030319@lava.sentex.ca> Message-ID: <20080709233650.B3813@odysseus.silby.com> On Wed, 9 Jul 2008, Mike Tancsa wrote: > At 06:54 AM 7/9/2008, Oliver Fromme wrote: >> Andrew Storms wrote: >> > http://www.isc.org/index.pl?/sw/bind/bind-security.php >> >> I'm just wondering ... >> >> ISC's patches cause source ports to be randomized, thus >> making it more difficult to spoof response packets. >> >> But doesn't FreeBSD already randomize source ports by >> default? So, do FreeBSD systems require to be patched >> at all? > > It doesnt seem to do a very good job of it with bind for some reason... > Perhaps because it picks a port and reuses it ? Yep, binding to a single query port and sticking to it is how BIND has operated for years. I just came up with a crazy idea, perhaps someone with more pf knowledge could answer this question: Can you make a pf rule that NATs all outgoing udp queries from BIND with random source ports? That seems like it would have exactly the same effect as BIND randomizing the source ports itself. Granted, updating BIND would probably be the better choice long term, but perhaps it'd be easier to push a new firewall rule out to a rack of machines. Mike "Silby" Silbersack From chris at noncombatant.org Thu Jul 10 05:21:54 2008 From: chris at noncombatant.org (Chris Palmer) Date: Thu Jul 10 05:22:00 2008 Subject: BIND update? In-Reply-To: References: <17cd1fbe0807090819o2aa28250h13c58dbe262abb7c@mail.gmail.com> <3a558cb8f79e923db0c6945830834ba2.squirrel@galain.elvandar.org> <17cd1fbe0807090909i566e1789s6b7b61bf82dd333e@mail.gmail.com> <4874ECDA.60202@elvandar.org> <4874F149.1040101@FreeBSD.org> <17cd1fbe0807091027n6af312cbwab3d3277f2b5e081@mail.gmail.com> <20080709182340.GD55473@noncombatant.org> <4875481E.4000100@kernel32.de> <20080709235204.GB72293@root.ucsc.edu> <20080710002749.GK55473@noncombatant.org> Message-ID: <48759C70.2060705@noncombatant.org> Jason Stone wrote: > So you say, "But I don't send important information over that > connection, nor do I trust the information I get back?" Maybe. I think > that the AOL data leak fiasco proved that, while people don't generally > think of search queries as sensitive, they really kind of are. And you > almost certainly place _some_ trust in the results you get back; I mean, > you're not reading them purely as fiction. I validate such unauthenticated information at the human layer. Have to -- even when nobody has tampered with DNS, BGP, or HTTP, the stuff at nytimes.com and wikipedia.org is still often false. > So, if your DNS resolver is vulnerable to cache poisoning, then every > time you casually surf the web, you're allowing for the possibility that > you will get spoofed, surf to some malware site, get served a browser > exploit, and get 0wned. That is already true, and is true regardless of the "security" of the DNS. Think hard on why this is possible: http://ex-parrot.com/~pete/upside-down-ternet.html :) Similarly, why does YouTube disappear whenever Pervez Musharraf gets cranky? > I agree that DNSSEC is the real solution. It won't, and can't, solve *any* of the problems you cited. Any attacker than can mangle my DNS traffic (and cache poisoning is hardly the only way to do that) can also just read and alter *any* non-secure-by-design plaintext network traffic. > I also think that making it easy (or even possible) to sandbox the > browsers is a real solution. I think that using strong crypto everywhere > and making fine-grained capabilities and MAC systems ubiquitous is also a > real solution. Okay, I know when I'm being trolled. :) I'll stop posting now. It's bed time anyway. From tim at clewlow.org Thu Jul 10 05:48:39 2008 From: tim at clewlow.org (Tim Clewlow) Date: Thu Jul 10 05:48:45 2008 Subject: BIND update? In-Reply-To: <20080709233650.B3813@odysseus.silby.com> References: <200807091054.m69As4eH065391@lurza.secnetix.de> <200807091209.m69C9Gsl030319@lava.sentex.ca> <20080709233650.B3813@odysseus.silby.com> Message-ID: <53413.192.168.1.10.1215667980.squirrel@192.168.1.100> > > On Wed, 9 Jul 2008, Mike Tancsa wrote: > >> At 06:54 AM 7/9/2008, Oliver Fromme wrote: >>> Andrew Storms wrote: >>> > http://www.isc.org/index.pl?/sw/bind/bind-security.php >>> >>> I'm just wondering ... >>> >>> ISC's patches cause source ports to be randomized, thus >>> making it more difficult to spoof response packets. >>> >>> But doesn't FreeBSD already randomize source ports by >>> default? So, do FreeBSD systems require to be patched >>> at all? >> >> It doesnt seem to do a very good job of it with bind for some >> reason... >> Perhaps because it picks a port and reuses it ? > > Yep, binding to a single query port and sticking to it is how BIND > has > operated for years. > > I just came up with a crazy idea, perhaps someone with more pf > knowledge > could answer this question: > > Can you make a pf rule that NATs all outgoing udp queries from BIND > with > random source ports? That seems like it would have exactly the same > effect as BIND randomizing the source ports itself. > > Granted, updating BIND would probably be the better choice long > term, but > perhaps it'd be easier to push a new firewall rule out to a rack of > machines. > Assuming this is NOT a gateway, ie a single homed DNS. This has not been tested, and may not work, but anyway, how about: nic="network interface name" bind_port="source port number you have set bind to ALWAYS use" nat on $nic from any port $bind_port to any -> ($nic) This _should_ do a special nat of both udp and tcp traffic, ie keep the same source IP but randomly pick a new source port. I haven't had time to set up a jail/test DNS to try this on, maybe it wont work at all, but that should give you an idea. Cheers, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ From silby at silby.com Thu Jul 10 05:54:18 2008 From: silby at silby.com (Mike Silbersack) Date: Thu Jul 10 05:54:25 2008 Subject: BIND update? In-Reply-To: <53413.192.168.1.10.1215667980.squirrel@192.168.1.100> References: <200807091054.m69As4eH065391@lurza.secnetix.de> <200807091209.m69C9Gsl030319@lava.sentex.ca> <20080709233650.B3813@odysseus.silby.com> <53413.192.168.1.10.1215667980.squirrel@192.168.1.100> Message-ID: <20080710004835.S5394@odysseus.silby.com> On Thu, 10 Jul 2008, Tim Clewlow wrote: >> Can you make a pf rule that NATs all outgoing udp queries from BIND >> with >> random source ports? That seems like it would have exactly the same >> effect as BIND randomizing the source ports itself. > > Assuming this is NOT a gateway, ie a single homed DNS. > > This has not been tested, and may not work, but anyway, how about: > > nic="network interface name" > bind_port="source port number you have set bind to ALWAYS use" > nat on $nic from any port $bind_port to any -> ($nic) > > This _should_ do a special nat of both udp and tcp traffic, ie keep > the same source IP but randomly pick a new source port. > > I haven't had time to set up a jail/test DNS to try this on, maybe > it wont work at all, but that should give you an idea. > > Cheers, Tim. Yes, using pf's NAT seems to work, although doxpara's checker claims that it is not working. Here's what tcpdump on the external side of NAT shows me after I nat port 53 traffic: 06:05:56.469558 IP SILBYIP.60153 > 209.85.139.9.53: 9078% [1au] A? www.l.google.com. (45) 06:05:56.535407 IP 209.85.139.9.53 > SILBYIP.60153: 9078*- 3/0/0 A 64.233.167.99,[|domain] 06:06:03.767643 IP SILBYIP.59956 > 216.239.36.10.53: 21333% [1au] A? news.google.com. (44) 06:06:03.817520 IP 216.239.36.10.53 > SILBYIP.59956: 21333*- 1/7/8 CNAME news.l.google.com. (289) 06:06:03.818565 IP SILBYIP.55784 > 64.233.167.9.53: 61468% [1au] A? news.l.google.com. (46) 06:06:03.840510 IP 64.233.167.9.53 > SILBYIP.55784: 61468*- 2/0/0 A 72.14.207.104, (67) 06:06:16.830837 IP SILBYIP.59956 > 216.239.36.10.53: 59557% [1au] A? maps.google.com. (44) 06:06:16.880945 IP 216.239.36.10.53 > SILBYIP.59956: 59557*- 1/7/8 CNAME maps.l.google.com. (289) 06:06:16.881988 IP SILBYIP.63680 > 209.85.137.9.53: 11160% [1au] A? maps.l.google.com. (46) 06:06:17.025439 IP 209.85.137.9.53 > SILBYIP.63680: 11160*- 3/0/0 A 64.233.167.104,[|domain] As you can see, we get a different source port for each server that we connect to. I would assume that makes us secure. But the checker at doxpara doesn't think we're secure because it's just one server that we're connecting to repeatedly. 06:06:45.127850 IP SILBYIP.57575 > 209.200.168.66.53: 38156% [1au] A? 46e004a4f29d.toorrr.com. (52) 06:06:45.238227 IP 209.200.168.66.53 > SILBYIP.57575: 38156*- 1/0/0 CNAME[|domain] 06:06:45.239020 IP SILBYIP.57575 > 209.200.168.66.53: 11461% [1au][|domain] 06:06:45.351066 IP 209.200.168.66.53 > SILBYIP.57575: 11461*-[|domain] 06:06:45.351836 IP SILBYIP.57575 > 209.200.168.66.53: 57564% [1au][|domain] 06:06:45.466886 IP 209.200.168.66.53 > SILBYIP.57575: 57564*-[|domain] 06:06:45.467658 IP SILBYIP.57575 > 209.200.168.66.53: 31106% [1au][|domain] 06:06:45.580640 IP 209.200.168.66.53 > SILBYIP.57575: 31106*-[|domain] 06:06:45.581619 IP SILBYIP.57575 > 209.200.168.66.53: 4662% [1au][|domain] 06:06:45.692804 IP 209.200.168.66.53 > SILBYIP.57575: 4662*-[|domain] So there we go, we saved the internet with NAT. :) -Mike From silby at silby.com Thu Jul 10 06:06:29 2008 From: silby at silby.com (Mike Silbersack) Date: Thu Jul 10 06:06:35 2008 Subject: BIND update? In-Reply-To: <53413.192.168.1.10.1215667980.squirrel@192.168.1.100> References: <200807091054.m69As4eH065391@lurza.secnetix.de> <200807091209.m69C9Gsl030319@lava.sentex.ca> <20080709233650.B3813@odysseus.silby.com> <53413.192.168.1.10.1215667980.squirrel@192.168.1.100> Message-ID: <20080710010119.K5394@odysseus.silby.com> On Thu, 10 Jul 2008, Tim Clewlow wrote: > Assuming this is NOT a gateway, ie a single homed DNS. nat on $ext_if proto udp from any to any port 53 -> ($ext_if) That's the rule that works for me. You don't need to worry about tcp because tcp is protected by its 32 bit initial sequence number. If someone wants to go propose this fix on bugtraq, please don't mention my name. I don't want to get dragged into it. :) -Mike From Mark_Andrews at isc.org Thu Jul 10 07:02:39 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Thu Jul 10 07:02:46 2008 Subject: BIND update? In-Reply-To: Your message of "Wed, 09 Jul 2008 22:21:52 MST." <48759C70.2060705@noncombatant.org> Message-ID: <200807100702.m6A72VV4011126@drugs.dv.isc.org> > Jason Stone wrote: > > > So you say, "But I don't send important information over that > > connection, nor do I trust the information I get back?" Maybe. I think > > that the AOL data leak fiasco proved that, while people don't generally > > think of search queries as sensitive, they really kind of are. And you > > almost certainly place _some_ trust in the results you get back; I mean, > > you're not reading them purely as fiction. > > I validate such unauthenticated information at the human layer. Have to -- > even when nobody has tampered with DNS, BGP, or HTTP, the stuff at > nytimes.com and wikipedia.org is still often false. > > > So, if your DNS resolver is vulnerable to cache poisoning, then every > > time you casually surf the web, you're allowing for the possibility that > > you will get spoofed, surf to some malware site, get served a browser > > exploit, and get 0wned. > > That is already true, and is true regardless of the "security" of the DNS. > > Think hard on why this is possible: > > http://ex-parrot.com/~pete/upside-down-ternet.html > > :) > > Similarly, why does YouTube disappear whenever Pervez Musharraf gets cranky? > > > I agree that DNSSEC is the real solution. > > It won't, and can't, solve *any* of the problems you cited. Any attacker > than can mangle my DNS traffic (and cache poisoning is hardly the only way > to do that) can also just read and alter *any* non-secure-by-design > plaintext network traffic. DNSSEC won't stop all attacks. It does however stop some attack vectors. Others, like the man in the middle attack above, it won't stop. > > I also think that making it easy (or even possible) to sandbox the > > browsers is a real solution. I think that using strong crypto everywhere > > and making fine-grained capabilities and MAC systems ubiquitous is also a > > real solution. > > Okay, I know when I'm being trolled. :) I'll stop posting now. It's bed time > anyway. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From marck at rinet.ru Thu Jul 10 15:05:57 2008 From: marck at rinet.ru (Dmitry Morozovsky) Date: Thu Jul 10 15:06:05 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <20080709204114.471A2F1835D@mx.npubs.com> References: <20080709204114.471A2F1835D@mx.npubs.com> Message-ID: <20080710183843.Q58331@woozle.rinet.ru> On Wed, 9 Jul 2008, Stef wrote: S> Thanks! S> S> Here are simple steps to use this instead of the base named (and easily S> go back later): S> S> # cd /usr/ports/dns/bind9 S> # make && make install S> # ln -s /etc/namedb/named.conf /usr/local/etc/named.conf S> # echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf S> # /etc/rc.d/named restart S> S> LMK if I missed something. (or use NO_BIND= in /etc/make.conf and WITH_REPLACE_BASE= on port options, but be careful when upgrading configs...) Just to have you and other related parties informed of a pitfall I stepped into: -- 8< -- From: BIND9 Bugs via RT Subject: [ISC-Bugs #18265] AutoReply: bind update to 9.4.2.1: 'empty label' inconsistent check ------------------------------------------------------------------------- Dear Doug and ISC maintainers, just updated bind94 on our master server and found that together with vulnerability fixes there is at least one glitch in configuration checks History: we have automatic scripted system to secondary some zones from one of our partners. so, part of named.conf is auto-generated, then checked via named-checkconf and then applied. After today upgrade I found that new server failed to start, which is really a PITA, as it has 13k+ authoritative zones. Named-checkconf does not return an error. named reports 'empty label' without any reference to config file and/or line number. After some nervous minutes of binary search ;-) I found the offending line, which erroneously contains two dots instead of one. I suppose this should be fixed at least in named-checkconf. -- 8< -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] ------------------------------------------------------------------------ *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck@rinet.ru *** ------------------------------------------------------------------------ From tedm at ipinc.net Thu Jul 10 17:56:16 2008 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu Jul 10 18:15:06 2008 Subject: Here is how to fix your nameserver - was Re: BIND update? In-Reply-To: <4875D67B.7010006@punktas.lt> Message-ID: > -----Original Message----- > From: stakys [mailto:stakys@punktas.lt] > Sent: Thursday, July 10, 2008 2:30 AM > To: Ted Mittelstaedt > Subject: Re: Here is how to fix your nameserver - was Re: BIND update? > > > > > > According to your simple steps everything runs fine for now. > What about > later then the port will be available or the 6.4 is out? How > the update > procedure should look like, or it would be the same as always without > any hints for BIND? > Hi Stakys, I hope you don't mind I'm ccing this to the list as others may have questions. Incidentally, if you use my instructions there is one other thing you have to do, that is you have to put a copy of rndc.key into /etc because rndc out of the box defaults to looking there for it. With regards to the ports, yes you can do it that way if you want. I myself haven't used the BIND port in the ports directories so I am not aware of all implications of using it. I presume it replaces all the BIND utilities in the base system with updated versions. What isn't clear to me is what the port does with every other program in the system that is linked into the BIND resolver functions. If your admining a nameserver and you routinely use the BIND port, you should continue to do so, NOT use my instructions. If you have never used that port, then you might consider it. But, I would do it on a nameserver your prototyping, so you can learn how the port operates. Keep in mind that there is no "right" way to admin your system - it is your system, do as you want. Because FreeBSD is self-supported, the security patches, the ports, and ad-hoc instructions like mine are purely out there for people to use IF THEY WANT TO. You do not have to admin your server the way that -we- say to do it. ;-) Just as a bit of background on UNIX. There was NEVER a standardized place to put things in the UNIX filesystem. For example, Sun likes to use the /opt directory a lot, and no other UNIX does that I know of. There's de-facto places. That is why the ports directories are so important, because when a port for a utility is created it standardizes where everything goes. For example, if someone says to the list that they used the BIND port to install an updated version of named, we -know- for example that named.conf is going to be at /var/named/etc/namedb/named.conf because that is where the FreeBSD Release engineers decided to put it, and the person who created the port is of course going to honor that. BUT, that is a compile-time option in BIND and the defaults in the BIND source don't actually put it there. Instead they put it in /etc/namedb/named.conf When a UNIX vendor (and the FreeBSD Project is a UNIX vendor, they just don't get paid for it like a commercial UNIX vendor like Sun does) creates a UNIX distribution they draw software from all over the globe. Sendmail comes from here, gcc comes from there, named comes from this other place, etc. etc. etc. Each of those individual packages has their own places that they put things. Part of the job of the release engineer is deciding a logical structure on -their- UNIX release of where things go, and then putting in compile time options, or patching makefiles, or even patching source itself, of all these different utilities to force them to put their stuff where the release engineer has decided to put it. Back in the bad old days of UNIX, most of the Really Useful utilities -weren't- included in the UNIX distribution. For example ALL Solaris UNIX versions up until very recently didn't even have a compiler, you had to bootstrap gcc into your Solaris system. HP/UX, and Utek UNIX had compilers, but they were crappy ones and wouldn't compile most programs, so you had to use their crappy compilers to build a better compiler then use that compiler to build basic tools - things like Perl, Bash, php, and so on. Quite a lot of work, and nowadays we have it a lot easier - BUT the PROBLEM is that because so many basic utilities are now supplied stock out of the box, if you want to replace one of them, because of a security vulnerability like this named thing, for example, it becomes a MAJOR PIA. Looking at Perl for example illustrates this. Perl is a rather nasty program to have people build because it is so involved - but it is a fantastically useful program. In FreeBSD 4 days it became obvious that it would be Really Useful if Perl was included in FreeBSD, so they did so. Then it became even more obvious that it would be even more Really Useful if Perl -wasn't- included, precisely because of stuff like what is going on right now with BIND. So, they reverted to the old way of doing things, and Perl is back to being an add-on, one that virtually everyone who is setting up a FreeBSD system immediately installs as soon as they setup a new FreeBSD system. (hopefully, from the ports or packages system) So, getting back to BIND. Unfortunately, BIND isn't as easy to create as an add-on as Perl is. BIND is more than a simple program. BIND has 2 parts, there's a set of libraries, usually referred to, generically, as the "resolver libraries" There's a set of utilities, like named, named-xfer, rndc, and so on. Just about every network-aware program in ANY unix, ie: sendmail, nslookup, host, netstat, etc. etc. is compiled to link in the resolver library. If a flaw in the libraries is discovered, it affects -ALL- network-aware programs that are linked into the libraries. Thus, the only real fix is to update the source for the system and recompile every single utility that is linked into the resolver libraries in the entire system -including- additional utilities that are built by the user after the system is installed. (ie: do a make world) With FreeBSD, during the system build process, the BIND resolver routines are put into libc. (ie: /usr/lib/libc.a for the static library, and /usr/lib/libc.so for the dynamic one) While it is sometimes possible IF the utility is dynamically linked to simply recompile the resolver library, this is a Beware, There Be Dragons kind of thing to do because if the library has changed much, you can introduce problems that way. And, with FreeBSD, libc has a lot of -other- stuff -besides- the BIND stuff in /usr/src/lib/libc/resolv It's probably accurate to say that virtually everything in the system is linked into this library. Thus, "upgrading BIND" if your talking about -everything- that makes up BIND is not simple. HOWEVER, this particular issue ONLY affects systems that are acting as nameservers because it only affects named itself. Virtually all FreeBSD systems are NOT running as nameservers and thus do not need to worry about this particular notification. Systems that ARE running as nameservers almost always are doing that ONLY, ie: they are dedicated nameserver servers. Thus your not using most utilities in the system, sendmail, host, netstat, etc. Because, when named is built it -statically- links into it's libraries (which are also built when named is built), thus when you follow my instructions you are ending up with a system that has the -old- resolver libraries that are linked into every other program in the system, and a named program that is built with the -new- code. Since the vulnerability only affects named, it doesn't matter that the rest of the system is using the old code. And, by NOT replacing the old libraries, you avoid introducing potential instabilities into other programs. For example suppose in addition to nameserving your server is doing some analysis of traffic - if you recompile the world with the new resolver library and the analysis code your running breaks, well now you are stuck because you don't know if the problem is in the new resolver code or if it is that you improperly compiled it into the system, or if it is because some other utility that linked into libc has a problem. My instructions basically give the nameserver admin a way to patch their server in the most -minimally invasive- way possible and then run it that way until the next version of FreeBSD is released in August or September. Ted From dougb at FreeBSD.org Fri Jul 11 00:33:04 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jul 11 00:33:10 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <20080709204114.471A2F1835D@mx.npubs.com> References: <20080709204114.471A2F1835D@mx.npubs.com> Message-ID: <4876A3FE.1070407@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 First off, to those who were kind enough to offer thanks, "you're welcome." :) Second, one user wrote me privately to indicate that my statement in the first paragraph of my commit message was not clear. The point to this change is that for _each_ outgoing query a _new, random_ UDP source port is used, _as well as_ the standard query ID. (This is of course assuming that you do not have a port locked down in named.conf, which no one should at this point unless firewall rules outside of your control mandate it.) However, named is still picking a "random" UDP port on startup and locking it down (2 if you're also using IPv6) although it's not immediately clear to me why (I do have a query as to the reason in progress). Stef wrote: | Thanks! | | Here are simple steps to use this instead of the base named (and easily | go back later): | | # cd /usr/ports/dns/bind9 Actually I'd at least use bind94, and preferably bind95. Either of those two will have better memory management characteristics than the 9.3.x that is in dns/bind9. | # make && make install | # ln -s /etc/namedb/named.conf /usr/local/etc/named.conf You will also need to do the same with the rndc.key file, and if you are running in the chroot (the default for the rc.d script) then you will need to create /var/named/usr/local/etc and repeat the exercise for both files. | # echo 'named_program="/usr/local/sbin/named" >> /etc/rc.conf Personally my preference would be to edit the rc.conf[.local] file. | # /etc/rc.d/named restart I would actually do 'rndc stop' first, then '/etc/rc.d/named start' but for most purposes the differences there would be minor. You can also use the "replace base bind" option in the 'make config' step which would obviate editing named_program above. If you do that, add 'WITHOUT_BIND= yes' in /etc/src.conf for 7 or 8, and 'NO_BIND= yes' in /etc/make.conf in 6. hope this helps, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkh2o/4ACgkQyIakK9Wy8PurfQCfeN7Vvme3PABgFWMPhQz1Kgu6 gVUAni9iCNt0Gzi2YntV6uQmmRI8MhQl =4Blu -----END PGP SIGNATURE----- From dougb at FreeBSD.org Fri Jul 11 05:05:38 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jul 11 05:05:49 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <4876A3FE.1070407@FreeBSD.org> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> Message-ID: <4876EA1E.9000804@FreeBSD.org> Doug Barton wrote: > However, named is still picking a "random" UDP port on startup and > locking it down (2 if you're also using IPv6) although it's not > immediately clear to me why. And the answer is .... in order to make the -P1 releases as clean as possible, that part of the code was not touched (which I think is a very good decision) and that port may continue to see use down the road. hope this helps, Doug -- This .signature sanitized for your protection From artis.caune at gmail.com Fri Jul 11 05:36:33 2008 From: artis.caune at gmail.com (Artis Caune) Date: Fri Jul 11 05:36:39 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <48750BF7.5040402@FreeBSD.org> References: <48750BF7.5040402@FreeBSD.org> Message-ID: <9e20d71e0807102209k2b9cc638he76d8a2a82e986cf@mail.gmail.com> On Wed, Jul 9, 2008 at 10:05 PM, Remko Lodder wrote: > Dear all, > > Doug just updated the ports tree with the updated BIND ports. If you > urgently want to upgrade and really cannot wait for the advisory. Please use > the ports system to get up to speed. Has anyone tried to run bind95? I updated bind94-9.4.2_1 to bind95-9.5.0.1 and after couple of hours it eated all 2G of ram and 1G of swap and was killed. max-cache-size was set to 1500M, same problem with 64M. Looks like bind95 is leaking memory. FreeBSD-7.0/amd64, 2K queries/sec bind94-4.2.1 works just fine. thanks, Artis From brett at lariat.net Fri Jul 11 15:06:00 2008 From: brett at lariat.net (Brett Glass) Date: Fri Jul 11 15:09:21 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <4876A3FE.1070407@FreeBSD.org> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> Message-ID: <200807111454.IAA18639@lariat.net> Is there a way to restrict the ports which BIND selects -- perhaps at the expense of a small amount of entropy -- such that it doesn't try to use UDP ports which are administratively blocked (e.g. ports used by worms, or insecure Microsoft network utilities)? We don't dare turn these port blocks off, or naive users will fall prey to security holes in Microsoft products. But if BIND doesn't know to work around them, lookups will occasionally (and infuriatingly!) fail. --Brett Glass At 06:06 PM 7/10/2008, Doug Barton wrote: >First off, to those who were kind enough to offer thanks, "you're >welcome." :) > >Second, one user wrote me privately to indicate that my statement in >the first paragraph of my commit message was not clear. The point to >this change is that for _each_ outgoing query a _new, random_ UDP >source port is used, _as well as_ the standard query ID. (This is of >course assuming that you do not have a port locked down in named.conf, >which no one should at this point unless firewall rules outside of >your control mandate it.) However, named is still picking a "random" >UDP port on startup and locking it down (2 if you're also using IPv6) >although it's not immediately clear to me why (I do have a query as to >the reason in progress). From koitsu at FreeBSD.org Fri Jul 11 15:29:03 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jul 11 15:29:10 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <200807111454.IAA18639@lariat.net> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> Message-ID: <20080711151228.GA52385@eos.sc1.parodius.com> On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote: > Is there a way to restrict the ports which BIND selects -- perhaps > at the expense of a small amount of entropy -- such that it doesn't > try to use UDP ports which are administratively blocked (e.g. ports > used by worms, or insecure Microsoft network utilities)? We don't > dare turn these port blocks off, or naive users will fall prey to > security holes in Microsoft products. But if BIND doesn't know to > work around them, lookups will occasionally (and infuriatingly!) > fail. query-source has an argument called "port" which will do what you want. That option *only* affects UDP queries, however; TCP queries are always random. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From alan at clegg.com Fri Jul 11 15:56:58 2008 From: alan at clegg.com (Alan Clegg) Date: Fri Jul 11 15:57:05 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <20080711151228.GA52385@eos.sc1.parodius.com> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> <20080711151228.GA52385@eos.sc1.parodius.com> Message-ID: <487782C5.7050703@clegg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jeremy Chadwick wrote: > On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote: >> Is there a way to restrict the ports which BIND selects -- perhaps >> at the expense of a small amount of entropy -- such that it doesn't >> try to use UDP ports which are administratively blocked (e.g. ports >> used by worms, or insecure Microsoft network utilities)? We don't >> dare turn these port blocks off, or naive users will fall prey to >> security holes in Microsoft products. But if BIND doesn't know to >> work around them, lookups will occasionally (and infuriatingly!) >> fail. > > query-source has an argument called "port" which will do what you want. > That option *only* affects UDP queries, however; TCP queries are always > random. While query-source allows you to lock down to a single port, you DO NOT WANT TO DO THIS -- if you do, you will be vulnerable to the very thing that the patch made you immune (well, safer) from. What Brett (and others) need to do is risk the waters with the new beta code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained" control for the UDP ports to be used. Please, PLEASE, do not introduce "query-source port XX" into your configurations. AlanC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFId4LEcKpYUrUDCYcRAiowAJ47bCASBmTszN8A7d1MbEvB9ZJq0wCWMZIK t8Uv4q/ro3MDpEP71GqtHg== =+SwG -----END PGP SIGNATURE----- From m.seaman at infracaninophile.co.uk Fri Jul 11 16:28:38 2008 From: m.seaman at infracaninophile.co.uk (Matthew Seaman) Date: Fri Jul 11 16:28:45 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <487782C5.7050703@clegg.com> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> <20080711151228.GA52385@eos.sc1.parodius.com> <487782C5.7050703@clegg.com> Message-ID: <48778A1B.4060504@infracaninophile.co.uk> Alan Clegg wrote: > Jeremy Chadwick wrote: >> On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote: >>> Is there a way to restrict the ports which BIND selects -- perhaps >>> at the expense of a small amount of entropy -- such that it doesn't >>> try to use UDP ports which are administratively blocked (e.g. ports >>> used by worms, or insecure Microsoft network utilities)? We don't >>> dare turn these port blocks off, or naive users will fall prey to >>> security holes in Microsoft products. But if BIND doesn't know to >>> work around them, lookups will occasionally (and infuriatingly!) >>> fail. >> query-source has an argument called "port" which will do what you want. >> That option *only* affects UDP queries, however; TCP queries are always >> random. > While query-source allows you to lock down to a single port, you DO NOT > WANT TO DO THIS -- if you do, you will be vulnerable to the very thing > that the patch made you immune (well, safer) from. > > What Brett (and others) need to do is risk the waters with the new beta > code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained" > control for the UDP ports to be used. > > Please, PLEASE, do not introduce "query-source port XX" into your > configurations. Probably what Brett is looking for are the avoid-v4-udp-ports and avoid-v6-udp-ports options -- these just contain lists of UDP ports to avoid as the source of any DNS traffic. Details are available here (for bind95) http://www.isc.org/sw/bind/arm95/Bv9ARM.ch06.html#options but it's the same for all 9.x versions of BIND. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080711/0103b282/signature.pgp From koitsu at FreeBSD.org Fri Jul 11 16:29:13 2008 From: koitsu at FreeBSD.org (Jeremy Chadwick) Date: Fri Jul 11 16:29:20 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <487782C5.7050703@clegg.com> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> <20080711151228.GA52385@eos.sc1.parodius.com> <487782C5.7050703@clegg.com> Message-ID: <20080711162913.GA55187@eos.sc1.parodius.com> On Fri, Jul 11, 2008 at 11:56:53AM -0400, Alan Clegg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Jeremy Chadwick wrote: > > On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote: > >> Is there a way to restrict the ports which BIND selects -- perhaps > >> at the expense of a small amount of entropy -- such that it doesn't > >> try to use UDP ports which are administratively blocked (e.g. ports > >> used by worms, or insecure Microsoft network utilities)? We don't > >> dare turn these port blocks off, or naive users will fall prey to > >> security holes in Microsoft products. But if BIND doesn't know to > >> work around them, lookups will occasionally (and infuriatingly!) > >> fail. > > > > query-source has an argument called "port" which will do what you want. > > That option *only* affects UDP queries, however; TCP queries are always > > random. > > While query-source allows you to lock down to a single port, you DO NOT > WANT TO DO THIS -- if you do, you will be vulnerable to the very thing > that the patch made you immune (well, safer) from. > > What Brett (and others) need to do is risk the waters with the new beta > code (9.4.3b2 and 9.5.1b1) which includes additional "fine-grained" > control for the UDP ports to be used. > > Please, PLEASE, do not introduce "query-source port XX" into your > configurations. The problem here is WRT network ACLs. The only solution is to bind BIND to a specific IP address and permit any outbound TCP or UDP traffic + any inbound TCP or UDP traffic to port 53. Most network administrators I know of won't like that, as they deny all incoming *and* outgoing traffic, then apply permit ACLs. There's no "clean" or "strict" permit ACL, while with port XX, you can at least narrow down things UDP-wise a bit more. I'll add that the stock src/etc/namedb/named.conf even advocates the use of query-source ... port 53. I'm sure this will be changed as a result of the recent security issue. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From dougb at FreeBSD.org Fri Jul 11 17:44:54 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jul 11 17:45:06 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <20080711162913.GA55187@eos.sc1.parodius.com> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> <20080711151228.GA52385@eos.sc1.parodius.com> <487782C5.7050703@clegg.com> <20080711162913.GA55187@eos.sc1.parodius.com> Message-ID: <48779C0E.2020807@FreeBSD.org> Jeremy Chadwick wrote: > The problem here is WRT network ACLs. The only solution is to bind BIND > to a specific IP address and permit any outbound TCP or UDP traffic + > any inbound TCP or UDP traffic to port 53. Not quite any inbound traffic, named will pick a source port > 1024. In the current beta versions there is an option to restrict the ports chosen to a range. I'm also not quite sure what kind of server you're talking about here. If it's authoritative, then by definition you have to allow all inbound traffic to port 53. > Most network administrators > I know of won't like that, as they deny all incoming *and* outgoing > traffic, then apply permit ACLs. There's no "clean" or "strict" permit > ACL, while with port XX, you can at least narrow down things UDP-wise a > bit more. False economy. The "danger" of allowing inbound UDP traffic is infinitely less than the danger of having a recursive resolver's cache poisoned. The new way of things would be to define those UDP ports that run services other than named on the system, add those to the avoid-* option(s) in named.conf, and block those ports at the firewall, leaving everything else open. Of course, almost any modern firewall should have keep-state functionality for UDP, so all of this should be moot. > I'll add that the stock src/etc/namedb/named.conf even advocates the use > of query-source ... It doesn't advocate, it gives an example. This is the reason I am resistant to adding too many examples to our installed named.conf, it is too easy for people to misinterpret them. Doug -- This .signature sanitized for your protection From dougb at FreeBSD.org Fri Jul 11 18:17:37 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jul 11 18:17:44 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <9e20d71e0807102209k2b9cc638he76d8a2a82e986cf@mail.gmail.com> References: <48750BF7.5040402@FreeBSD.org> <9e20d71e0807102209k2b9cc638he76d8a2a82e986cf@mail.gmail.com> Message-ID: <4877A3BE.7040808@FreeBSD.org> Artis Caune wrote: > I updated bind94-9.4.2_1 to bind95-9.5.0.1 and after couple of hours > it eated all 2G of ram and 1G of swap and was killed. The best place to report these issues is bind-users@isc.org. Good luck, Doug -- This .signature sanitized for your protection From cswiger at mac.com Fri Jul 11 20:29:16 2008 From: cswiger at mac.com (Chuck Swiger) Date: Fri Jul 11 20:29:23 2008 Subject: OpenSSL warning from dns/bind95 build...? Message-ID: Hi, all-- Apropos of this security issue with BIND, I just tried updating a FreeBSD-6.3-STABLE system with dns/bind95, and it loudly complains about the OpenSSL version which comes with the system: > [ ... ] > config.status: creating include/isc/platform.h > config.status: creating config.h > WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING > WARNING WARNING > WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING > WARNING WARNING > WARNING > > WARNING > WARNING Your OpenSSL crypto library may be vulnerable > to WARNING > WARNING one or more of the the following known > security WARNING > WARNING > flaws: WARNING > WARNING > > WARNING > WARNING CAN-2002-0659, CAN-2006-4339, CVE-2006-2937 > and WARNING > WARNING > CVE-2006-2940. WARNING > WARNING > > WARNING > WARNING It is recommended that you upgrade to > OpenSSL WARNING > WARNING version 0.9.8d/0.9.7l (or > greater). WARNING > WARNING > > WARNING > WARNING You can disable this warning by > specifying: WARNING > WARNING > > WARNING > WARNING --disable-openssl-version-check > WARNING > WARNING > > WARNING > WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING > WARNING WARNING > WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING > WARNING WARNING > ===> Building for bind95-base-9.5.0.1 Is the version of OpenSSL now included with RELENG_6 (OpenSSL 0.9.7e- p1) OK, or is it at risk as reported? Regards, -- -Chuck From alan at clegg.com Fri Jul 11 20:38:54 2008 From: alan at clegg.com (Alan Clegg) Date: Fri Jul 11 20:39:01 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <48778A1B.4060504@infracaninophile.co.uk> References: <20080709204114.471A2F1835D@mx.npubs.com> <4876A3FE.1070407@FreeBSD.org> <200807111454.IAA18639@lariat.net> <20080711151228.GA52385@eos.sc1.parodius.com> <487782C5.7050703@clegg.com> <48778A1B.4060504@infracaninophile.co.uk> Message-ID: <4877C4DA.9070404@clegg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Matthew Seaman wrote: > Probably what Brett is looking for are the avoid-v4-udp-ports and > avoid-v6-udp-ports options -- these just contain lists of UDP ports > to avoid as the source of any DNS traffic. Details are available here > (for bind95) http://www.isc.org/sw/bind/arm95/Bv9ARM.ch06.html#options > but it's the same for all 9.x versions of BIND. This is fine as long as you are not defining large numbers of "don't touch" ports. The added functionality of 9.5.1b1: use-v4-udp-ports { range 1024 65535; }; use-v6-udp-ports { range 1024 65535; }; Is what I was pointing people towards. AlanC -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFId8TacKpYUrUDCYcRAhmHAJoCkQ3dxLfQhw1EamBJfNrLqwVZLwCfcfRg VTWMnJEfymL8TH7AV2MQ7y4= =mIl7 -----END PGP SIGNATURE----- From dougb at FreeBSD.org Fri Jul 11 21:23:22 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Fri Jul 11 21:23:29 2008 Subject: OpenSSL warning from dns/bind95 build...? In-Reply-To: References: Message-ID: <4877CF47.2080208@FreeBSD.org> Chuck Swiger wrote: > Hi, all-- > > Apropos of this security issue with BIND, I just tried updating a > FreeBSD-6.3-STABLE system with dns/bind95, and it loudly complains about > the OpenSSL version which comes with the system: [snip] > Is the version of OpenSSL now included with RELENG_6 (OpenSSL 0.9.7e-p1) > OK, or is it at risk as reported? You're better off upgrading using the version in ports/security/openssl and adding WITH_OPENSSL_PORT to /etc/make.conf. hth, Doug -- This .signature sanitized for your protection From Mark_Andrews at isc.org Fri Jul 11 22:19:52 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri Jul 11 22:20:04 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: Your message of "Fri, 11 Jul 2008 08:54:48 CST." <200807111454.IAA18639@lariat.net> Message-ID: <200807112219.m6BMJmLg042450@drugs.dv.isc.org> > Is there a way to restrict the ports which BIND selects -- perhaps > at the expense of a small amount of entropy -- such that it doesn't > try to use UDP ports which are administratively blocked (e.g. ports > used by worms, or insecure Microsoft network utilities)? We don't > dare turn these port blocks off, or naive users will fall prey to > security holes in Microsoft products. But if BIND doesn't know to > work around them, lookups will occasionally (and infuriatingly!) > fail. % grep avoid doc/misc/options avoid-v4-udp-ports { ; ... }; avoid-v6-udp-ports { ; ... }; % -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From Mark_Andrews at isc.org Fri Jul 11 22:48:52 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Fri Jul 11 22:49:01 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: Your message of "Fri, 11 Jul 2008 08:12:28 MST." <20080711151228.GA52385@eos.sc1.parodius.com> Message-ID: <200807112248.m6BMmlkL042880@drugs.dv.isc.org> > On Fri, Jul 11, 2008 at 08:54:48AM -0600, Brett Glass wrote: > > Is there a way to restrict the ports which BIND selects -- perhaps > > at the expense of a small amount of entropy -- such that it doesn't > > try to use UDP ports which are administratively blocked (e.g. ports > > used by worms, or insecure Microsoft network utilities)? We don't > > dare turn these port blocks off, or naive users will fall prey to > > security holes in Microsoft products. But if BIND doesn't know to > > work around them, lookups will occasionally (and infuriatingly!) > > fail. > > query-source has an argument called "port" which will do what you want. > That option *only* affects UDP queries, however; TCP queries are always > random. ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** ******* DO NOT SET THE PORT IN QUERY-SOURCE. ******** Use avoid-v4-udp-ports { ; ... }; avoid-v6-udp-ports { ; ... }; > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From wildcard.name at gmail.com Fri Jul 11 22:58:32 2008 From: wildcard.name at gmail.com (bsd) Date: Fri Jul 11 22:58:41 2008 Subject: freebsd-security Message-ID: <1444282990.20080709175027@gmail.com> Hello freebsd-security, -- Best regards, bsd mailto:wildcard.name@gmail.com From smithi at nimnet.asn.au Sat Jul 12 05:20:55 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jul 12 05:21:02 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: <200807112219.m6BMJmLg042450@drugs.dv.isc.org> Message-ID: On Sat, 12 Jul 2008, Mark Andrews wrote: > > > Is there a way to restrict the ports which BIND selects -- perhaps > > at the expense of a small amount of entropy -- such that it doesn't > > try to use UDP ports which are administratively blocked (e.g. ports > > used by worms, or insecure Microsoft network utilities)? We don't > > dare turn these port blocks off, or naive users will fall prey to > > security holes in Microsoft products. But if BIND doesn't know to > > work around them, lookups will occasionally (and infuriatingly!) > > fail. > > % grep avoid doc/misc/options > avoid-v4-udp-ports { ; ... }; > avoid-v6-udp-ports { ; ... }; > % This seems to imply that you can't specify ranges of UDP ports to avoid here. For example perhaps, the range traceroute uses .. Doug responded with a new option for a range of ports to use, but an intersection of ports to use and ^ports to avoid, including range(s), would cover all the bases .. cheers, Ian From smithi at nimnet.asn.au Sat Jul 12 05:32:53 2008 From: smithi at nimnet.asn.au (Ian Smith) Date: Sat Jul 12 05:33:00 2008 Subject: [Fwd: cvs commit: ports/dns/bind9 Makefile distinfo ports/dns/bind94 Makefile distinfo ports/dns/bind95 Makefile distinfo] In-Reply-To: Message-ID: On Sat, 12 Jul 2008, Ian Smith wrote: > Doug responded with a new option My apologies, it was Alan. Second cup of tea hadn't kicked in .. Ian From dougb at FreeBSD.org Sun Jul 13 04:00:58 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Sun Jul 13 04:01:06 2008 Subject: BIND update? In-Reply-To: References: Message-ID: <48797DF7.9050402@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 This is an interesting thread, so I'm going to try to respond to what I think are the reasonable points all in one post so as not to single anyone out. Again, thanks to those who chose to give thanks, encouragement, or criticism with a positive approach. This issue is complicated because it both is, and is not a "serious" security issue. As others stated rather eloquently, the fact that DNS is an "insecure" service is (or certainly should be) well known. What is also (or certainly should be) well known is that almost all of the other services on the Internet are also insecure, even those with "secure" in the name. :) The problem with this particular vulnerability is that it grabbed the media's attention, and since they think they understand it they are banging the drum pretty loudly. This creates FUD in normally rational people, and hilarity ensues. There are a large number of steps that network operators can and should already have been taking to mitigate damage from this attack. Ingress/egress filtering (ala BCP 38), secure ACLs on your name servers and/or firewalls, splitting authoritative and resolving name services to separate instances, restricting availability of recursive services to only those users who should have them, etc. The danger (and this is a BIG danger in the DNS world) is that most networks are not taking the basic steps that they should be taking to secure their name service (it works, why touch it?), and this upcoming exploit is going to hit them right between the eyes. Changing topics, the BIND installation in the base is not intended to be an out of the box solution to those for whom DNS is part of their critical infrastructure. The BIND bits, along with the sample named.conf file, are set up to run by default as a fairly secure local resolver (and by local I mean really local: only listening on the loopback address). The fact that for many purposes (for instance a "medium" sized ISP, etc.) it works well out of the box is not totally accidental, but like any other service if it's important to your business you need to invest the time and effort to make sure it's working the way you need it to, not rely on others to do that work for you. Jeremy asked why the ports are updated before the BIND in the base. Someone else gave part of the answer, that a lot more QA is involved in dealing with stuff in the base. There are patches to create, security advisories (including instructions, etc.) to write, FreeBSD update stuff to prep, etc. By contrast updating the ports is easy, and gives users for whom a given security issue is critical a simple path to upgrade, and just as importantly, to back out from when/if they deem what's in the base suitable for their needs. However, there is a more fundamental reason that goes to the heart of my philosophy as BIND maintainer. When I was the DNS admen at Yahoo! I _never_ used the BIND that came with the base system. There were a variety of reasons for this, the two most important being that I had a lot of custom tweaks/patches for our version of BIND, and the fact that I needed to update stuff more often than the boxes were updated. This lead to the "replace the base" option in the ports way back when. There is another meta-issue that seems to be coming up a lot lately, which is users who seem to be paralyzed, unable to take any action to help themselves, totally dependent on the FreeBSD developers to make things happen for them. I'm not going to get dragged into that topic again, but I will say that Mark was right, the BIND ports are pretty easy to update if you ever have to do it yourself. And, you don't even have to go out of your way to check the PGP signature, there is a 'make verify' target that will do that for you. :) Seriously though, one user wrote to me (and others) privately and said in so many words, "The things I run on FreeBSD are critically important to me, therefore making them run smoothly must be critically important to you." If you have that mindset, you really, really need to take a reality check. (Go ahead, we'll wait for you.) The vast majority of people who work on FreeBSD do it for FUN, as VOLUNTEERS. If you need a commercial level of support, you're going to have to pay for it, it's that simple. And NO, please do not go off into the woods on this topic. I believe that there is a market for commercial FreeBSD support, but unfortunately it hasn't reached critical mass yet. (Chicken, meet egg. Why don't you two go off and talk for a while?) So, the short version is, "Don't Panic." Well, wok, panic a little, but don't let it distract you from actually getting something useful done, like upgrading your servers, firewall rules, etc. And, if anyone has a business that relies heavily on DNS and needs a good DNS consultant, I know where to find one. :) hope this helps, Doug - -- ~ This .signature sanitized for your protection -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEAREDAAYFAkh5ffcACgkQyIakK9Wy8Ps9YwCgtl80hRIuMkMqcRf9gWLP2dwA fUIAoOsWRsXAYIMotlgC/yS1RQdp2g6E =TLjy -----END PGP SIGNATURE----- From security-advisories at freebsd.org Sun Jul 13 19:10:05 2008 From: security-advisories at freebsd.org (FreeBSD Security Advisories) Date: Sun Jul 13 19:10:22 2008 Subject: FreeBSD Security Advisory FreeBSD-SA-08:06.bind Message-ID: <200807131910.m6DJA5hl093319@freefall.freebsd.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-08:06.bind Security Advisory The FreeBSD Project Topic: DNS cache poisoning Category: contrib Module: bind Announced: 2008-07-13 Credits: Dan Kaminsky Affects: All supported FreeBSD versions. Corrected: 2008-07-12 10:07:33 UTC (RELENG_6, 6.3-STABLE) 2008-07-13 18:42:38 UTC (RELENG_6_3, 6.3-RELEASE-p3) 2008-07-13 18:42:38 UTC (RELENG_7, 7.0-STABLE) 2008-07-13 18:42:38 UTC (RELENG_7_0, 7.0-RELEASE-p3) CVE Name: CVE-2008-1447 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet Domain Name Server. DNS requests contain a query id which is used to match a DNS request with the response and to make it harder for anybody but the DNS server which received the request to send a valid response. II. Problem Description The BIND DNS implementation does not randomize the UDP source port when doing remote queries, and the query id alone does not provide adequate randomization. III. Impact The lack of source port randomization reduces the amount of data the attacker needs to guess in order to successfully execute a DNS cache poisoning attack. This allows the attacker to influence or control the results of DNS queries being returned to users from target systems. IV. Workaround Limiting the group of machines that can do recursive queries on the DNS server will make it more difficult, but not impossible, for this vulnerability to be exploited. To limit the machines able to perform recursive queries, add an ACL in named.conf and limit recursion like the following: acl example-acl { 192.0.2.0/24; }; options { recursion yes; allow-recursion { example-acl; }; }; V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 6-STABLE or 7-STABLE, or to the RELENG_7_0 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 and 7.0 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 6.3] # fetch http://security.FreeBSD.org/patches/SA-08:06/bind63.patch # fetch http://security.FreeBSD.org/patches/SA-08:06/bind63.patch.asc [FreeBSD 7.0] # fetch http://security.FreeBSD.org/patches/SA-08:06/bind7.patch # fetch http://security.FreeBSD.org/patches/SA-08:06/bind7.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 NOTE WELL: This update causes BIND to choose a new, random UDP port for each new query; this may cause problems for some network configurations, particularly if firewall(s) block incoming UDP packets on particular ports. The avoid-v4-udp-ports and avoid-v6-udp-ports options should be used to avoid selecting random port numbers within a blocked range. NOTE WELL: If a port number is specified via the query-source or query-source-v6 options to BIND, randomized port selection will not be used. Consequently it is strongly recommended that these options not be used to specify fixed port numbers. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_6 src/contrib/bind9/bin/named/client.c 1.1.1.2.2.5 src/contrib/bind9/bin/named/server.c 1.1.1.2.2.4 src/contrib/bind9/lib/dns/api 1.1.1.2.2.5 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.1.4.4 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.1.4.3 src/contrib/bind9/lib/dns/resolver.c 1.1.1.2.2.8 RELENG_6_3 src/UPDATING 1.416.2.37.2.8 src/sys/conf/newvers.sh 1.69.2.15.2.7 src/contrib/bind9/bin/named/client.c 1.1.1.2.2.3.2.1 src/contrib/bind9/bin/named/server.c 1.1.1.2.2.2.2.1 src/contrib/bind9/lib/dns/api 1.1.1.2.2.3.2.1 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.1.4.2.2.1 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.1.4.1.2.1 src/contrib/bind9/lib/dns/resolver.c 1.1.1.2.2.6.2.1 RELENG_7 src/contrib/bind9/bin/named/client.c 1.1.1.6.2.2 src/contrib/bind9/bin/named/server.c 1.1.1.6.2.2 src/contrib/bind9/lib/dns/api 1.1.1.6.2.2 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.4.2.2 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.3.2.2 src/contrib/bind9/lib/dns/resolver.c 1.1.1.9.2.2 RELENG_7_0 src/UPDATING 1.507.2.3.2.7 src/sys/conf/newvers.sh 1.72.2.5.2.7 src/contrib/bind9/bin/named/client.c 1.1.1.6.2.1.2.1 src/contrib/bind9/bin/named/server.c 1.1.1.6.2.1.2.1 src/contrib/bind9/lib/dns/api 1.1.1.6.2.1.2.1 src/contrib/bind9/lib/dns/dispatch.c 1.1.1.4.2.1.2.1 src/contrib/bind9/lib/dns/include/dns/dispatch.h 1.1.1.3.2.1.2.1 src/contrib/bind9/lib/dns/resolver.c 1.1.1.9.2.1.2.1 - ------------------------------------------------------------------------- VII. References http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447 http://www.kb.cert.org/vuls/id/800113 The latest revision of this advisory is available at http://security.FreeBSD.org/advisories/FreeBSD-SA-08:06.bind.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkh6UiMACgkQFdaIBMps37IE5ACfYzpWMhEXgWNdjwVlzd7JTwBS Eu0AnRIogMIJ3fjQF4hcymtdwR6buRNc =shnR -----END PGP SIGNATURE----- From simon at FreeBSD.org Sun Jul 13 22:39:35 2008 From: simon at FreeBSD.org (Simon L. Nielsen) Date: Sun Jul 13 22:39:42 2008 Subject: OpenSSL warning from dns/bind95 build...? In-Reply-To: References: Message-ID: <20080713222344.GB15766@zaphod.nitro.dk> On 2008.07.11 13:14:09 -0700, Chuck Swiger wrote: [quote edited to contain important part] >> WARNING Your OpenSSL crypto library may be vulnerable to >> WARNING one or more of the the following known security >> WARNING flaws: >> WARNING >> WARNING CAN-2002-0659, CAN-2006-4339, CVE-2006-2937 and >> WARNING CVE-2006-2940. >> WARNING [...] > Is the version of OpenSSL now included with RELENG_6 (OpenSSL 0.9.7e-p1) > OK, or is it at risk as reported? Just so there is no doubt - the base system OpenSSL isn't actually vulnerable to those issues. They were fixed in SA-02:33.openssl, FreeBSD-SA-06:19.openssl, and FreeBSD-SA-06:23.openssl. The BIND build system just has no way to see this since they were patched instead of upgraded. -- Simon L. Nielsen Hats: Base system OpenSSL janitor and FreeBSD Security Team From Mark_Andrews at isc.org Mon Jul 14 00:29:38 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Jul 14 00:29:45 2008 Subject: FreeBSD Security Advisory FreeBSD-SA-08:06.bind In-Reply-To: Your message of "Sun, 13 Jul 2008 19:10:05 GMT." <200807131910.m6DJA5hl093319@freefall.freebsd.org> Message-ID: <200807140029.m6E0TaRg059266@drugs.dv.isc.org> There was no mention of checking named.conf to ensure that a port was not specified in the query-source clauses. Just upgrading will not fix the problem it if named.conf has "query-source port 53". Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From dougb at FreeBSD.org Mon Jul 14 00:42:33 2008 From: dougb at FreeBSD.org (Doug Barton) Date: Mon Jul 14 00:42:39 2008 Subject: OpenSSL warning from dns/bind95 build...? In-Reply-To: <20080713222344.GB15766@zaphod.nitro.dk> References: <20080713222344.GB15766@zaphod.nitro.dk> Message-ID: <487AA0F6.1010801@FreeBSD.org> Simon L. Nielsen wrote: > On 2008.07.11 13:14:09 -0700, Chuck Swiger wrote: > > [quote edited to contain important part] > >>> WARNING Your OpenSSL crypto library may be vulnerable to >>> WARNING one or more of the the following known security >>> WARNING flaws: >>> WARNING >>> WARNING CAN-2002-0659, CAN-2006-4339, CVE-2006-2937 and >>> WARNING CVE-2006-2940. >>> WARNING > [...] >> Is the version of OpenSSL now included with RELENG_6 (OpenSSL 0.9.7e-p1) >> OK, or is it at risk as reported? > > Just so there is no doubt - the base system OpenSSL isn't actually > vulnerable to those issues. They were fixed in SA-02:33.openssl, > FreeBSD-SA-06:19.openssl, and FreeBSD-SA-06:23.openssl. > > The BIND build system just has no way to see this since they were > patched instead of upgraded. ... hence the false economy of not doing a "standard" upgrade of the version in the base. :) It's nice to know that for the particular set of problems listed in this version of BIND's warning message our users should not be at risk though. I used the ports openssl on my 6-stable boxes without problems, but I did not have that many ports installed, and I nuked the base openssl first. YMMV. Doug -- This .signature sanitized for your protection From Mark_Andrews at isc.org Mon Jul 14 01:34:45 2008 From: Mark_Andrews at isc.org (Mark Andrews) Date: Mon Jul 14 01:34:51 2008 Subject: FreeBSD Security Advisory FreeBSD-SA-08:06.bind In-Reply-To: Your message of "Sun, 13 Jul 2008 21:13:47 -0400." Message-ID: <200807140134.m6E1YgJT060145@drugs.dv.isc.org> > NOTE WELL: If a port number is specified via the query-source or > query-source-v6 options to BIND, randomized port selection will not be > used. Consequently it is strongly recommended that these options not > be used to specify fixed port numbers > -- > Michael Scheidell, CTO > >|SECNAP Network Security > Winner 2008 Network Products Guide Hot Companies > FreeBSD SpamAssassin Ports maintainer Yep, I missed it despite looking for it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org From scheidell at secnap.net Mon Jul 14 01:35:38 2008 From: scheidell at secnap.net (Michael Scheidell) Date: Mon Jul 14 01:36:08 2008 Subject: FreeBSD Security Advisory FreeBSD-SA-08:06.bind In-Reply-To: <200807140029.m6E0TaRg059266@drugs.dv.isc.org> Message-ID: NOTE WELL: If a port number is specified via the query-source or query-source-v6 options to BIND, randomized port selection will not be used. Consequently it is strongly recommended that these options not be used to specify fixed port numbers -- Michael Scheidell, CTO >|SECNAP Network Security Winner 2008 Network Products Guide Hot Companies FreeBSD SpamAssassin Ports maintainer > From: Mark Andrews > Date: Mon, 14 Jul 2008 10:29:36 +1000 > To: > Cc: FreeBSD Security Advisories > Subject: Re: FreeBSD Security Advisory FreeBSD-SA-08:06.bind > > > There was no mention of checking named.conf to ensure that > a port was not specified in the query-source clauses. Just > upgrading will not fix the problem it if named.conf has > > "query-source port 53". > > Mark > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@isc.org > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" _________________________________________________________________________ This email has been scanned and certified safe by SpammerTrap(r). For Information please see http://www.spammertrap.com _________________________________________________________________________ From booloo at ucsc.edu Mon Jul 14 23:39:41 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Mon Jul 14 23:39:48 2008 Subject: freebsd-update not pulling in BIND update Message-ID: <20080714233939.GA59891@root.ucsc.edu> Hi folks, I ran freebsd-update today hoping it would have picked up the BIND upgrade. freebsd-update reported: The following files will be updated as part of updating to 7.0-RELEASE-p3: /boot/kernel/kernel /boot/kernel/kernel.symbols /usr/bin/dig /usr/bin/host /usr/bin/nslookup /usr/bin/nsupdate /usr/include/netinet/tcp.h /usr/lib/libssh.a /usr/lib/libssh.so.4 /usr/lib/libssh_p.a /usr/sbin/dnssec-signzone /usr/sbin/lwresd /usr/sbin/named /usr/sbin/named-checkconf /usr/sbin/named-checkzone /usr/sbin/named-compilezone /usr/sbin/sshd /usr/src/sys/conf/newvers.sh /usr/src/sys/netinet/tcp.h /usr/src/sys/netinet/tcp_output.c While there is a new file for /usr/sbin/named, it isn't reporting the updated version: $ /usr/sbin/named -v BIND 9.4.2 Any thoughts? thanks in advance, mark From remko at elvandar.org Tue Jul 15 04:28:04 2008 From: remko at elvandar.org (Remko Lodder) Date: Tue Jul 15 04:28:11 2008 Subject: freebsd-update not pulling in BIND update In-Reply-To: <20080714233939.GA59891@root.ucsc.edu> References: <20080714233939.GA59891@root.ucsc.edu> Message-ID: On Tue, July 15, 2008 1:39 am, Mark Boolootian wrote: > > Hi folks, > > I ran freebsd-update today hoping it would have picked > up the BIND upgrade. freebsd-update reported: > > The following files will be updated as part of updating to > 7.0-RELEASE-p3: > /boot/kernel/kernel > /boot/kernel/kernel.symbols > /usr/bin/dig > /usr/bin/host > /usr/bin/nslookup > /usr/bin/nsupdate > /usr/include/netinet/tcp.h > /usr/lib/libssh.a > /usr/lib/libssh.so.4 > /usr/lib/libssh_p.a > /usr/sbin/dnssec-signzone > /usr/sbin/lwresd > /usr/sbin/named > /usr/sbin/named-checkconf > /usr/sbin/named-checkzone > /usr/sbin/named-compilezone > /usr/sbin/sshd > /usr/src/sys/conf/newvers.sh > /usr/src/sys/netinet/tcp.h > /usr/src/sys/netinet/tcp_output.c > > While there is a new file for /usr/sbin/named, it isn't reporting > the updated version: > > $ /usr/sbin/named -v > BIND 9.4.2 > > Any thoughts? > > thanks in advance, > mark > _______________________________________________ >From my understand we don't bump the version of the named binary, so that seems correct.. -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From booloo at ucsc.edu Tue Jul 15 04:36:55 2008 From: booloo at ucsc.edu (Mark Boolootian) Date: Tue Jul 15 04:37:02 2008 Subject: freebsd-update not pulling in BIND update In-Reply-To: References: <20080714233939.GA59891@root.ucsc.edu> Message-ID: <20080715043647.GA62823@root.ucsc.edu> > From my understand we don't bump the version of the named binary, so that > seems correct.. Thank you Remko. I really should have tested ahead of posting (which i aim to do shortly). From mattjreimer at gmail.com Thu Jul 17 00:34:34 2008 From: mattjreimer at gmail.com (Matt Reimer) Date: Thu Jul 17 00:34:41 2008 Subject: A new kind of security needed Message-ID: Is anyone else nervous trusting all his programs to have access to all his files? Is there already a reasonable solution to this problem? It makes me nervous for, say, Firefox and its plugins to be able to read and write every file I own, whether it's gnucash, ~/.ssh, or other sensitive files. Programs could be set up to run under their own uids, but this is cumbersome, especially in a desktop environment. One possibility would be to "filewall" off a program--say, Firefox--so that of all my uid's files Firefox is only able to read or write ~/.mozilla. If we had app signatures like it seems OS X does, then maybe a "filewall" MAC module could use extended attributes to grant access to files based on the app's signature. Permission could be granted to the application to access other files through a special file picker, so the user is always in control. Thoughts? Matt From chris at noncombatant.org Thu Jul 17 02:36:05 2008 From: chris at noncombatant.org (Chris Palmer) Date: Thu Jul 17 02:36:14 2008 Subject: A new kind of security needed In-Reply-To: References: Message-ID: <487EB013.9090706@noncombatant.org> Matt Reimer wrote: > Is anyone else nervous trusting all his programs to have access to all > his files? Is there already a reasonable solution to this problem? http://www.cis.upenn.edu/~KeyKOS/Confinement.html http://cr.yp.to/qmail/qmailsec-20071101.pdf Also: CapDesk, Bitfrost, systrace, EROS/Coyotos In general, solutions have proven to be vaporware, very burdensome to use (systrace), or reduced in scope (Bernstein's single-source transforms). The success rate is not zero, though, and I too crave a solution... From freebsd-security at dfmm.org Thu Jul 17 06:24:30 2008 From: freebsd-security at dfmm.org (Jason Stone) Date: Thu Jul 17 06:24:37 2008 Subject: A new kind of security needed In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Is anyone else nervous trusting all his programs to have access to all > his files? Is there already a reasonable solution to this problem? > > It makes me nervous for, say, Firefox and its plugins to be able to read > and write every file I own, whether it's gnucash, ~/.ssh, or other > sensitive files. Absolutely. Right now, I use different logins for different things (casual web surfing, financial stuff, snd work), but it's inconvenient and far from fullproof. Capabilities or MAC systems could be used here -- someone just has to put in the work to make it happen. -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFIfuWdswXMWWtptckRAui7AJoDPimy9czlyCRbPcDMTK0XzZ9GIgCg2u0z CQweJjrVQz2fV3xNH5ML50M= =G2pt -----END PGP SIGNATURE----- From patpro at patpro.net Thu Jul 17 07:18:20 2008 From: patpro at patpro.net (Patrick Proniewski) Date: Thu Jul 17 07:18:29 2008 Subject: A new kind of security needed In-Reply-To: References: Message-ID: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> On 17 juil. 08, at 08:24, Jason Stone wrote: >> Is anyone else nervous trusting all his programs to have access to >> all his files? Is there already a reasonable solution to this >> problem? >> >> It makes me nervous for, say, Firefox and its plugins to be able to >> read and write every file I own, whether it's gnucash, ~/.ssh, or >> other sensitive files. > > Absolutely. Right now, I use different logins for different things > (casual web surfing, financial stuff, snd work), but it's > inconvenient and far from fullproof. > > Capabilities or MAC systems could be used here -- someone just has > to put in the work to make it happen. What about sandbox/chroot ? Apple has designed such a system for Mac OS X 10.5, and even if it's not fully functional now, it's probably interesting. patpro From rwatson at FreeBSD.org Thu Jul 17 08:10:56 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 17 08:11:02 2008 Subject: A new kind of security needed In-Reply-To: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> Message-ID: <20080717085136.B87887@fledge.watson.org> On Thu, 17 Jul 2008, Patrick Proniewski wrote: >> Absolutely. Right now, I use different logins for different things (casual >> web surfing, financial stuff, snd work), but it's inconvenient and far from >> fullproof. >> >> Capabilities or MAC systems could be used here -- someone just has to put >> in the work to make it happen. > > What about sandbox/chroot ? Apple has designed such a system for Mac OS X > 10.5, and even if it's not fully functional now, it's probably interesting. > > And, interestingly, the Mac OS X Sandbox parts are based on the TrustedBSD MAC Framework that was first developed on FreeBSD and later port to Mac OS X. However, Sandbox is not open source, and does rely on the reliability of pathnames, which on UFS (and even HFS+) is a bit of a tricky issue. FWIW, I have some work in progress on the capability front, but it's a highly complex issue that will take years to work through properly. Unfortunately, the real issue isn't so much the OS primitives as building up a non-trivial application base that uses them. Providing primitives to subdivie applications isn't easy, but once you've done that you still have to rewrite lots of applications to take advantage of it, and in a way that shows a lot more application programmer discipline. It's not clear to me that the pressure is there to make feature-driven application development for major desktop applications adopt techniques of this sort. Robert N M Watson Computer Laboratory University of Cambridge From tim at clewlow.org Thu Jul 17 13:34:54 2008 From: tim at clewlow.org (Tim Clewlow) Date: Thu Jul 17 13:35:02 2008 Subject: A new kind of security needed In-Reply-To: <20080717085136.B87887@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> Message-ID: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> > > On Thu, 17 Jul 2008, Patrick Proniewski wrote: > >>> Absolutely. Right now, I use different logins for different >>> things (casual >>> web surfing, financial stuff, snd work), but it's inconvenient >>> and far from >>> fullproof. >>> >>> Capabilities or MAC systems could be used here -- someone just >>> has to put >>> in the work to make it happen. >> >> What about sandbox/chroot ? Apple has designed such a system for >> Mac OS X >> 10.5, and even if it's not fully functional now, it's probably >> interesting. >> >> > > And, interestingly, the Mac OS X Sandbox parts are based on the > TrustedBSD MAC > Framework that was first developed on FreeBSD and later port to Mac > OS X. > However, Sandbox is not open source, and does rely on the > reliability of > pathnames, which on UFS (and even HFS+) is a bit of a tricky issue. > > FWIW, I have some work in progress on the capability front, but it's > a highly > complex issue that will take years to work through properly. > Unfortunately, > the real issue isn't so much the OS primitives as building up a > non-trivial > application base that uses them. Providing primitives to subdivie > applications isn't easy, but once you've done that you still have to > rewrite > lots of applications to take advantage of it, and in a way that > shows a lot > more application programmer discipline. It's not clear to me that > the > pressure is there to make feature-driven application development for > major > desktop applications adopt techniques of this sort. > The "One Laptop Per Child" organisation seem to be taking the sandbox/jail concept to its extreme in an attempt to neuter viruses. In FreeBSD terms, they appear to be insisting that each user application on the laptop be run in its own jail. http://news.softpedia.com/news/The-100-Laptop-Virus-Free-37464.shtml This may be feasible on a system designed to be very restrictive in regards to hacking/tinkering, but much more difficult, if not impossible, to implement on a system like FreeBSD (how do you build a piped process group when all the individual processes are separately jailed?) Perhaps a security layer could be implemented that includes the ability to designate some applications as being only allowed to run if they are in a jail, and then have all other executables not available to be run on their own. But this would be a very different system from FreeBSD. Maybe it could be done with a sysctl switch, or maybe it would be such a major change it should really be considered a separate operating system in its own right, ie perhaps better implemented as part of PCBSD, or something of that ilk. Of course, if it can be done, without upsetting everyone, then that would be ideal, but I agree there would be a great deal of work involved. Regards, Tim. We are BSD ... resistance is futile. http://www.freebsd.org/ - http://www.openbsd.org/ - http://www.netbsd.org/ From die.gestalt at gmail.com Thu Jul 17 15:07:37 2008 From: die.gestalt at gmail.com (Die Gestalt) Date: Thu Jul 17 15:07:44 2008 Subject: A new kind of security needed In-Reply-To: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> Message-ID: <5bf3e10d0807170738t561fccb4rcfd79f994120aa1c@mail.gmail.com> It's the concept behind Microsoft's experimental OS : Symphony... Otherwise you can use jail. From die.gestalt at gmail.com Thu Jul 17 15:11:07 2008 From: die.gestalt at gmail.com (Die Gestalt) Date: Thu Jul 17 15:11:14 2008 Subject: A new kind of security needed In-Reply-To: <5bf3e10d0807170738t561fccb4rcfd79f994120aa1c@mail.gmail.com> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> <5bf3e10d0807170738t561fccb4rcfd79f994120aa1c@mail.gmail.com> Message-ID: <5bf3e10d0807170811j10025e0amf13ecb89ad16195f@mail.gmail.com> On Thu, Jul 17, 2008 at 4:38 PM, Die Gestalt wrote: > It's the concept behind Microsoft's experimental OS : Symphony... > > Otherwise you can use jail. > My bad, Singularity... Symphony is another story. :) From freebsd-security at dfmm.org Thu Jul 17 20:10:47 2008 From: freebsd-security at dfmm.org (Jason Stone) Date: Thu Jul 17 20:10:57 2008 Subject: A new kind of security needed In-Reply-To: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > how do you build a piped process group when all the individual > processes are separately jailed? "pipe ; fork ; chroot ; setuid". See qmail for an example. -Jason -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) Comment: See https://private.idealab.com/public/jason/jason.gpg iD8DBQFIf6dHswXMWWtptckRAoumAJoCwvvrDwZzZRQPqC7G4u8rxFv1hwCdEeiY 9KP1d4aEhCpkVy3FYkHHP0w= =4P0+ -----END PGP SIGNATURE----- From lyndon at orthanc.ca Fri Jul 18 20:41:59 2008 From: lyndon at orthanc.ca (Lyndon Nerenberg) Date: Fri Jul 18 20:42:05 2008 Subject: A new kind of security needed In-Reply-To: <20080717085136.B87887@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> Message-ID: <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> On 2008-Jul-17, at 00:54 , Robert Watson wrote: > FWIW, I have some work in progress on the capability front, but it's > a highly complex issue that will take years to work through > properly. Unfortunately, the real issue isn't so much the OS > primitives as building up a non-trivial application base that uses > them. Providing primitives to subdivie applications isn't easy, but > once you've done that you still have to rewrite lots of applications > to take advantage of it, and in a way that shows a lot more > application programmer discipline. It's not clear to me that the > pressure is there to make feature-driven application development for > major desktop applications adopt techniques of this sort. Realistically, this will never happen. It would require *every*one agreeing on a single consistent API, and that just won't happen with any sort of policy-based mechanism. It's sad people don't pay more attention to Plan 9. Namespaces go a long way towards solving this problem in a manner that's completely transparent to the application, and trivial for the end-user to configure and use. See: http://plan9.bell-labs.com/sys/doc/names.html http://plan9.bell-labs.com/magic/man2html/1/0intro http://plan9.bell-labs.com/magic/man2html/4/namespace In a nutshell, your view of the 'filesystem' is fully mutable. A simple 'rfork n' in the shell will instantiate a brand new instance of the namespace, which you can then fiddle to your heart's content. E.g. rfork n bind /usr/ftp / creates a namespace where /usr/ftp (by convention the anonymous FTP directory) is now the "root" directory of the process' filesystem. Analogous system calls exist for programmatic use. And since there is no concept of (or need for) a 'superuser' these facilities are available to everyone. This makes sandboxing trivial for any number of remotely accessible network services as well as to the interactive system user. Both files and directories can be bind targets, and the source of the bind can as easily be a program as a file or directory; the ability to create secure synthetic filesystems just naturally falls out of this paradigm. And the applications are blissfully unaware that any of this even exists. --lyndon From rwatson at FreeBSD.org Thu Jul 24 08:05:46 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 24 08:05:54 2008 Subject: A new kind of security needed In-Reply-To: <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <50456.192.168.1.10.1216301690.squirrel@192.168.1.100> Message-ID: <20080724085912.U63347@fledge.watson.org> On Thu, 17 Jul 2008, Tim Clewlow wrote: > The "One Laptop Per Child" organisation seem to be taking the sandbox/jail > concept to its extreme in an attempt to neuter viruses. In FreeBSD terms, > they appear to be insisting that each user application on the laptop be run > in its own jail. > > http://news.softpedia.com/news/The-100-Laptop-Virus-Free-37464.shtml > > This may be feasible on a system designed to be very restrictive in regards > to hacking/tinkering, but much more difficult, if not impossible, to > implement on a system like FreeBSD (how do you build a piped process group > when all the individual processes are separately jailed?) I think it's worth comparing this and other approaches to the Sandbox approach used in the version of Mac OS X in the iPhone, which fairly firmly compartmentalizes applications. The obvious upsets are a high level of isolation. The downsides are also pretty important to think about, though: common non-OS-provided infrastructure is minimized, inter-process services are limited, and especially, inter-application data sharing. Notice that the iPhone is careful not to expose a generic file system interface for sharing a single user's files between applications, and for good reason. This captures, I think, the fundamental challenges of desktop security quite well: desktop environments are highly interconnected and interdependent software packages built with a lot of mutual trust and integration. If you start slicing them up, you both completely disrupt the model they are designed around, and you also limit their ability to do some fairly widely depended on things. > Perhaps a security layer could be implemented that includes the ability to > designate some applications as being only allowed to run if they are in a > jail, and then have all other executables not available to be run on their > own. But this would be a very different system from FreeBSD. Maybe it could > be done with a sysctl switch, or maybe it would be such a major change it > should really be considered a separate operating system in its own right, ie > perhaps better implemented as part of PCBSD, or something of that ilk. > > Of course, if it can be done, without upsetting everyone, then that would be > ideal, but I agree there would be a great deal of work involved. Jails are extremely useful, but rest on the principle of pretty complete isolation of jailed environments. This is great for ISPs, but not so good if you want your web browser to sometimes, but not always, be able to upload your OpenOffice.org accounting spreadsheets to web sites. Even if you play a lot of grafting games using nullfs, etc, it's still messy. Assuming a desire to move incrementally towards a more fine-grained model, I suspect the starting point is to produce some security tools for application-based subdivision of the OS environment (and user rights), and then apply them in the most critical places first. I've had capability-related patches for FreeBSD on the back-burner for some time -- they allow processes to arbitrarily subdivide themselves into "jails" passing only very specific rights into the compartments, etc. They're not really for widespread use, since I've been trying to drive their development by adapting applications to use them for things like executing script interpreters, etc, and that process is slow, as it involves a lot of software adaption, but some of the work, at least, is probably ready to see the world. Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Thu Jul 24 08:09:27 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 24 08:09:35 2008 Subject: A new kind of security needed In-Reply-To: <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> Message-ID: <20080724090549.G63347@fledge.watson.org> On Fri, 18 Jul 2008, Lyndon Nerenberg wrote: > It's sad people don't pay more attention to Plan 9. Namespaces go a long way > towards solving this problem in a manner that's completely transparent to > the application, and trivial for the end-user to configure and use. > > See: > > http://plan9.bell-labs.com/sys/doc/names.html > http://plan9.bell-labs.com/magic/man2html/1/0intro > http://plan9.bell-labs.com/magic/man2html/4/namespace > > In a nutshell, your view of the 'filesystem' is fully mutable. A simple > 'rfork n' in the shell will instantiate a brand new instance of the > namespace, which you can then fiddle to your heart's content. E.g. > > rfork n bind /usr/ftp / > > creates a namespace where /usr/ftp (by convention the anonymous FTP > directory) is now the "root" directory of the process' filesystem. Analogous > system calls exist for programmatic use. And since there is no concept of > (or need for) a 'superuser' these facilities are available to everyone. > > This makes sandboxing trivial for any number of remotely accessible network > services as well as to the interactive system user. Both files and > directories can be bind targets, and the source of the bind can as easily be > a program as a file or directory; the ability to create secure synthetic > filesystems just naturally falls out of this paradigm. > > And the applications are blissfully unaware that any of this even exists. Lots of people care a lot about plan9. The problem is that it's a lot like UNIX. UNIX presupposes lots of special-purpose applications doing rather specific and well-defined things, and that is a decreasingly accurate reflection of the way people write applications. All these security extensions get extremely messy the moment you have general-purpose applications that you want to be able to do some things some times, and other things other times, and where the nature of the protections you want depends on, and changes with, the whim of the user. The complex structure of modern UNIX applications doesn't help (lots of dependent libraries, files, interpreters, etc), because it almost instantly pushes the package dependency problem into the access control problem. I don't think it's hopeless, but I think that any answer that looks simple is probably wrong by definition. :-) Robert N M Watson Computer Laboratory University of Cambridge From rwatson at FreeBSD.org Thu Jul 24 09:06:20 2008 From: rwatson at FreeBSD.org (Robert Watson) Date: Thu Jul 24 09:06:26 2008 Subject: A new kind of security needed In-Reply-To: <20080724085910.GG97161@deviant.kiev.zoral.com.ua> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> Message-ID: <20080724100439.D63347@fledge.watson.org> On Thu, 24 Jul 2008, Kostik Belousov wrote: >> Lots of people care a lot about plan9. The problem is that it's a lot like >> UNIX. UNIX presupposes lots of special-purpose applications doing rather >> specific and well-defined things, and that is a decreasingly accurate >> reflection of the way people write applications. All these security >> extensions get extremely messy the moment you have general-purpose >> applications that you want to be able to do some things some times, and >> other things other times, and where the nature of the protections you want >> depends on, and changes with, the whim of the user. The complex structure >> of modern UNIX applications doesn't help (lots of dependent libraries, >> files, interpreters, etc), because it almost instantly pushes the package >> dependency problem into the access control problem. I don't think it's >> hopeless, but I think that any answer that looks simple is probably wrong >> by definition. :-) > > I think that the per-process namespaces are useful, and can be added to the > existing Unix model with quite favourable consequences. On the other hand, I > do not think that security is the most important application of the > namespaces, or even have a direct relation to it. > > Implementing namespaces for FreeBSD looks as an doable and quite interesting > project for me :). Sounds good to me :-). As with all such project (variant symlinks, process-local name spaces, etc), do be very careful about security -- often as not, such projects risk tripping over problems with privilege-escalated processes, such as setuid binaries, etc, which place strong trust in the file system name space. Robert N M Watson Computer Laboratory University of Cambridge From kostikbel at gmail.com Thu Jul 24 09:33:29 2008 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Jul 24 09:33:35 2008 Subject: A new kind of security needed In-Reply-To: <20080724090549.G63347@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org> Message-ID: <20080724085910.GG97161@deviant.kiev.zoral.com.ua> On Thu, Jul 24, 2008 at 09:09:26AM +0100, Robert Watson wrote: > On Fri, 18 Jul 2008, Lyndon Nerenberg wrote: > > >It's sad people don't pay more attention to Plan 9. Namespaces go a long > >way towards solving this problem in a manner that's completely transparent > >to the application, and trivial for the end-user to configure and use. > > > >See: > > > >http://plan9.bell-labs.com/sys/doc/names.html > >http://plan9.bell-labs.com/magic/man2html/1/0intro > >http://plan9.bell-labs.com/magic/man2html/4/namespace > > > >In a nutshell, your view of the 'filesystem' is fully mutable. A simple > >'rfork n' in the shell will instantiate a brand new instance of the > >namespace, which you can then fiddle to your heart's content. E.g. > > > >rfork n bind /usr/ftp / > > > >creates a namespace where /usr/ftp (by convention the anonymous FTP > >directory) is now the "root" directory of the process' filesystem. > >Analogous system calls exist for programmatic use. And since there is no > >concept of (or need for) a 'superuser' these facilities are available to > >everyone. > > > >This makes sandboxing trivial for any number of remotely accessible > >network services as well as to the interactive system user. Both files and > >directories can be bind targets, and the source of the bind can as easily > >be a program as a file or directory; the ability to create secure > >synthetic filesystems just naturally falls out of this paradigm. > > > >And the applications are blissfully unaware that any of this even exists. > > Lots of people care a lot about plan9. The problem is that it's a lot like > UNIX. UNIX presupposes lots of special-purpose applications doing rather > specific and well-defined things, and that is a decreasingly accurate > reflection of the way people write applications. All these security > extensions get extremely messy the moment you have general-purpose > applications that you want to be able to do some things some times, and > other things other times, and where the nature of the protections you want > depends on, and changes with, the whim of the user. The complex structure > of modern UNIX applications doesn't help (lots of dependent libraries, > files, interpreters, etc), because it almost instantly pushes the package > dependency problem into the access control problem. I don't think it's > hopeless, but I think that any answer that looks simple is probably wrong > by definition. :-) I think that the per-process namespaces are useful, and can be added to the existing Unix model with quite favourable consequences. On the other hand, I do not think that security is the most important application of the namespaces, or even have a direct relation to it. Implementing namespaces for FreeBSD looks as an doable and quite interesting project for me :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-security/attachments/20080724/e0ef874e/attachment.pgp From julian at elischer.org Thu Jul 24 15:52:58 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jul 24 16:43:18 2008 Subject: A new kind of security needed In-Reply-To: <20080724100439.D63347@fledge.watson.org> References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> <20080724100439.D63347@fledge.watson.org> Message-ID: <4888A217.9000109@elischer.org> Robert Watson wrote: > > On Thu, 24 Jul 2008, Kostik Belousov wrote: > >>> Lots of people care a lot about plan9. The problem is that it's a >>> lot like UNIX. UNIX presupposes lots of special-purpose applications >>> doing rather specific and well-defined things, and that is a >>> decreasingly accurate reflection of the way people write >>> applications. All these security extensions get extremely messy the >>> moment you have general-purpose applications that you want to be able >>> to do some things some times, and other things other times, and where >>> the nature of the protections you want depends on, and changes with, >>> the whim of the user. The complex structure of modern UNIX >>> applications doesn't help (lots of dependent libraries, files, >>> interpreters, etc), because it almost instantly pushes the package >>> dependency problem into the access control problem. I don't think >>> it's hopeless, but I think that any answer that looks simple is >>> probably wrong by definition. :-) >> >> I think that the per-process namespaces are useful, and can be added >> to the existing Unix model with quite favourable consequences. On the >> other hand, I do not think that security is the most important >> application of the namespaces, or even have a direct relation to it. >> >> Implementing namespaces for FreeBSD looks as an doable and quite >> interesting project for me :). > > Sounds good to me :-). there is some work going on by the Verio guys and by others with some namespace separation.. > > As with all such project (variant symlinks, process-local name spaces, > etc), do be very careful about security -- often as not, such projects > risk tripping over problems with privilege-escalated processes, such as > setuid binaries, etc, which place strong trust in the file system name > space. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From dillon at apollo.backplane.com Thu Jul 24 16:51:46 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Jul 24 16:51:53 2008 Subject: A new kind of security needed References: <884CB541-7977-4EF1-9B72-7226BDF30188@patpro.net> <20080717085136.B87887@fledge.watson.org> <05661513-E0DA-4B33-BD4E-FCF73943F332@orthanc.ca> <20080724090549.G63347@fledge.watson.org> <20080724085910.GG97161@deviant.kiev.zoral.com.ua> <20080724100439.D63347@fledge.watson.org> Message-ID: <200807241639.m6OGda4b004216@apollo.backplane.com> Doesn't OpenBSD have a syscall filtering mechanic where one can restrict the file paths the program is allowed to access? What I would like to see is the ability to just wrap an application with a few process-tracked control directives which restricts what portion of the filesystem and kernel namespace the program (and all its children)" can then access. So, e.g. something like: #!/bin/csh # pmac $$ << EOF restrict all allow-read ~/.firefox /usr/pkg/bin allow-read /etc allow-write ~/.firefox ~/download allow-connect <<<<<< ok that probably would be allow-connect named a gaping hole, but... exec firefox ... EOF It seems to me it would be fairly simple filter to make. The problem with using different usernames, jails, chroots... the problem with all of that is that they are not fine-grained mechanisms and it is seriously inconvenient to set up on an application-by-application basis. -Matt Matthew Dillon From phk at phk.freebsd.dk Thu Jul 24 18:07:56 2008 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Jul 24 18:08:03 2008 Subject: A new kind of security needed In-Reply-To: Your message of "Thu, 24 Jul 2008 09:39:36 MST." <200807241639.m6OGda4b004216@apollo.backplane.com> Message-ID: <60254.1216921273@critter.freebsd.dk> In message <200807241639.m6OGda4b004216@apollo.backplane.com>, Matthew Dillon w rites: > Doesn't OpenBSD have a syscall filtering mechanic where one can restrict > the file paths the program is allowed to access? Yes they do. Really smart programs modify the strings after the check and get to access the files anyway. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From julian at elischer.org Thu Jul 24 18:23:26 2008 From: julian at elischer.org (Julian Elischer) Date: Thu Jul 24 18:27:35 2008 Subject: A new kind of security needed In-Reply-To: <60254.1216921273@critter.freebsd.dk> References: <60254.1216921273@critter.freebsd.dk> Message-ID: <4888C882.30707@elischer.org> Poul-Henning Kamp wrote: > In message <200807241639.m6OGda4b004216@apollo.backplane.com>, Matthew Dillon w > rites: >> Doesn't OpenBSD have a syscall filtering mechanic where one can restrict >> the file paths the program is allowed to access? > > Yes they do. > > Really smart (multithreaded) > programs modify the strings after the check and get > to access the files anyway. though it's not always successful. It's kind of strange that they don't just copyin the name. > From dillon at apollo.backplane.com Thu Jul 24 23:20:26 2008 From: dillon at apollo.backplane.com (Matthew Dillon) Date: Thu Jul 24 23:20:33 2008 Subject: A new kind of security needed References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> Message-ID: <200807242320.m6ONKPgW007279@apollo.backplane.com> Well, what we are talking about here is not just copying OpenBSD, but perhaps providing a similar feature that doesn't have the same security failings. I think the best way to approach the problem is to work out the desired userland API first... find the easiest and most convenient way to wrap an application, what kind of features are desired, etc, and then implement it. It seems to me that while there are many system calls which can indirectly provide filesystem accessibility (1), the biggest guns are the ones which have to run through namei(). That bodes very well for being able to code up namespace controls that would also properly operate across softlinks. FreeBSD's namei() does do a copyinstr()... at that point the path and its various components are in kernel space. The only gotcha that I see is how to match directory-relative components against global paths. You might need a working kernel-side CWD for that. I dunno, I haven't thought that far ahead. (note 1): For a production system I think one must separate recovery from exploitation. The idea of having namespace restrictions is not to prevent the exploitation from occuring, but instead to prevent it from causing so much damage that the sysad is forced to compare the entire set of accessible filesystems against backups to revalidate the system. -Matt Matthew Dillon From tim at clewlow.org Fri Jul 25 03:18:28 2008 From: tim at clewlow.org (Tim Clewlow) Date: Fri Jul 25 03:18:36 2008 Subject: A new kind of security needed In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> Message-ID: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> > Well, what we are talking about here is not just copying > OpenBSD, > but perhaps providing a similar feature that doesn't have the > same > security failings. > > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way > to wrap > an application, what kind of features are desired, etc, and then > implement it. > > It seems to me that while there are many system calls which can > indirectly provide filesystem accessibility (1), the biggest > guns are > the ones which have to run through namei(). That bodes very > well for > being able to code up namespace controls that would also > properly operate > across softlinks. FreeBSD's namei() does do a copyinstr()... at > that > point the path and its various components are in kernel space. > > The only gotcha that I see is how to match directory-relative > components against global paths. You might need a working > kernel-side > CWD for that. I dunno, I haven't thought that far ahead. > > (note 1): For a production system I think one must separate > recovery > from exploitation. The idea of having namespace restrictions is > not > to prevent the exploitation from occuring, but instead to > prevent > it from causing so much damage that the sysad is forced to > compare the > entire set of accessible filesystems against backups to > revalidate > the system. > > -Matt Some more thoughts. The existing DAC method already provides sufficient protection (we all hope) to system objects, often via root/wheel. What we really want is a mechanism to protect user data from being clobbered by an errant program. By extending the traditional DAC with an Application ID (AID) the kernel could allow or deny processes that are part of a particular application from accessing a file based on the rwx flags of the AID for a particular user file. Note 1: the AID would only be tested if/after normal DAC has granted access. Note 2: It may be desirable to limit this extention to a particular section of the file system, eg /home/ - perhaps via a configuration setting somewhere. Note 3: There would need to be a way of guaranteeing unique identification of an application, maybe the full path / binary name. Note 4: It would not need to be an extension to DAC, it could just as easily be a layer added on top. Anyway, to summarise, my thinking is that: to protect all/most of a users data from a badly behaving user process (eg firefox), there would need to be a way to allow/deny specific applications from accessing specific files - and therefor at a minimum there must be the equivalent of an Application ID to match against. Just some thoughts, Tim. PS - This may already be covered by MAC, I should really read more about that :-) From sziszi at bsd.hu Fri Jul 25 05:38:55 2008 From: sziszi at bsd.hu (Szilveszter Adam) Date: Fri Jul 25 05:39:03 2008 Subject: A new kind of security needed In-Reply-To: <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> Message-ID: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: > Some more thoughts. <...> > The existing DAC method already provides sufficient protection (we > all hope) to system objects, often via root/wheel. What we really > want is a mechanism to protect user data from being clobbered by an > errant program. By extending the traditional DAC with an Application > ID (AID) the kernel could allow or deny processes that are part of a > particular application from accessing a file based on the rwx flags > of the AID for a particular user file. This idea may work quite well for a server (and already does, there are several implementations out there). But for an interactive desktop software that a user drives in real-time (like firefox, as you mention) this does not work. Think about it: You want firefox to not touch your files in your ~ directory, so you configure FF in this way. But then, somehow you come to the very unlikely idea that you want to actually download something from the web. (eg a PDF manual for the latest gadget that you bought) Or upload one of your photos to an online album (as Robert Watson has already pointed out). What now? FF is not allowed to touch your files, so will not be able to do at least the first case (because that requires write access to some location in order to save the file) but quite possibly the second may not work either, after all, why would you want FF to read your office documents, so you have already denied that as well. There is no secure and usable solution to this problem, as Robert has already pointed out. The whole notion of sandboxing rests on the idea that the behaviour of an application is very deterministic (it only does A, and never, ever, anything else, during normal operation) and not very complex. Typical desktop software is already very complex, has a lot of functions and is not deterministic almost by design: there is a human sitting in front of it, doing this on one occassion and something else on another. If you allow everything that the functions of the software might cover (or only a reasonable set) you are already almost at the status-quo: You have to allow access to many-many objects, many of which are not in use most of the time, some are not in use ever, but who knows. Anything else is bad: Requiring reconfiguration of the sandbox everytime you want to save a file and then setting it back does not work. Prompting the user "Are you sure you want FF to access your files?" is bad. ("Yes, do it already!") Using "trusted" components, services, or locations to hack around it is bad. (When push comes to shove, there is nothing that could be "trusted" on a normal PC, not even the hardware in this age of mobile computing.) So no, the idea itself is interesting but does not work in the general case. It does work in specific cases though, and there it should be considered. (For example in a public Internet terminal you have no business to save anything on the local hard drive, so there is no need to allow that. But then, the desired effect can be reached much more easily there even with the existing access control.) -- Regards: Szilveszter ADAM Budapest Hungary From chris at noncombatant.org Sun Jul 27 03:48:04 2008 From: chris at noncombatant.org (Chris Palmer) Date: Sun Jul 27 03:48:11 2008 Subject: A new kind of security needed In-Reply-To: <200807242320.m6ONKPgW007279@apollo.backplane.com> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> Message-ID: <2E998E52-257B-47BF-917F-4FB41E9D5854@noncombatant.org> On Jul 24, 2008, at 4:20 PM, Matthew Dillon wrote: > I think the best way to approach the problem is to work out the > desired > userland API first... find the easiest and most convenient way to > wrap > an application, what kind of features are desired, etc, and then > implement it. I think Szilveszter Adam was right to point out that any such system needs to work with the user, and support what the user needs in a way that fits well with they interact with an application. Rather than being the easiest and most convenient (for the developer), the API should be the simplest means to provide what the user needs. That may have been what you meant when you said "what kinds of features are desired", though. There's a great book that covers a wide range of security and usability topics called *Security and Usability: Designing Secure Systems That People Can Use*, by Cranor and Garfinkel. I highly recommend it. http://books.google.com/books?id=wDVhy9EyEAEC&dq=lorrie+faith+cranor+simson+garfinkel+usable+security&pg=PP1&ots=BOKHuIHr2u&sig=e-DoE4ap0ldkxffFqUs8LaROmYc&hl=en&sa=X&oi=book_result&resnum=1&ct=result From mattjreimer at gmail.com Mon Jul 28 19:28:40 2008 From: mattjreimer at gmail.com (Matt Reimer) Date: Mon Jul 28 19:28:46 2008 Subject: A new kind of security needed In-Reply-To: <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Message-ID: On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam wrote: > On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: >> Some more thoughts. > > <...> > >> The existing DAC method already provides sufficient protection (we >> all hope) to system objects, often via root/wheel. What we really >> want is a mechanism to protect user data from being clobbered by an >> errant program. By extending the traditional DAC with an Application >> ID (AID) the kernel could allow or deny processes that are part of a >> particular application from accessing a file based on the rwx flags >> of the AID for a particular user file. > > This idea may work quite well for a server (and already does, there are > several implementations out there). But for an interactive desktop > software that a user drives in real-time (like firefox, as you mention) > this does not work. Think about it: You want firefox to not touch your > files in your ~ directory, so you configure FF in this way. But then, > somehow you come to the very unlikely idea that you want to actually > download something from the web. (eg a PDF manual for the latest gadget > that you bought) Or upload one of your photos to an > online album (as Robert Watson has already pointed out). What now? FF is > not allowed to touch your files, so will not be able to do at least the > first case (because that requires write access to some location in order > to save the file) but quite possibly the second may not work either, > after all, why would you want FF to read your office documents, so you > have already denied that as well. > > There is no secure and usable solution to this problem, as Robert has > already pointed out. The whole notion of sandboxing rests on the idea > that the behaviour of an application is very deterministic (it only does > A, and never, ever, anything else, during normal operation) and not very > complex. Typical desktop software is already very complex, has a lot of > functions and is not deterministic almost by design: there is a human > sitting in front of it, doing this on one occassion and something else > on another. If you allow everything that the functions of the software > might cover (or only a reasonable set) you are already almost at the > status-quo: You have to allow access to many-many objects, many of which > are not in use most of the time, some are not in use ever, but who > knows. My idea was to basically have a secure file picker that grants the app (e.g. Firefox) access to the file, in a way that would be transparent to the user. For example, when Firefox wants to save a PDF it displays the file picker as usual and the file is saved. Underneath what's happening is that Firefox talks to the trusted system filepicker via a socket, and depending on the user's input it grants access to the file, whether temporarily or permanently. If Firefox is using the standard GTK file picker, then only GTK would need to be changed. Matt From jeff+freebsd at wagsky.com Tue Jul 29 00:25:24 2008 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Tue Jul 29 00:25:32 2008 Subject: ipfw "bug" - recv any = not recv any Message-ID: <488E5F5A.3050209@wagsky.com> I hesitate to call this a "bug" as I don't know all the history behind the ipfw2 decisions, so let me toss this out there and see I'm just missing something. Overview ======== The negated operator, "not recv any" was taken to mean "any packet never received by an interface" believed to be equivalent to "any packet that originated on the current machine's interfaces" My logic being: * If "recv any" means "received by any interface" * then "not recv any" means "not received by any interface" (which should be locally-generated packets) In practice, both "recv any" and "not recv any" appear to be "no-op" phrases. Application was to be able to discriminate between: * Packets from the current host that are going out (and need stateful rules of the form my.outside.IP <==> some.rest.of.world.host) * Packets received from "inside" hosts that had been NAT-ed (and need to be let out without another stateful rule, as one was created when the packet was received of the form my.private.net.IP <==> some.rest.of.world.host) Agreed, there are ways to solve this in ipfw2 (tagging, for one), but the issue is that there is at least one "reasonable" application for the phrase and that the behavior is not what one might expect, in a potentially dangerous way. To replicate ============ 1) Identify a "blank" rule [root@wildside /etc/firewall]# ipfw list 20000 ipfw: rule 20000 does not exist 2) create a rule that does not modify traffic, but logs matches, using "not recv any" [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any out not recv any 20000 count ip from any to any out 2a) Expect that (2) would have indication that "not recv any" was present 3) delete the rule just created and create another that is identical, but without the "not" modifier [root@wildside /etc/firewall]# ipfw delete 20000 [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any out recv any 20000 count ip from any to any out 3a) Note that the generated rule is the same (enabling logging confirms that both "recv any" and "not recv any" appear to be NOOPs) Discussion ========== I didn't find much here, but did dig up an older post that looked to be discussing this kind of thing > From: Patrick O'Reilly > Date: 11 Mar 2001 23:47:44 In my opinion, the following would be "ideal" 1) "recv any" -- matches packets that have been received by the host through one of its interfaces 2) "not recv any" -- does not match packets that have been received by the host through one of its interfaces Unfortunately, implementing (1) would likely break a lot of people's rule sets (2), however, I can't immediately see being used without expecting that it would fail to match packets that were received by the current host, so its implementation would be a bit "safer" for the community I took a quick look at the code, as Patrick's message suggests matching "NULL" > Likewise, Rod Grimes suggested: > ------------------ > No, but it should be trivial to patch the code to allow your !any, if > you consider that !any is the same as =null: > > ipfw count ip from any to any in recv null > > Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be null > for packets originated on the local machine. /usr/src/sys/netinet/ip_fw2.c -- seemed to be the place, but the start of the s/r that caught my eye is not immediately suggesting that there is a way to match a null ifp without patching code as its trapped before the check is done static int iface_match(struct ifnet *ifp, ipfw_insn_if *cmd) { if (ifp == NULL) /* no iface with this packet, match fails */ return 0; /* Check by name or by IP address */ if (cmd->name[0] != '\0') { /* match by name */ /* Check name */ if (cmd->p.glob) { if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) return(1); } else { if (strncmp(ifp->if_xname, cmd->name, IFNAMSIZ) == 0) return(1); } Thoughts? Worth more than just a doc change? Thanks for the time, Jeff From tim at clewlow.org Tue Jul 29 02:36:30 2008 From: tim at clewlow.org (Tim Clewlow) Date: Tue Jul 29 02:36:37 2008 Subject: A new kind of security needed In-Reply-To: References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Message-ID: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> On Thu, Jul 24, 2008 at 9:56 PM, Szilveszter Adam wrote: > On Fri, Jul 25, 2008 at 01:18:25PM +1000, Tim Clewlow wrote: >> Some more thoughts. > > <...> > >> The existing DAC method already provides sufficient protection (we >> all hope) to system objects, often via root/wheel. What we really >> want is a mechanism to protect user data from being clobbered by an >> errant program. By extending the traditional DAC with an Application >> ID (AID) the kernel could allow or deny processes that are part of a >> particular application from accessing a file based on the rwx flags >> of the AID for a particular user file. > > This idea may work quite well for a server (and already does, there are > several implementations out there). But for an interactive desktop > software that a user drives in real-time (like firefox, as you mention) > this does not work. Think about it: You want firefox to not touch your > files in your ~ directory, so you configure FF in this way. But then, > somehow you come to the very unlikely idea that you want to actually > download something from the web. (eg a PDF manual for the latest gadget > that you bought) Or upload one of your photos to an > online album (as Robert Watson has already pointed out). What now? FF is > not allowed to touch your files, so will not be able to do at least the > first case (because that requires write access to some location in order > to save the file) but quite possibly the second may not work either, > after all, why would you want FF to read your office documents, so you > have already denied that as well. > > There is no secure and usable solution to this problem, as Robert has > already pointed out. The whole notion of sandboxing rests on the idea > that the behaviour of an application is very deterministic (it only does > A, and never, ever, anything else, during normal operation) and not very > complex. Typical desktop software is already very complex, has a lot of > functions and is not deterministic almost by design: there is a human > sitting in front of it, doing this on one occassion and something else > on another. If you allow everything that the functions of the software > might cover (or only a reasonable set) you are already almost at the > status-quo: You have to allow access to many-many objects, many of which > are not in use most of the time, some are not in use ever, but who > knows. I'd like to offer a possible solution that I believe can be both secure and usable. This will use the AID concept outlined above. (Note, when I refer to a rwx flag in the following paragraphs, I am talking about a flag in a 4th group, ie in addition to the normal user/group/other set of flags, lets call it the app set - in addition, there is an associated AID for any of the 3 of those flags that have been set, ie there can be up to 3 different application ID's set for a single user file) When a user file is created, the kernel sets the read flag, and sets the AID for that flag to 0 (0 being a special value), the intention being that this means any application can read the file. Next the kernel sets the the write flag, and set the AID for the write flag to be the same as the application that is creating the file. (If at some later time the user wants to limit reading to a single application, then they can with the equivalent of a chmod for AID) Using this method, an errant application will only be able to damage data files that it owns. It also means if an application wants to create a new file, then it can. This solves the problems presented above. (If the file about to be created already exists, then as long as the application owns the file, it should be allowed to overwrite it as it should already have write access) For systems with this enabled, ie desktop systems, this would, for the majority of data files, work quietly in the background without the user even being aware of what is going on. One place where some work would be required is during the installation or upgrade of an application, ie as part of the installation, there would need to be some provision for acquiring the AID that the application will eventually be given by the kernel, and then setting the write AID value accordingly for any data / config files that may be created during installation. This is part of what I was referring to when I said the implementation of AID would create a system that has some important differences from a vanilla FreeBSD system. Anyway, I just wanted to offer this as being a potential way of overcoming some of the pitfalls pointed out above. Yes I know I am being persistant, and probably a bit annoying too. I dont mean it to be, I just would like to explore the possibilities of enhanced security that may be available. Feel free to shoot holes in any/all of this, I may have painted a big target here :-) Cheers, Tim. From sziszi at bsd.hu Tue Jul 29 05:13:00 2008 From: sziszi at bsd.hu (Szilveszter Adam) Date: Tue Jul 29 05:13:07 2008 Subject: A new kind of security needed In-Reply-To: References: <60254.1216921273@critter.freebsd.dk> <4888C882.30707@elischer.org> <200807242320.m6ONKPgW007279@apollo.backplane.com> <51095.192.168.1.10.1216955905.squirrel@192.168.1.100> <20080725045654.GA1572@baranyfelhocske.buza.adamsfamily.xx> Message-ID: <20080729051241.GA1995@baranyfelhocske.buza.adamsfamily.xx> On Mon, Jul 28, 2008 at 12:28:38PM -0700, Matt Reimer wrote: > My idea was to basically have a secure file picker that grants the app > (e.g. Firefox) access to the file, in a way that would be transparent > to the user. For example, when Firefox wants to save a PDF it displays > the file picker as usual and the file is saved. Underneath what's > happening is that Firefox talks to the trusted system filepicker via a > socket, and depending on the user's input it grants access to the > file, whether temporarily or permanently. > > If Firefox is using the standard GTK file picker, then only GTK would > need to be changed. Well, you have snipped the part of my message that deals with this: The mere idea of "trusted" system components is faulty. There is nothing on a standard PC that you can trust, when it comes down to it. Not even the hardware. Remember, if you can install a new application, a malware author can do the same. It only takes one hole in such a "trusted" service, and all of your machine is 0wned. There is a very long history of such disasters on Windows, where it is quite common to split software in two parts: one that runs with priviledge in the background as a service (you could say a daemon on Unix) and one that runs as the user and displays the GUI. Many anti-virus products work this way. There have been just too many cases when this design just blew up and led to a system compromise instead of just eg deleting all the jpg-s of the user. Security is a complex matter... -- Regards: Szilveszter ADAM Budapest Hungary From julian at elischer.org Tue Jul 29 04:59:25 2008 From: julian at elischer.org (Julian Elischer) Date: Tue Jul 29 11:48:01 2008 Subject: ipfw "bug" - recv any = not recv any In-Reply-To: <488E5F5A.3050209@wagsky.com> References: <488E5F5A.3050209@wagsky.com> Message-ID: <488EA31B.9070707@elischer.org> Jeff Kletsky wrote: > I hesitate to call this a "bug" as I don't know all the history behind > the ipfw2 decisions, so let me toss this out there and see I'm just > missing something. > > Overview > ======== > > The negated operator, "not recv any" was taken to mean "any packet never > received by an interface" believed to be equivalent to "any packet that > originated on the current machine's interfaces" > > My logic being: > * If "recv any" means "received by any interface" > * then "not recv any" means "not received by any interface" (which > should be locally-generated packets) > > In practice, both "recv any" and "not recv any" appear to be "no-op" > phrases. > > > > Application was to be able to discriminate between: > > * Packets from the current host that are going out > (and need stateful rules of the form > my.outside.IP <==> some.rest.of.world.host) > > * Packets received from "inside" hosts that had been NAT-ed > (and need to be let out without another stateful rule, as one was > created when the packet was received of the form > my.private.net.IP <==> some.rest.of.world.host) > > Agreed, there are ways to solve this in ipfw2 (tagging, for one), but > the issue is that there is at least one "reasonable" application for the > phrase and that the behavior is not what one might expect, in a > potentially dangerous way. > > To replicate > ============ > > 1) Identify a "blank" rule > > [root@wildside /etc/firewall]# ipfw list 20000 > ipfw: rule 20000 does not exist > > 2) create a rule that does not modify traffic, but logs matches, using > "not recv any" > > [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any > out not recv any > 20000 count ip from any to any out > > 2a) Expect that (2) would have indication that "not recv any" was present > > 3) delete the rule just created and create another that is identical, > but without the "not" modifier > > [root@wildside /etc/firewall]# ipfw delete 20000 > [root@wildside /etc/firewall]# ipfw add 20000 count all from any to any > out recv any > 20000 count ip from any to any out > > 3a) Note that the generated rule is the same > > (enabling logging confirms that both "recv any" and "not recv any" > appear to be NOOPs) > > > Discussion > ========== > > I didn't find much here, but did dig up an older post that looked to be > discussing this kind of thing > > > > > From: Patrick O'Reilly > > Date: 11 Mar 2001 23:47:44 > > > In my opinion, the following would be "ideal" > > 1) "recv any" -- matches packets that have been received by the host > through one of its interfaces > 2) "not recv any" -- does not match packets that have been received by > the host through one of its interfaces > > Unfortunately, implementing (1) would likely break a lot of people's > rule sets > > (2), however, I can't immediately see being used without expecting that > it would fail to match packets that were received by the current host, > so its implementation would be a bit "safer" for the community > how does "not recv *" (appropriatly escaped for your shell) do? > > > I took a quick look at the code, as Patrick's message suggests matching > "NULL" > > > Likewise, Rod Grimes suggested: > > ------------------ > > No, but it should be trivial to patch the code to allow your !any, if > > you consider that !any is the same as =null: > > > ipfw count ip from any to any in recv null > > > Ie, the recv keyword looks at the ifp in the mbuff, the ifp will be > null > > for packets originated on the local machine. > > /usr/src/sys/netinet/ip_fw2.c -- seemed to be the place, but the start > of the s/r that caught my eye is not immediately suggesting that there > is a way to match a null ifp without patching code as its trapped before > the check is done > > static int > iface_match(struct ifnet *ifp, ipfw_insn_if *cmd) > { > if (ifp == NULL) /* no iface with this packet, match fails */ > return 0; > /* Check by name or by IP address */ > if (cmd->name[0] != '\0') { /* match by name */ > /* Check name */ > if (cmd->p.glob) { > if (fnmatch(cmd->name, ifp->if_xname, 0) == 0) > return(1); > } else { > if (strncmp(ifp->if_xname, cmd->name, IFNAMSIZ) == 0) > return(1); > } > > > > Thoughts? > > Worth more than just a doc change? > > Thanks for the time, > > Jeff > > > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" From jeff+freebsd at wagsky.com Tue Jul 29 14:38:16 2008 From: jeff+freebsd at wagsky.com (Jeff Kletsky) Date: Tue Jul 29 14:38:23 2008 Subject: ipfw "bug" - recv any = not recv any Message-ID: <488F2B57.7000706@wagsky.com> > In practice, both "recv any" and "not recv any" appear to be "no-op" > phrases. > [...] > In my opinion, the following would be "ideal" > > 1) "recv any" -- matches packets that have been received by the host > through one of its interfaces > 2) "not recv any" -- does not match packets that have been received by > the host through one of its interfaces > > Unfortunately, implementing (1) would likely break a lot of people's > rule sets > > (2), however, I can't immediately see being used without expecting that > it would fail to match packets that were received by the current host, > so its implementation would be a bit "safer" for the community > Julian Elishcher suggested: > how does "not recv *" (appropriatly escaped for your shell) do? This does appear to "work as desired" -- suggesting documentation clarification rather than functionality change My apologies for not posting to the ipfw list. Jeff From mail at maxlor.com Wed Jul 30 11:41:51 2008 From: mail at maxlor.com (Benjamin Lutz) Date: Wed Jul 30 11:42:22 2008 Subject: A new kind of security needed In-Reply-To: <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> References: <60254.1216921273@critter.freebsd.dk> <51075.192.168.1.10.1217298987.squirrel@192.168.1.100> Message-ID: <200807301300.54490.mail@maxlor.com> On Tuesday 29 July 2008 04:36:27 Tim Clewlow wrote: > I'd like to offer a possible solution that I believe can be both > secure and usable. This will use the AID concept outlined above. > > (Note, when I refer to a rwx flag in the following paragraphs, I am > talking about a flag in a 4th group, ie in addition to the normal > user/group/other set of flags, lets call it the app set - in > addition, there is an associated AID for any of the 3 of those flags > that have been set, ie there can be up to 3 different application > ID's set for a single user file) > > When a user file is created, the kernel sets the read flag, and sets > the AID for that flag to 0 (0 being a special value), the intention > being that this means any application can read the file. Next the > kernel sets the the write flag, and set the AID for the write flag > to be the same as the application that is creating the file. (If at > some later time the user wants to limit reading to a single > application, then they can with the equivalent of a chmod for AID) > > Using this method, an errant application will only be able to damage > data files that it owns. It also means if an application wants to > create a new file, then it can. This solves the problems presented > above. (If the file about to be created already exists, then as long > as the application owns the file, it should be allowed to overwrite > it as it should already have write access) Can you elaborate a bit more on what the AID for the x permission is going to look like? Obviously, there have to be applications with very wide-ranging permissions (a filemanager, tools like cp and mv, or the tool used to set AID permissions). Being able to execute them often means being able to change the target file freely and non-interactively (with cp for example). So most applications should not be able to execute cp, right?. However, what about programs whose main job it is to launch other processes, such as /bin/sh. How are you going to prevent some evil application from running /bin/sh -c "cp /dev/zero /very/important/file"? If you're now thinking, limit who can run /bin/sh, consider that some application launching programs can be controlled in other ways; KDE apps can often be controlled with DCOP for example. Cheers Benjamin