From owner-freebsd-security Sun Jun 8 09:21:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA19444 for security-outgoing; Sun, 8 Jun 1997 09:21:55 -0700 (PDT) Received: from yoss.canweb.net (root@yoss.canweb.net [207.139.235.8]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA19435 for ; Sun, 8 Jun 1997 09:21:53 -0700 (PDT) Received: from localhost (yossman@localhost) by yoss.canweb.net (8.8.5/8.8.5) with SMTP id MAA09225 for ; Sun, 8 Jun 1997 12:17:07 -0400 (EDT) Date: Sun, 8 Jun 1997 12:17:06 -0400 (EDT) From: yossman To: security@freebsd.org Subject: ftpd security weakness on FreeBSD (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk one of my users sent me this. just wondering if anyone has heard about this before. he claims freebsd.org is affected. yossman ------------------------------------------------------------------------ Yossarian Holmberg (yossman) yossman@canweb.net System Administrator, National Online http://www.canweb.net/~yossman/ my statements are my own, not my employer's -- i do not speak for them. '... and if i die, before i learn to speak .. can money pay for all the days i've lived awake but half asleep?' -- Primitive Radio Gods, "Standing Outside a Broken Phone Booth With Money In My Hand" ---------- Forwarded message ---------- Date: Sun, 1 Jun 1997 22:14:03 +1000 To: yossman@canweb.net Subject: ftpd security weakness on FreeBSD Yoss, FreeBSD's ftpd has a bug (although I dont know if its a fetaure of FTP protocol or not (maybe newer RFC's discuss it)). Its possible to semi-hijack the ftpd into doing portscans to arbitrary hosts/ports. A good replacement would be wu-ftp 2.4.2 beta 11 or later. From owner-freebsd-security Sun Jun 8 15:48:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20856 for security-outgoing; Sun, 8 Jun 1997 15:48:36 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA20850 for ; Sun, 8 Jun 1997 15:48:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id PAA00116; Sun, 8 Jun 1997 15:49:16 -0700 (PDT) Message-Id: <199706082249.PAA00116@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: yossman cc: security@FreeBSD.ORG Subject: Re: ftpd security weakness on FreeBSD (fwd) In-reply-to: Your message of "Sun, 08 Jun 1997 12:17:06 EDT." From: David Greenman Reply-To: dg@root.com Date: Sun, 08 Jun 1997 15:49:16 -0700 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >one of my users sent me this. just wondering if anyone has heard about >this before. he claims freebsd.org is affected. ... >---------- Forwarded message ---------- >Date: Sun, 1 Jun 1997 22:14:03 +1000 >To: yossman@canweb.net >Subject: ftpd security weakness on FreeBSD > >Yoss, > >FreeBSD's ftpd has a bug (although I dont know if its a fetaure of FTP protocol >or not (maybe newer RFC's discuss it)). >Its possible to semi-hijack the ftpd into doing portscans to arbitrary >hosts/ports. A good replacement would be wu-ftp 2.4.2 beta 11 or later. There are options for disallowing PORT commands to remote ports less than 1024 (priviledged ports) or addresses other than the originator's. Enabling these options will violate the FTP RFC and might break support for ftp proxies. The options were added to FreeBSD on Aug. 5, '96. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Sun Jun 8 19:05:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA27613 for security-outgoing; Sun, 8 Jun 1997 19:05:23 -0700 (PDT) Received: from mail.telcentral.com (mail.telcentral.com [207.211.70.7]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA27608 for ; Sun, 8 Jun 1997 19:05:20 -0700 (PDT) Received: from mail.telcentral.com by mail.telcentral.com (NTMail 3.02.10) with ESMTP id la009579 for ; Sun, 8 Jun 1997 21:05:11 -0500 Message-Id: <3.0.32.19970608210325.009c66a0@mail.telcentral.net> X-Sender: darkstar@mail.telcentral.net X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sun, 08 Jun 1997 21:03:28 -0400 To: dg@root.com, yossman From: Mark Rollings Subject: Re: ftpd security weakness on FreeBSD (fwd) Cc: security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Above any of the below mentioned deficiencies in the ftpd, CERT recently released an advisory on the ftpd for practically all OS's. The replacement mentioned below is not satisfactory in order to properly prevent attacks covered in the advisory. wu-ftp-2.4.2-beta-13 is the correct ftpd to compile for FreeBSD based machines. The advisory can be found in complete form at CERT. www.cert.org. Mark Rollings Systems Administrator TelCentral Internet www.telcentral.net darkstar@telcentral.net At 03:49 PM 6/8/97 -0700, David Greenman wrote: >>one of my users sent me this. just wondering if anyone has heard about >>this before. he claims freebsd.org is affected. >... >>---------- Forwarded message ---------- >>Date: Sun, 1 Jun 1997 22:14:03 +1000 >>To: yossman@canweb.net >>Subject: ftpd security weakness on FreeBSD >> >>Yoss, >> >>FreeBSD's ftpd has a bug (although I dont know if its a fetaure of FTP protocol >>or not (maybe newer RFC's discuss it)). >>Its possible to semi-hijack the ftpd into doing portscans to arbitrary >>hosts/ports. A good replacement would be wu-ftp 2.4.2 beta 11 or later. > > There are options for disallowing PORT commands to remote ports less than >1024 (priviledged ports) or addresses other than the originator's. Enabling >these options will violate the FTP RFC and might break support for ftp >proxies. The options were added to FreeBSD on Aug. 5, '96. > >-DG > >David Greenman >Core-team/Principal Architect, The FreeBSD Project > From owner-freebsd-security Sun Jun 8 20:00:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA29878 for security-outgoing; Sun, 8 Jun 1997 20:00:05 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA29833 for ; Sun, 8 Jun 1997 19:59:58 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id WAA23765; Sun, 8 Jun 1997 22:56:06 -0400 (EDT) From: Adam Shostack Message-Id: <199706090256.WAA23765@homeport.org> Subject: Re: ftpd security weakness on FreeBSD (fwd) In-Reply-To: <3.0.32.19970608210325.009c66a0@mail.telcentral.net> from Mark Rollings at "Jun 8, 97 09:03:28 pm" To: darkstar@telcentral.net (Mark Rollings) Date: Sun, 8 Jun 1997 22:56:06 -0400 (EDT) Cc: dg@root.com, yossman@yoss.canweb.net, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mark Rollings wrote: | Above any of the below mentioned deficiencies in the ftpd, CERT recently | released an advisory on the ftpd for practically all OS's. The replacement | mentioned below is not satisfactory in order to properly prevent attacks | covered in the advisory. wu-ftp-2.4.2-beta-13 is the correct ftpd to | compile for FreeBSD based machines. The advisory can be found in complete | form at CERT. www.cert.org. Could I suggest that the FTPd from logdaemon, which is small, feature poor, and probably more secure than WU-ftpd would be a more appropriate default? People who need the functionality of WU can install it, those that dont't get a smaller, more appropriate tool. Adam -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Sun Jun 8 20:30:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA01130 for security-outgoing; Sun, 8 Jun 1997 20:30:30 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA01125 for ; Sun, 8 Jun 1997 20:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with SMTP id UAA00434; Sun, 8 Jun 1997 20:31:07 -0700 (PDT) Message-Id: <199706090331.UAA00434@implode.root.com> X-Authentication-Warning: implode.root.com: localhost [127.0.0.1] didn't use HELO protocol To: Mark Rollings cc: yossman , security@FreeBSD.ORG Subject: Re: ftpd security weakness on FreeBSD (fwd) In-reply-to: Your message of "Sun, 08 Jun 1997 21:03:28 EDT." <3.0.32.19970608210325.009c66a0@mail.telcentral.net> From: David Greenman Reply-To: dg@root.com Date: Sun, 08 Jun 1997 20:31:07 -0700 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Above any of the below mentioned deficiencies in the ftpd, CERT recently >released an advisory on the ftpd for practically all OS's. The replacement >mentioned below is not satisfactory in order to properly prevent attacks >covered in the advisory. wu-ftp-2.4.2-beta-13 is the correct ftpd to >compile for FreeBSD based machines. The advisory can be found in complete >form at CERT. www.cert.org. The bug I think you're refering to was fixed in FreeBSD prior to the CERT announcement - I was the one who found the bug and alerted CERT and AUSCERT. ...but yes, your advice to avoid pre-beta13 is very important. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project From owner-freebsd-security Mon Jun 9 08:59:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA28675 for security-outgoing; Mon, 9 Jun 1997 08:59:01 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA28665 for ; Mon, 9 Jun 1997 08:58:46 -0700 (PDT) Received: from localhost (cschuber@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) with SMTP id IAA10313; Mon, 9 Jun 1997 08:57:27 -0700 (PDT) Message-Id: <199706091557.IAA10313@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: cschuber@localhost didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: Adam Shostack cc: darkstar@telcentral.net (Mark Rollings), dg@root.com, yossman@yoss.canweb.net, security@FreeBSD.ORG Subject: Re: ftpd security weakness on FreeBSD (fwd) In-reply-to: Your message of "Sun, 08 Jun 1997 22:56:06 EDT." <199706090256.WAA23765@homeport.org> Date: Mon, 09 Jun 1997 08:57:26 -0700 From: Cy Schubert - ITSD Open Systems Group Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Mark Rollings wrote: > | Above any of the below mentioned deficiencies in the ftpd, CERT recently > | released an advisory on the ftpd for practically all OS's. The replacement > | mentioned below is not satisfactory in order to properly prevent attacks > | covered in the advisory. wu-ftp-2.4.2-beta-13 is the correct ftpd to > | compile for FreeBSD based machines. The advisory can be found in complete > | form at CERT. www.cert.org. > > Could I suggest that the FTPd from logdaemon, which is small, > feature poor, and probably more secure than WU-ftpd would be a more > appropriate default? People who need the functionality of WU can > install it, those that dont't get a smaller, more appropriate tool. Another good ftpd daemon is anonftpd. It only supports anonymous ftp and a subset of features. Sites offering an anonymous ftp service could use the anonftpd daemon for anonymous use while running the FreeBSD daemon (or better yet the Kerberos V daemon) behind a TCP/Wrapper off another port. > Adam Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Mon Jun 9 09:11:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29406 for security-outgoing; Mon, 9 Jun 1997 09:11:31 -0700 (PDT) Received: from homeport.org (lighthouse.homeport.org [205.136.65.198]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29398 for ; Mon, 9 Jun 1997 09:11:26 -0700 (PDT) Received: (adam@localhost) by homeport.org (8.8.5/8.6.9) id MAA26597; Mon, 9 Jun 1997 12:05:42 -0400 (EDT) From: Adam Shostack Message-Id: <199706091605.MAA26597@homeport.org> Subject: Re: ftpd security weakness on FreeBSD (fwd) In-Reply-To: <199706091557.IAA10313@passer.osg.gov.bc.ca> from Cy Schubert - ITSD Open Systems Group at "Jun 9, 97 08:57:26 am" To: cschuber@uumail.gov.bc.ca Date: Mon, 9 Jun 1997 12:05:41 -0400 (EDT) Cc: adam@homeport.org, darkstar@telcentral.net, dg@root.com, yossman@yoss.canweb.net, security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL27 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I considered suggesting anonftpd (or Ranum's aftpd, which has more traditional messages). I did not because a lot of people want to be able to ftp inwards, and the anon only option seems a bit more restrictive than is freebsd's bent. I wouldn't oppose it as long as the docs suggested an upgrade path of (a/anon) -> logdaemon -> WUftpd as need for capabilities increases. Adam Cy Schubert - ITSD Open Systems Group wrote: | Another good ftpd daemon is anonftpd. It only supports anonymous ftp and a | subset of features. Sites offering an anonymous ftp service could use the | anonftpd daemon for anonymous use while running the FreeBSD daemon (or | better yet the Kerberos V daemon) behind a TCP/Wrapper off another port. -- "It is seldom that liberty of any kind is lost all at once." -Hume From owner-freebsd-security Mon Jun 9 11:45:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07706 for security-outgoing; Mon, 9 Jun 1997 11:45:34 -0700 (PDT) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07699 for ; Mon, 9 Jun 1997 11:45:27 -0700 (PDT) Received: from localhost (cschuber@localhost) by passer.osg.gov.bc.ca (8.8.5/8.6.10) with SMTP id LAA10915; Mon, 9 Jun 1997 11:44:42 -0700 (PDT) Message-Id: <199706091844.LAA10915@passer.osg.gov.bc.ca> X-Authentication-Warning: passer.osg.gov.bc.ca: cschuber@localhost didn't use HELO protocol Reply-to: cschuber@uumail.gov.bc.ca X-Mailer: MH X-Sender: cschuber To: Adam Shostack cc: cschuber@uumail.gov.bc.ca, darkstar@telcentral.net, dg@root.com, yossman@yoss.canweb.net, security@FreeBSD.ORG Subject: Re: ftpd security weakness on FreeBSD (fwd) In-reply-to: Your message of "Mon, 09 Jun 1997 12:05:41 EDT." <199706091605.MAA26597@homeport.org> Date: Mon, 09 Jun 1997 11:44:42 -0700 From: Cy Schubert - ITSD Open Systems Group Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Wuftpd has some significant security holes in it, especially the realdir() hole, allowing remote exploit of root. The FreeBSD ftp daemon would be much more secure for sites that wish to offer ftp access to local users. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca cschuber@bcsc02.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." > I considered suggesting anonftpd (or Ranum's aftpd, which has more > traditional messages). I did not because a lot of people want to be > able to ftp inwards, and the anon only option seems a bit more > restrictive than is freebsd's bent. > > I wouldn't oppose it as long as the docs suggested an upgrade path of > (a/anon) -> logdaemon -> WUftpd as need for capabilities increases. > > Adam > > > Cy Schubert - ITSD Open Systems Group wrote: > | Another good ftpd daemon is anonftpd. It only supports anonymous ftp and a > | subset of features. Sites offering an anonymous ftp service could use the > | anonftpd daemon for anonymous use while running the FreeBSD daemon (or > | better yet the Kerberos V daemon) behind a TCP/Wrapper off another port. > > > -- > "It is seldom that liberty of any kind is lost all at once." > -Hume > > From owner-freebsd-security Mon Jun 9 14:31:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA15969 for security-outgoing; Mon, 9 Jun 1997 14:31:16 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA15958 for ; Mon, 9 Jun 1997 14:31:09 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id XAA04142 for ; Mon, 9 Jun 1997 23:31:03 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id XAA04462 for security@FreeBSD.ORG; Mon, 9 Jun 1997 23:30:46 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id WAA05619; Mon, 9 Jun 1997 22:55:20 +0200 (CEST) Message-ID: <19970609225520.40070@keltia.freenix.fr> Date: Mon, 9 Jun 1997 22:55:20 +0200 From: Ollivier Robert To: security@FreeBSD.ORG Subject: Re: ftpd security weakness on FreeBSD (fwd) References: <199706090256.WAA23765@homeport.org> <199706091557.IAA10313@passer.osg.gov.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <199706091557.IAA10313@passer.osg.gov.bc.ca>; from Cy Schubert - ITSD Open Systems Group on Mon, Jun 09, 1997 at 08:57:26AM -0700 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3359 AMD-K6 MMX @ 208 MHz Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Cy Schubert - ITSD Open Systems Group: > Another good ftpd daemon is anonftpd. It only supports anonymous ftp and a > subset of features. Sites offering an anonymous ftp service could use the The main problem of anonftpd is the non standard format of "ls". This will confuse the Hell out of many mirroring script/programs. Apart from that "feature", it seems fine. -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Sun Jun 8 15:32:28 CEST 1997 From owner-freebsd-security Tue Jun 10 07:59:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA09377 for security-outgoing; Tue, 10 Jun 1997 07:59:10 -0700 (PDT) Received: from FreeBSD.cs.nccu.edu.tw (FreeBSD.cs.nccu.edu.tw [140.119.163.156]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA08998 for ; Tue, 10 Jun 1997 07:54:24 -0700 (PDT) Received: (from root@localhost) by FreeBSD.cs.nccu.edu.tw (8.8.5/8.8.5) id WAA02221 for freebsd-security@freebsd.org; Tue, 10 Jun 1997 22:54:54 GMT Date: Tue, 10 Jun 1997 22:54:54 GMT From: Yuang Shuang-Long Message-Id: <199706102254.WAA02221@FreeBSD.cs.nccu.edu.tw> To: freebsd-security@freebsd.org Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! folks: I have a trouble that some users use the following prog. to get root privilege, and the more they do some destructive thing. (eg. delete some file /var/log/* :-( ) I need your help... ********************************************************************** #include #include #include #include #if 0 struct passwd { char *pw_name; /* user's login name */ char *pw_passwd; /* no longer used */ uid_t pw_uid; /* user's uid */ gid_t pw_gid; /* user's gid */ char *pw_age; /* not used */ char *pw_comment; /* not used */ char *pw_gecos; /* typically user's full name */ char *pw_dir; /* user's home dir */ char *pw_shell; /* user's login shell */ }; #endif void main(int argc, char *argv[]) { struct passwd *pw; if(argc < 2) { fprintf(stderr, "too few argument\n"); exit(-1); } if((pw = getpwnam(argv[1])) == NULL) { perror(argv[1]); exit(-1); } printf("uid:%d gid:%d home:%s shell:%s\n", pw->pw_uid, pw->pw_gid, pw->pw_dir, pw->pw_shell); if(setgid(pw->pw_gid) == -1) perror("setgid"); if(setuid(pw->pw_uid) == -1) perror("setuid"); chdir(pw->pw_dir); system(pw->pw_shell); } ************************************************************************* From owner-freebsd-security Tue Jun 10 10:04:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA16926 for security-outgoing; Tue, 10 Jun 1997 10:04:48 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA16914 for ; Tue, 10 Jun 1997 10:04:41 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wbULB-0001Fg-00; Tue, 10 Jun 1997 11:04:17 -0600 To: Guy Helmer Subject: Re: Security problem with FreeBSD 2.2.1 default installation Cc: Michael Haro , freebsd-security@freebsd.org In-reply-to: Your message of "Tue, 03 Jun 1997 10:29:16 CDT." References: Date: Tue, 10 Jun 1997 11:04:17 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Guy Helmer writes: : See the CERT Advisory CA-97.17 (sperl) for this problem at : : ftp://info.cert.org/pub/cert_advisories/CA-97.17.sperl : : dated May 29, 1997. It would not have been known at the time FreeBSD : 2.2.1 (or 2.2.2, for that matter) was released. This bug was fixed in the sources of 2.2 2.1 and -current on May 20, after the 2.2.2 release. Since Perl 4 is way way way unsupported by the Perl community, I just patched the exploit that caused the program I was using to get root. I didn't audit all of Perl 4 to make sure it was cool. Since perl 5 seems to be moving into the source tree, this may become a non-issue. Guy's advise is excellent: Disable sperl unless you have a specific need for it. Warner From owner-freebsd-security Tue Jun 10 10:09:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA17341 for security-outgoing; Tue, 10 Jun 1997 10:09:35 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17325 for ; Tue, 10 Jun 1997 10:09:32 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wbUPM-0001GK-00; Tue, 10 Jun 1997 11:08:36 -0600 To: Matthias Buelow Subject: Re: Security problem with FreeBSD 2.2.1 default installation Cc: ghelmer@cs.iastate.edu (Guy Helmer), freebsd-security@freebsd.org In-reply-to: Your message of "Tue, 03 Jun 1997 18:51:42 +0200." <199706031651.SAA24768@wicx20.informatik.uni-wuerzburg.de> References: <199706031651.SAA24768@wicx20.informatik.uni-wuerzburg.de> Date: Tue, 10 Jun 1997 11:08:35 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message <199706031651.SAA24768@wicx20.informatik.uni-wuerzburg.de> Matthias Buelow writes: : I was already wondering when I freshly installed 2.1.5 half a year ago that : sperl 4.x was still setuid (I remember that Perl's unsafety was already : known at least when I was still running 2.1.0 and I also remember some old : CERT advisories mentioning freebsd ages ago). Since then it has become : routine for me to chmod 0 sperl/setuidperl etc. and I'm really wondering : how there could be people left who don't know of that ancient hole? I mean, : even some of my clueless Linux friends know about the sperl vulnerability. ;) I'm pretty sure it wasn't that ancient hole, but rather a newer one that was a buffer overflow. The ancient hole was different and fixed, if memory serves correctly. Warner From owner-freebsd-security Tue Jun 10 10:07:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA17173 for security-outgoing; Tue, 10 Jun 1997 10:07:51 -0700 (PDT) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA17166 for ; Tue, 10 Jun 1997 10:07:48 -0700 (PDT) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 1.60 #1) id 0wbUOS-0001Fz-00; Tue, 10 Jun 1997 11:07:40 -0600 To: Guy Helmer Subject: Re: Security problem with FreeBSD 2.2.1 default installation Cc: freebsd-security@freebsd.org In-reply-to: Your message of "Tue, 03 Jun 1997 10:44:33 CDT." References: Date: Tue, 10 Jun 1997 11:07:40 -0600 From: Warner Losh Message-Id: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Guy Helmer writes: : I just checked the bugtraq archives and found an exploit for sperl4.036 : and sperl 5.00x on FreeBSD was posted April 21! : : I guess no one watches bugtraq?!? Sigh. Yes. I watch bug track. I also have a full time job. It takes me about a week to get to the bugtraq bugs, and then up to two to four weeks to get them fixed due to other time commitments that I have. If no one else has the time, then the only way that is going to get better will be if I'm paid to watch for these things and paid to spend the time to fix them. I might also point out that the Bugtraq mail had no patches at all for 4.x perl. I had to develop them on my own. Yes, it is important. However, there is only so much that can be done given the resources that we have. Warner From owner-freebsd-security Tue Jun 10 12:22:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA26008 for security-outgoing; Tue, 10 Jun 1997 12:22:22 -0700 (PDT) Received: from cs.iastate.edu (cs.iastate.edu [129.186.3.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA25993 for ; Tue, 10 Jun 1997 12:22:18 -0700 (PDT) Received: from popeye.cs.iastate.edu (popeye.cs.iastate.edu [129.186.3.4]) by cs.iastate.edu (8.8.5/8.7.1) with ESMTP id OAA19497; Tue, 10 Jun 1997 14:22:02 -0500 (CDT) Received: from localhost (ghelmer@localhost) by popeye.cs.iastate.edu (8.8.5/8.7.1) with SMTP id OAA05348; Tue, 10 Jun 1997 14:22:01 -0500 (CDT) X-Authentication-Warning: popeye.cs.iastate.edu: ghelmer owned process doing -bs Date: Tue, 10 Jun 1997 14:21:59 -0500 (CDT) From: Guy Helmer To: Warner Losh cc: freebsd-security@FreeBSD.ORG Subject: Re: Security problem with FreeBSD 2.2.1 default installation In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Tue, 10 Jun 1997, Warner Losh wrote: > In message Guy Helmer writes: > : I just checked the bugtraq archives and found an exploit for sperl4.036 > : and sperl 5.00x on FreeBSD was posted April 21! > : > : I guess no one watches bugtraq?!? > > Sigh. > > Yes. I watch bug track. I also have a full time job. It takes me > about a week to get to the bugtraq bugs, and then up to two to four > weeks to get them fixed due to other time commitments that I have. If > no one else has the time, then the only way that is going to get > better will be if I'm paid to watch for these things and paid to spend > the time to fix them. > > I might also point out that the Bugtraq mail had no patches at all for > 4.x perl. I had to develop them on my own. > > Yes, it is important. However, there is only so much that can be done > given the resources that we have. Sorry, I did not mean to imply that nobody must be working on this. I meant that I had not heard anything in the FreeBSD security list about this exploit, so I was not aware that anyone (in a position to do something about it) was working on it. I realized after re-reading my message that it could offend anyone who was working on the problem, and it was not meant to. After a brief look at the perl 5 patches and the perl 4 source, it was quickly obvious that the perl 4 patch was non-trivially different. I've just started tracking current in the past couple of weeks, so I missed your fix. Thanks for your work, and apologies for the previous message. Guy Helmer, Computer Science Grad Student, Iowa State - ghelmer@cs.iastate.edu http://www.cs.iastate.edu/~ghelmer From owner-freebsd-security Tue Jun 10 12:52:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA27835 for security-outgoing; Tue, 10 Jun 1997 12:52:25 -0700 (PDT) Received: from mexico.brainstorm.eu.org (root@mexico.brainstorm.fr [193.56.58.253]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA27818 for ; Tue, 10 Jun 1997 12:52:18 -0700 (PDT) Received: from brasil.brainstorm.eu.org (brasil.brainstorm.fr [193.56.58.33]) by mexico.brainstorm.eu.org (8.8.4/8.8.4) with ESMTP id VAA08052 for ; Tue, 10 Jun 1997 21:52:10 +0200 Received: (from uucp@localhost) by brasil.brainstorm.eu.org (8.8.4/8.6.12) with UUCP id VAA19849 for freebsd-security@FreeBSD.ORG; Tue, 10 Jun 1997 21:51:47 +0200 Received: (from roberto@localhost) by keltia.freenix.fr (8.8.5/keltia-uucp-2.9) id VAA09694; Tue, 10 Jun 1997 21:40:01 +0200 (CEST) Message-ID: <19970610214001.05348@keltia.freenix.fr> Date: Tue, 10 Jun 1997 21:40:01 +0200 From: Ollivier Robert To: freebsd-security@FreeBSD.ORG Subject: suid exploit (??) References: <199706102254.WAA02221@FreeBSD.cs.nccu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67 In-Reply-To: <199706102254.WAA02221@FreeBSD.cs.nccu.edu.tw>; from Yuang Shuang-Long on Tue, Jun 10, 1997 at 10:54:54PM +0000 X-Operating-System: FreeBSD 3.0-CURRENT ctm#3359 AMD-K6 MMX @ 208 MHz Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Yuang Shuang-Long: > I have a trouble that some users use the following prog. to get > root privilege, and the more they do some destructive thing. (eg. > delete some file /var/log/* :-( ) I need your help... I'm afraid I don't see how they can get root privs with this unless you have made it setuid root. The following lines can't executed only by root to succeed. This is on 3.0-CURRENT. To my knowledge, setuid/setgid has always been restricted to root (unless you want to become yourself). > if(setgid(pw->pw_gid) == -1) > perror("setgid"); > if(setuid(pw->pw_uid) == -1) > perror("setuid"); -- Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Sun Jun 8 15:32:28 CEST 1997 From owner-freebsd-security Tue Jun 10 14:34:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05085 for security-outgoing; Tue, 10 Jun 1997 14:34:47 -0700 (PDT) Received: from news.IAEhv.nl (root@news.IAEhv.nl [194.151.64.4]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id OAA05076 for ; Tue, 10 Jun 1997 14:34:36 -0700 (PDT) Received: from LOCAL (uucp@localhost) by news.IAEhv.nl (8.6.13/1.63) with IAEhv.nl; pid 22002 on Tue, 10 Jun 1997 21:33:35 GMT; id VAA22002 efrom: peter@grendel.IAEhv.nl; eto: UNKNOWN Received: (from peter@localhost) by grendel.IAEhv.nl (8.8.5/8.8.5) id XAA00704; Tue, 10 Jun 1997 23:21:41 +0200 (CEST) Message-ID: <19970610232141.02938@hw.nl> Date: Tue, 10 Jun 1997 23:21:41 +0200 From: Peter Korsten To: Yuang Shuang-Long Cc: freebsd-security@FreeBSD.ORG References: <199706102254.WAA02221@FreeBSD.cs.nccu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.67e In-Reply-To: <199706102254.WAA02221@FreeBSD.cs.nccu.edu.tw>; from Yuang Shuang-Long on Tue, Jun 10, 1997 at 10:54:54PM +0000 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yuang Shuang-Long shared with us: > I have a trouble that some users use the following prog. to get > root privilege, and the more they do some destructive thing. (eg. > delete some file /var/log/* :-( ) I need your help... > > [code fragment deleted] Perhaps I'm confused here, but I don't think this program could do any harm, except when it's run as setuid root. So find / -user 0 -perm -04000 should give you all setuid root programs on the system. But doesn't the daily security run complain about setuid programs that have been added? Perhaps the solution would be to make a backup of your /etc tree, reboot the system in single user mode, type find / -user 0 -perm -04000 | xargs chmod -s reinstall the system and replace the /etc tree after checking for obvious things like uid's of 0 in the password file. Note that above method is very drastic and I suppose that a more-into-secu- rity person has a more elegant solution. In other words, don't try it. - Peter From owner-freebsd-security Tue Jun 10 14:39:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA05287 for security-outgoing; Tue, 10 Jun 1997 14:39:02 -0700 (PDT) Received: from delsol.sunfire.net (root@delsol.sunfire.net [199.224.7.165]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA05258 for ; Tue, 10 Jun 1997 14:38:50 -0700 (PDT) Received: from localhost (afurman@localhost) by delsol.sunfire.net (8.8.5/8.6.12) with SMTP id RAA09533; Tue, 10 Jun 1997 17:38:12 -0400 (EDT) Date: Tue, 10 Jun 1997 17:38:12 -0400 (EDT) From: Adam Furman To: Ollivier Robert cc: freebsd-security@FreeBSD.ORG Subject: Re: suid exploit (??) In-Reply-To: <19970610214001.05348@keltia.freenix.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I also tried to run this script and the same thing was true for me. It had to be setuid root for it to work correctly. Adam Adam Furman Assistant System Administrator of United Computer Specialists afurman@amf.net Irc Admin of irc.ucs.net On Tue, 10 Jun 1997, Ollivier Robert wrote: > According to Yuang Shuang-Long: > > I have a trouble that some users use the following prog. to get > > root privilege, and the more they do some destructive thing. (eg. > > delete some file /var/log/* :-( ) I need your help... > > I'm afraid I don't see how they can get root privs with this unless you > have made it setuid root. > > The following lines can't executed only by root to succeed. This is on > 3.0-CURRENT. To my knowledge, setuid/setgid has always been restricted to > root (unless you want to become yourself). > > > if(setgid(pw->pw_gid) == -1) > > perror("setgid"); > > if(setuid(pw->pw_uid) == -1) > > perror("setuid"); > > -- > Ollivier ROBERT -=- FreeBSD: There are no limits -=- roberto@keltia.freenix.fr > FreeBSD keltia.freenix.fr 3.0-CURRENT #18: Sun Jun 8 15:32:28 CEST 1997 > From owner-freebsd-security Thu Jun 12 09:06:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA04752 for security-outgoing; Thu, 12 Jun 1997 09:06:23 -0700 (PDT) Received: from xkis.kis.ru (dv@xkis.kis.ru [194.87.66.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA04746 for ; Thu, 12 Jun 1997 09:06:18 -0700 (PDT) Received: from localhost (dv@localhost) by xkis.kis.ru (8.8.5/8.8.5) with SMTP id UAA10573 for ; Thu, 12 Jun 1997 20:04:34 +0400 (MSD) Date: Thu, 12 Jun 1997 20:04:34 +0400 (MSD) From: Dmitry Valdov To: freebsd-security@freebsd.org Subject: DNS abuse (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi! named in 2.1.5 is vulnerable... Is 2.2.x's named vulnerable too? Dmitry. ---------- Forwarded message ---------- Date: Thu, 12 Jun 1997 08:02:22 +0200 From: Jordi Murgo To: BUGTRAQ@NETSPACE.ORG Subject: DNS abuse Test this URL to see if your DNS is abusable. http://apostols.org/toolz/dnshack.cgi ======================================= From owner-freebsd-security Thu Jun 12 10:06:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA07902 for security-outgoing; Thu, 12 Jun 1997 10:06:23 -0700 (PDT) Received: from xkis.kis.ru (dv@xkis.kis.ru [194.87.66.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA07885 for ; Thu, 12 Jun 1997 10:06:07 -0700 (PDT) Received: from localhost (dv@localhost) by xkis.kis.ru (8.8.5/8.8.5) with SMTP id VAA11414 for ; Thu, 12 Jun 1997 21:05:37 +0400 (MSD) Date: Thu, 12 Jun 1997 21:05:37 +0400 (MSD) From: Dmitry Valdov To: freebsd-security@FreeBSD.ORG Subject: Re: DNS abuse (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Jun 1997, Dmitry Valdov wrote: > Date: Thu, 12 Jun 1997 20:04:34 +0400 (MSD) > From: Dmitry Valdov > To: freebsd-security@FreeBSD.ORG > Subject: DNS abuse (fwd) > > Hi! > > named in 2.1.5 is vulnerable... > Is 2.2.x's named vulnerable too? > I've just compiled 2.2.2's named (-static) and replaced it on my nameserver...(fbsd 2.1.5). It still vulnerable. So.. Is there any way to fix it? > > ---------- Forwarded message ---------- > Date: Thu, 12 Jun 1997 08:02:22 +0200 > From: Jordi Murgo > To: BUGTRAQ@NETSPACE.ORG > Subject: DNS abuse > > Test this URL to see if your DNS is abusable. > > http://apostols.org/toolz/dnshack.cgi > > ======================================= > > From owner-freebsd-security Thu Jun 12 11:14:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA11621 for security-outgoing; Thu, 12 Jun 1997 11:14:09 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA11600 for ; Thu, 12 Jun 1997 11:14:00 -0700 (PDT) Received: from Jupiter.Mcs.Net (karl@Jupiter.mcs.net [192.160.127.88]) by Kitten.mcs.com (8.8.5/8.8.2) with ESMTP id NAA22425; Thu, 12 Jun 1997 13:13:54 -0500 (CDT) Received: (from karl@localhost) by Jupiter.Mcs.Net (8.8.5/8.8.2) id NAA04691; Thu, 12 Jun 1997 13:13:53 -0500 (CDT) Message-ID: <19970612131353.63083@Jupiter.Mcs.Net> Date: Thu, 12 Jun 1997 13:13:53 -0500 From: Karl Denninger To: Dmitry Valdov Cc: freebsd-security@FreeBSD.ORG Subject: Re: DNS abuse (fwd) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.64 In-Reply-To: ; from Dmitry Valdov on Thu, Jun 12, 1997 at 09:05:37PM +0400 Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Jun 12, 1997 at 09:05:37PM +0400, Dmitry Valdov wrote: > > > On Thu, 12 Jun 1997, Dmitry Valdov wrote: > > > Date: Thu, 12 Jun 1997 20:04:34 +0400 (MSD) > > From: Dmitry Valdov > > To: freebsd-security@FreeBSD.ORG > > Subject: DNS abuse (fwd) > > > > Hi! > > > > named in 2.1.5 is vulnerable... > > Is 2.2.x's named vulnerable too? > > > > I've just compiled 2.2.2's named (-static) and replaced it on my > nameserver...(fbsd 2.1.5). It still vulnerable. > So.. Is there any way to fix it? > > > > > ---------- Forwarded message ---------- > > Date: Thu, 12 Jun 1997 08:02:22 +0200 > > From: Jordi Murgo > > To: BUGTRAQ@NETSPACE.ORG > > Subject: DNS abuse > > > > Test this URL to see if your DNS is abusable. > > > > http://apostols.org/toolz/dnshack.cgi > > > > ======================================= Build BIND 8.1? :-) (ftp.isc.org) -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | 99 Analog numbers, 77 ISDN, http://www.mcs.net/ Voice: [+1 312 803-MCS1 x219]| NOW Serving 56kbps DIGITAL on our analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal From owner-freebsd-security Thu Jun 12 11:30:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12593 for security-outgoing; Thu, 12 Jun 1997 11:30:10 -0700 (PDT) Received: from denver.net (milehigh.denver.net [204.144.180.2]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA12588 for ; Thu, 12 Jun 1997 11:30:08 -0700 (PDT) Received: from localhost (jdc@localhost) by denver.net (8.8.5/8.8.5) with SMTP id MAA19219; Thu, 12 Jun 1997 12:29:35 -0600 (MDT) Date: Thu, 12 Jun 1997 12:29:34 -0600 (MDT) From: John-David Childs To: Dmitry Valdov cc: freebsd-security@FreeBSD.ORG Subject: Re: DNS abuse (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Jun 1997, Dmitry Valdov wrote: > > > I've just compiled 2.2.2's named (-static) and replaced it on my > nameserver...(fbsd 2.1.5). It still vulnerable. > So.. Is there any way to fix it? > I haven't looked yet (just installed a 2.2.2. box myself this morning), but I'd bet it still uses BIND 4.9.X The bugs you are questioning with respect to the posted web page are fixed I believe in BIND 8.1 (ftp://ftp.isc.org/isc/bind/) -- John-David Childs (JC612) http://www.denver.net System Administrator jdc@denver.net & Network Engineer Think, Listen, Look, THEN Act! "A verbal contract isn't worth the paper it's written on" - Louis B Mayer > > > > ---------- Forwarded message ---------- > > Date: Thu, 12 Jun 1997 08:02:22 +0200 > > From: Jordi Murgo > > To: BUGTRAQ@NETSPACE.ORG > > Subject: DNS abuse > > > > Test this URL to see if your DNS is abusable. > > > > http://apostols.org/toolz/dnshack.cgi > > > > ======================================= > > > > > > From owner-freebsd-security Thu Jun 12 11:30:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA12621 for security-outgoing; Thu, 12 Jun 1997 11:30:22 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA12549; Thu, 12 Jun 1997 11:29:51 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.5/8.8.5) id WAA00867; Thu, 12 Jun 1997 22:29:25 +0400 (MSD) Date: Thu, 12 Jun 1997 22:29:24 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Dmitry Valdov cc: freebsd-security@freebsd.org, peter@freebsd.org Subject: Re: DNS abuse (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Jun 1997, Dmitry Valdov wrote: > named in 2.1.5 is vulnerable... > Is 2.2.x's named vulnerable too? Even -current named 4.9.5-P1 is vulnerable. > > Test this URL to see if your DNS is abusable. > > http://apostols.org/toolz/dnshack.cgi -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Thu Jun 12 15:29:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA24687 for security-outgoing; Thu, 12 Jun 1997 15:29:31 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24672; Thu, 12 Jun 1997 15:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lsd.relcom.eu.net (8.8.5/8.8.5) with ESMTP id CAA24291; Fri, 13 Jun 1997 02:28:59 +0400 (MSD) X-Received: from dux.ru (ns.dux.ru [193.125.210.65]) by lsd.relcom.eu.net (8.8.5/8.8.5) with ESMTP id CAA22702 for ; Fri, 13 Jun 1997 02:11:14 +0400 (MSD) X-Received: (from fil@localhost) by dux.ru (8.8.5/8.7.6/DUX) id CAA29505; Fri, 13 Jun 1997 02:11:06 +0400 (MSD) From: Valery Filippov Message-Id: <199706122211.CAA29505@dux.ru> Subject: Re: Our DNS severs are vulnerable (fwd) To: ache@lsd.relcom.eu.net Date: Fri, 13 Jun 1997 02:11:06 +0400 (MSD) Cc: noc@relcom.eu.net X-Mailer: ELM [version 2.4 PL24 ME8a] MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit ReSent-Date: Fri, 13 Jun 1997 02:28:33 +0400 (MSD) ReSent-From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= ReSent-To: security@freebsd.org, peter@freebsd.org ReSent-Message-ID: Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Это описано. Валера Филиппов рассылал полное и подробное описание (примерно > то, что ты говоришь) и там был приведен патч, но я не помню при установке > 4.9.5 поставили мы этот патч или нет. Проверю. Бросьте в меня тоже патчем, please... -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ ---------- Forwarded message ---------- Date: Tue, 22 Apr 1997 04:36:17 -0600 From: Oliver Friedrichs To: BUGTRAQ@NETSPACE.ORG Subject: SNI-12: BIND Vulnerabilities and Solutions -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. AND CORE Seguridad de la Informacion Security Advisory April 22, 1997 BIND Vulnerabilities and Solutions Problem Description ~~~~~~~~~~~~~~~~~~~ This advisory contains descriptions and solutions for two vulnerabilities present in current BIND distributions. These vulnerabilities are actively being exploited on the Internet. I. The usage of predictable IDs in queries and recursed queries allows for remote cache corruption. This allows malicious users to alter domain name server caches to change the addresses and hostnames of hosts on the internet. II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in size. This results in potential buffer overflows in programs which expect the BIND resolver to only return a maximum hostname length of MAXHOSTNAMELEN. Problem I. The usage of predictable ID's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem I. - Impact ~~~~~~~~~~~~~~~~~~~ Remote root users can poison BIND and Microsoft Windows NT name server caches by forging UDP packets. We should note that unlike other well documented attacks, in this instance it is NOT necessary for the attacker to take over a DNS server or sniff the target network. Problem I. - Technical Details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This particular cache corruption attack requires that the target nameserver be configured to allow recursion. Recursion allows a nameserver to handle requests for zones or domains which it does not serve. When receiving a query for a zone or domain which is not served by the name server, the name server will transmit a query to a nameserver which serves the desired domain. Once a response is received from the second nameserver, the first nameserver sends the response back to the requesting party. The following attack is outlined in the paper "Addressing weaknesses in the Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. To the extent of our knowledge, this problem has not been previously addressed. The paper also assumes that the attacker has super-user access to a primary nameserver, here we demonstrate that this is not necessary nor are source routed packets required. Using the recursion feature, one can poison the cache on a name server with the following procedure: Problem I. - The Players ~~~~~~~~~~~~~~~~~~~~~~~~ . HOST.ATTACKER.COM is the attacking host. . DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is the only name server for ATTACKER.COM to simplify the description. . DNS.TARGET.COM is the target nameserver which runs BIND. What we will attempt to do is add an A (address) resource record on DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. . DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have determined this before the attack begins. Once again we just presume its the only one in order to simplify this description. Problem I. - The Attack ~~~~~~~~~~~~~~~~~~~~~~~ A. First a query is sent to DNS.TARGET.COM asking for the address of UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, meaning that if the nameserver we are querying has recursion enabled, it will query another nameserver with our query (assuming it does not have the information cached). B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM domain, then it will build a query packet and send it to DNS.ATTACKER.COM. C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine the query ID (qid0) used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 10 for most cases. D. Once we have determined what the next query ID generated will be, we send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. F. If we guessed the query ID used by DNS.TARGET.COM in its recursed query and our response is received first, our response will be taken as valid and the address will be cached. Subsequent responses will be discarded as duplicates. We can always send many (N*M) spoofed packets with different IDs in the range (qid0,qid0+N] so we will be sure that at least one of them will hit DNS.TARGET.COM and have the 'right' ID. M is a factor dependent of the amount of UDP packets we expect to lose on their way to DNS.TARGET.COM. Problem I. - The Result ~~~~~~~~~~~~~~~~~~~~~~~ If the attack succeeded, any query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to contact WWW.SPOOFED.COM. The usage of 127.0.0.1 in this description is of course for instructional purposes, any IP address can be used, in particular an attacker could use its own IP address (BADGUY.COM's IP) so all connections to 'host' will go to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is easy to visualize the effects of impersonating a high traffic FTP distribution site. This attack can also be used to intercept email traffic, and bypass address based authentication methods, including TCP wrappers and firewalls. Problem I. - Notes ~~~~~~~~~~~~~~~~~~ This attack depends on a few things to succeed: 1. The attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. 2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must be received before the legit response from DNS.SPOOFED.COM. This is very easy to achieve. In testing we have not yet encountered a situation where we could not get our packets to the nameserver first. 3. The name server on DNS.TARGET.COM supports recursion and caches responses. This is common practice. It should be noted that most nameservers allow recursion (unless specifically denied by configuration options). Root name servers, however, do not allow recursion. If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial of service attack can be performed, in this case, spoofed responses sent by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not exist (and be authorative on this). The existence of several nameservers for the domains does not alter the basic outline of this attack. The attacker would only need to send DNS responses with source addresses of each of SPOOFED.COM's nameservers. (N*M*I responses, where I is the number of nameservers). Problem I. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - All systems using BIND as their domain name server with recursion enabled. - - Windows NT (server) version 3.51 & 4.0 DNS server. Microsoft has been notified and has acknowledged this is a serious problem. No information on a fix is availible. Problem II. Hostname length checking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem II. - Impact ~~~~~~~~~~~~~~~~~~~~ BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to programs. As many programs utilize buffers of size MAXHOSTNAMELEN and copy the results from a query into these buffers, an overflow can occur. This can allow an attacker to execute arbitrary commands on a remote server in a worst case scenario. Problem II. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All systems running BIND. Fix Information ~~~~~~~~~~~~~~~ Obtain BIND version 4.9.5-P1. BIND is availible from ftp.isc.org in the directory /isc/bind/src. Patches to solve both problem I and problem II are included at the end of this advisory. Once BIND has been obtained, follow the following procedure: i. First remove the patches from this text. This can be performed by removing all text in between the "CUT HERE" lines, and saving it to a text file (i.e. /tmp/diffs.txt). ii. Perform the following operations to apply the patches: % gzip -d bind.tar.gz % mkdir bind % cd bind % tar -xvf ../bind.tar % patch < /tmp/diffs.txt iii. Rebuild BIND Attributions ~~~~~~~~~~~~ Ivan Arce Emiliano Kargieman The OpenBSD Project Who found a good solution to problem, developed a solution and performed various tests to ensure its correctness. Individuals involved in this effort were: Theo de Raadt Niels Provos Todd Miller Allen Briggs Further attributions: AUSCERT David Sacerdote Oliver Friedrichs Alfred Huger Additional Information: ~~~~~~~~~~~~~~~~~~~~~~~ [1] Vixie P. , "DNS and BIND security issues". This was originally published in the proceedings of the 5th USENIX Security Symposium and its included in the BIND distribution under the doc/misc directory. [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes" Refer to problem 2 for a description of other weaknesses previously found in the recursion scheme. [3] Lottor, M., "RFC1033: Domain administrators operations guide" [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and specification" [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the Domain Name System Protocol", COAST Laboratory, Department of Computer Science, Purdue University. Comments and questions regarding this advisory can be sent to: Ivan Arce Emiliano Kargieman For more information about CORE S.A. contact: core@secnet.com Or visit: http://www.secnet.com/core Encrypted mail can also be sent to encrypted with the following PGP key: Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. Secure Networks - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and CORE Seguridad de la Informacion S.A., and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories" Patches ~~~~~~~ --- CUT HERE --- diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c *** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 - --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 *************** *** 537,543 **** _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = getpid() & 0x7fff; /* save new defaults */ new_res = _res; - --- 537,543 ---- _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = res_randomid(); /* save new defaults */ new_res = _res; diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c *** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 - --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 *************** *** 1658,1668 **** } /* ! * These are here in case we ever want to get more clever, like perhaps ! * using a bitmap to keep track of outstanding queries and a random ! * allocation scheme to make it a little harder to predict them. Note ! * that the resolver will need the same protection so the cleverness ! * should be put there rather than here; this is just an interface layer. */ void - --- 1658,1668 ---- } /* ! * This just an interface layer to the random number generator ! * used in the resolver. ! * A special random number generator is used to create non predictable ! * and non repeating ids over a long period. It also avoids reuse ! * by switching between two distinct number cycles. */ void *************** *** 1674,1683 **** u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } - --- 1674,1680 ---- u_int16_t nsid_next() { ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ ! res_random.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ ! res_random.o all: libresolv.a diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c *** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 - --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 *************** *** 98,103 **** - --- 98,105 ---- dn = exp_dn; cp = comp_dn; + if (length > MAXHOSTNAMELEN-1) + length = MAXHOSTNAMELEN-1; eom = exp_dn + length; /* * fetch next label in domain name diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c *** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 - --- ./res/res_init.c Wed Apr 9 00:33:30 1997 *************** *** 197,209 **** if (!(_res.options & RES_INIT)) _res.options = RES_DEFAULT; - - /* - - * This one used to initialize implicitly to zero, so unless the app - - * has set it to something in particular, we can randomize it now. - - */ - - if (!_res.id) - - _res.id = res_randomid(); - - #ifdef USELOOPBACK _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); #else - --- 197,202 ---- *************** *** 644,655 **** return(0); /* if not using DNS configuration from NetInfo */ } #endif /* NeXT */ - - - - u_int - - res_randomid() - - { - - struct timeval now; - - - - gettimeofday(&now, NULL); - - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); - - } - --- 637,639 ---- diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c *** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 - --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 *************** *** 107,118 **** #endif /* * Initialize header fields. */ if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(++_res.id); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; - --- 107,123 ---- #endif /* * Initialize header fields. + * + * A special random number generator is used to create non predictable + * and non repeating ids over a long period. It also avoids reuse + * by switching between two distinct number cycles. */ + if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(_res.id=res_randomid()); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c *** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 - --- ./res/res_random.c Tue Apr 22 02:31:25 1997 *************** *** 0 **** - --- 1,262 ---- + /* $OpenBSD: res_random.c,v 1.3 1997/04/19 10:07:01 provos Exp $ */ + + /* + * Copyright 1997 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + /* + * seed = random 15bit + * n = prime, g0 = generator to n, + * j = random so that gcd(j,n-1) == 1 + * g = g0^j mod n will be a generator again. + * + * X[0] = random seed. + * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator + * with a = 7^(even random) mod m, + * b = random with gcd(b,m) == 1 + * m = 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] = seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + * + * The 16 bit space is very small and brute force attempts are + * entirly feasible, we skip a random number of transaction ids + * so that an attacker will not get sequential ids. + */ + + #include + #include + #include + #include + + #if defined(BSD) && (BSD >= 199103) + # include + # include + # include + #else + # include "../conf/portability.h" + #endif + + #define RU_OUT 180 /* Time after wich will be reseeded */ + #define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ + #define RU_GEN 2 /* Starting generator */ + #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ + #define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ + #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ + + #define PFAC_N 3 + const static u_int16_t pfacts[PFAC_N] = { + 2, + 3, + 2729 + }; + + static u_int16_t ru_x; + static u_int16_t ru_seed; + static u_int16_t ru_a, ru_b; + static u_int16_t ru_g; + static u_int16_t ru_counter = 0; + static u_int16_t ru_msb = 0; + static long ru_reseed; + static u_int32_t tmp; /* Storage for unused random */ + static struct timeval tv; + + static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); + static void res_initid __P((void)); + + #ifndef __OpenBSD__ + /* + * No solid source of strong random in the system. Sigh. Fake it. + */ + u_long + arc4random() + { + static char state[256]; + char *savestate; + char *setstate(); + static unsigned seed; + static int count; + u_long datum; + + if (++count == 129837 || seed == 0) { + struct timeval tv; + + count = 0; + gettimeofday(&tv, NULL); + seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; + initstate(seed, state, sizeof state); + } + savestate = setstate(state); + datum = random(); + setstate(savestate); + return (datum); + } + + #endif + + /* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + + static u_int32_t + pmod(gen, exp, mod) + u_int32_t gen, exp, mod; + { + u_int32_t s, t, u; + + s = 1; + t = gen; + u = exp; + + while (u) { + if (u & 1) + s = (s*t) % mod; + u >>= 1; + t = (t*t) % mod; + } + return (s); + } + + /* + * Initalizes the seed and chooses a suitable generator. Also toggles + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from res_randomid() when needed, an + * application does not have to worry about it. + */ + static void + res_initid() + { + u_int16_t j, i; + int noprime = 1; + + tmp = arc4random(); + ru_x = (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed = (tmp >> 16) & 0x7FFF; + + tmp = arc4random(); + + /* Determine the LCG we use */ + ru_b = (tmp & 0xfffe) | 1; + ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 == 0) + ru_b += 2; + + tmp = arc4random(); + j = tmp % RU_N; + tmp = tmp >> 16; + + /* + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) == 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=0; i=PFAC_N) + noprime = 0; + else + j = (j+1) % RU_N; + } + + ru_g = pmod(RU_GEN,j,RU_N); + ru_counter = 0; + + gettimeofday(&tv, NULL); + ru_reseed = tv.tv_sec + RU_OUT; + ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; + } + + u_int + res_randomid() + { + int i, n; + + gettimeofday(&tv, NULL); + if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) + res_initid(); + + if (!tmp) + tmp = arc4random(); + + /* Skip a random number of ids */ + n = tmp & 0x2f; tmp = tmp >> 6; + if (ru_counter + n >= RU_MAX) + res_initid(); + + for (i=0; i<=n; i++) + /* Linear Congruential Generator */ + ru_x = (ru_a*ru_x + ru_b) % RU_M; + + ru_counter += i; + + return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; + } + + #if 0 + void + main(int argc, char **argv) + { + int i, n; + u_int16_t wert; + + res_initid(); + + printf("Generator: %d\n", ru_g); + printf("Seed: %d\n", ru_seed); + printf("Reseed at %ld\n", ru_reseed); + printf("Ru_X: %d\n", ru_x); + printf("Ru_A: %d\n", ru_a); + printf("Ru_B: %d\n", ru_b); + + n = atoi(argv[1]); + for (i=0;i Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA27526 for security-outgoing; Thu, 12 Jun 1997 16:35:20 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA27485; Thu, 12 Jun 1997 16:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lsd.relcom.eu.net (8.8.5/8.8.5) with SMTP id DAA07113; Fri, 13 Jun 1997 03:34:48 +0400 (MSD) Date: Fri, 13 Jun 1997 03:34:47 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= X-Sender: ache@lsd.relcom.eu.net cc: security@FreeBSD.ORG, peter@FreeBSD.ORG Subject: Re: Our DNS severs are vulnerable (fwd) In-Reply-To: <199706122211.CAA29505@dux.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > + > + #ifndef __OpenBSD__ > + /* > + * No solid source of strong random in the system. Sigh. Fake it. > + */ > + u_long > + arc4random() > + { We can use srandomdev() here. I plan to apply this patches in near days if nobody objects. -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Fri Jun 13 04:53:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA25955 for security-outgoing; Fri, 13 Jun 1997 04:53:56 -0700 (PDT) Received: from alpha.kada.lt (alpha.kada.lt [193.219.13.141]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA25913 for ; Fri, 13 Jun 1997 04:53:25 -0700 (PDT) Received: from dara by alpha.kada.lt (5.65v3.2/1.1.10.5/21Jun96-0218PM) id AA30873; Fri, 13 Jun 1997 14:49:27 +0300 Message-Id: <33A134F8.9A1D89BA@alpha.kada.lt> Date: Fri, 13 Jun 1997 14:54:32 +0300 From: Darius Ramanauskas X-Mailer: Mozilla 4.0 [en] (WinNT; I) Mime-Version: 1.0 To: security@freebsd.org Subject: [Fwd: Our DNS severs are vulnerable (fwd)] X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------C2B948D8E699DBA22F17D082" Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------C2B948D8E699DBA22F17D082 Content-Type: text/plain; charset=x-user-defined Content-Type: text/plain; charset=x-user-defined Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Some patches from SNI --------------C2B948D8E699DBA22F17D082 Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Content-Disposition: inline Received: from ra.dkuug.dk by alpha.kada.lt (5.65v3.2/1.1.10.5/21Jun96-0218PM) id AA30450; Fri, 13 Jun 1997 02:13:44 +0300 Received: from hub.freebsd.org (hub.FreeBSD.ORG [204.216.27.18]) by ra.dkuug.dk (8.6.12/8.6.12) with ESMTP id BAA20521; Fri, 13 Jun 1997 01:13:33 +0200 Received: from localhost (daemon@localhost) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA25440; Thu, 12 Jun 1997 15:41:18 -0700 (PDT) Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA24687 for security-outgoing; Thu, 12 Jun 1997 15:29:31 -0700 (PDT) Received: from lsd.relcom.eu.net (lsd.relcom.eu.net [193.124.23.23]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA24672; Thu, 12 Jun 1997 15:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lsd.relcom.eu.net (8.8.5/8.8.5) with ESMTP id CAA24291; Fri, 13 Jun 1997 02:28:59 +0400 (MSD) X-Received: from dux.ru (ns.dux.ru [193.125.210.65]) by lsd.relcom.eu.net (8.8.5/8.8.5) with ESMTP id CAA22702 for ; Fri, 13 Jun 1997 02:11:14 +0400 (MSD) X-Received: (from fil@localhost) by dux.ru (8.8.5/8.7.6/DUX) id CAA29505; Fri, 13 Jun 1997 02:11:06 +0400 (MSD) From: Valery Filippov Message-Id: <199706122211.CAA29505@dux.ru> Subject: Re: Our DNS severs are vulnerable (fwd) To: ache@lsd.relcom.eu.net Date: Fri, 13 Jun 1997 02:11:06 +0400 (MSD) Cc: noc@relcom.eu.net X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Resent-Date: Fri, 13 Jun 1997 02:28:33 +0400 (MSD) Resent-From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= Resent-To: security@FreeBSD.ORG, peter@FreeBSD.ORG Resent-Message-Id: Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Это описано. Валера Филиппов рассылал полное и подробное описание (примерно > то, что ты говоришь) и там был приведен патч, но я не помню при установке > 4.9.5 поставили мы этот патч или нет. Проверю. Бросьте в меня тоже патчем, please... -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ ---------- Forwarded message ---------- Date: Tue, 22 Apr 1997 04:36:17 -0600 From: Oliver Friedrichs To: BUGTRAQ@NETSPACE.ORG Subject: SNI-12: BIND Vulnerabilities and Solutions -----BEGIN PGP SIGNED MESSAGE----- ###### ## ## ###### ## ### ## ## ###### ## # ## ## ## ## ### ## ###### . ## ## . ######. Secure Networks Inc. AND CORE Seguridad de la Informacion Security Advisory April 22, 1997 BIND Vulnerabilities and Solutions Problem Description ~~~~~~~~~~~~~~~~~~~ This advisory contains descriptions and solutions for two vulnerabilities present in current BIND distributions. These vulnerabilities are actively being exploited on the Internet. I. The usage of predictable IDs in queries and recursed queries allows for remote cache corruption. This allows malicious users to alter domain name server caches to change the addresses and hostnames of hosts on the internet. II. A failure to check whether hostname lengths exceed MAXHOSTNAMELEN in size. This results in potential buffer overflows in programs which expect the BIND resolver to only return a maximum hostname length of MAXHOSTNAMELEN. Problem I. The usage of predictable ID's ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem I. - Impact ~~~~~~~~~~~~~~~~~~~ Remote root users can poison BIND and Microsoft Windows NT name server caches by forging UDP packets. We should note that unlike other well documented attacks, in this instance it is NOT necessary for the attacker to take over a DNS server or sniff the target network. Problem I. - Technical Details ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This particular cache corruption attack requires that the target nameserver be configured to allow recursion. Recursion allows a nameserver to handle requests for zones or domains which it does not serve. When receiving a query for a zone or domain which is not served by the name server, the name server will transmit a query to a nameserver which serves the desired domain. Once a response is received from the second nameserver, the first nameserver sends the response back to the requesting party. The following attack is outlined in the paper "Addressing weaknesses in the Domain Name System Protocol" by Christopher Schuba and Eugene Spafford [6]. To the extent of our knowledge, this problem has not been previously addressed. The paper also assumes that the attacker has super-user access to a primary nameserver, here we demonstrate that this is not necessary nor are source routed packets required. Using the recursion feature, one can poison the cache on a name server with the following procedure: Problem I. - The Players ~~~~~~~~~~~~~~~~~~~~~~~~ . HOST.ATTACKER.COM is the attacking host. . DNS.ATTACKER.COM is ATTACKER.COM's nameserver, we presume that this is the only name server for ATTACKER.COM to simplify the description. . DNS.TARGET.COM is the target nameserver which runs BIND. What we will attempt to do is add an A (address) resource record on DNS.TARGET.COM that will resolve WWW.SPOOFED.COM to 127.0.0.1. We are sure that WWW.SPOOFED.COM is not cached in DNS.TARGET.COM's DNS cache. . DNS.SPOOFED.COM is the nameserver for SPOOFED.COM's domain. We have determined this before the attack begins. Once again we just presume its the only one in order to simplify this description. Problem I. - The Attack ~~~~~~~~~~~~~~~~~~~~~~~ A. First a query is sent to DNS.TARGET.COM asking for the address of UNKNOWN.ATTACKER.COM. Our query has the recursion desired bit set, meaning that if the nameserver we are querying has recursion enabled, it will query another nameserver with our query (assuming it does not have the information cached). B. DNS.TARGET.COM will first determine who serves the ATTACKER.COM domain, then it will build a query packet and send it to DNS.ATTACKER.COM. C. We sniff DNS.ATTACKER.COM's local network and retrieve the query packet sent by DNS.TARGET.COM to DNS.ATTACKER.COM. We can then determine the query ID (qid0) used by DNS.TARGET.COM. Chances are that the next queries generated by DNS.TARGET.COM will have query IDs that will fall in the range [qid0,qid0+N] where N is dependent on the amount of queries DNS.TARGET.COM is generating in the period of time on which the attack takes place. N is usually <= 10 for most cases. D. Once we have determined what the next query ID generated will be, we send a query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address. E. Then we start sending spoofed DNS replies from DNS.SPOOFED.COM, telling DNS.TARGET.COM that WWW.SPOOFED.COM is '127.0.0.1'. F. If we guessed the query ID used by DNS.TARGET.COM in its recursed query and our response is received first, our response will be taken as valid and the address will be cached. Subsequent responses will be discarded as duplicates. We can always send many (N*M) spoofed packets with different IDs in the range (qid0,qid0+N] so we will be sure that at least one of them will hit DNS.TARGET.COM and have the 'right' ID. M is a factor dependent of the amount of UDP packets we expect to lose on their way to DNS.TARGET.COM. Problem I. - The Result ~~~~~~~~~~~~~~~~~~~~~~~ If the attack succeeded, any query to DNS.TARGET.COM asking for WWW.SPOOFED.COM's address, will get 127.0.0.1 as a response. Thus, any user on TARGET.COM's domain will connect to 127.0.0.1 if they try to contact WWW.SPOOFED.COM. The usage of 127.0.0.1 in this description is of course for instructional purposes, any IP address can be used, in particular an attacker could use its own IP address (BADGUY.COM's IP) so all connections to 'host' will go to 'BADGUY'. The attacker can then 'impersonate' WWW.SPOOFED.COM. Given this attack, it is easy to visualize the effects of impersonating a high traffic FTP distribution site. This attack can also be used to intercept email traffic, and bypass address based authentication methods, including TCP wrappers and firewalls. Problem I. - Notes ~~~~~~~~~~~~~~~~~~ This attack depends on a few things to succeed: 1. The attacker has complete control of DNS.ATTACKER.COM's network, he can both spoof and sniff DNS packets there. In particular, he can sniff DNS packets sent to DNS.ATTACKER.COM. 2. Spoofed DNS responses sent from the attacker to DNS.TARGET.COM must be received before the legit response from DNS.SPOOFED.COM. This is very easy to achieve. In testing we have not yet encountered a situation where we could not get our packets to the nameserver first. 3. The name server on DNS.TARGET.COM supports recursion and caches responses. This is common practice. It should be noted that most nameservers allow recursion (unless specifically denied by configuration options). Root name servers, however, do not allow recursion. If DNS.TARGET.COM caches negative responses as well (NCACHE), a denial of service attack can be performed, in this case, spoofed responses sent by the attacker will tell DNS.TARGET.COM that WWW.SPOOFED.COM does not exist (and be authorative on this). The existence of several nameservers for the domains does not alter the basic outline of this attack. The attacker would only need to send DNS responses with source addresses of each of SPOOFED.COM's nameservers. (N*M*I responses, where I is the number of nameservers). Problem I. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - - All systems using BIND as their domain name server with recursion enabled. - - Windows NT (server) version 3.51 & 4.0 DNS server. Microsoft has been notified and has acknowledged this is a serious problem. No information on a fix is availible. Problem II. Hostname length checking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Problem II. - Impact ~~~~~~~~~~~~~~~~~~~~ BIND allows passing of hostnames larger than MAXHOSTNAMELEN in size to programs. As many programs utilize buffers of size MAXHOSTNAMELEN and copy the results from a query into these buffers, an overflow can occur. This can allow an attacker to execute arbitrary commands on a remote server in a worst case scenario. Problem II. - Systems Affected ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ All systems running BIND. Fix Information ~~~~~~~~~~~~~~~ Obtain BIND version 4.9.5-P1. BIND is availible from ftp.isc.org in the directory /isc/bind/src. Patches to solve both problem I and problem II are included at the end of this advisory. Once BIND has been obtained, follow the following procedure: i. First remove the patches from this text. This can be performed by removing all text in between the "CUT HERE" lines, and saving it to a text file (i.e. /tmp/diffs.txt). ii. Perform the following operations to apply the patches: % gzip -d bind.tar.gz % mkdir bind % cd bind % tar -xvf ../bind.tar % patch < /tmp/diffs.txt iii. Rebuild BIND Attributions ~~~~~~~~~~~~ Ivan Arce Emiliano Kargieman The OpenBSD Project Who found a good solution to problem, developed a solution and performed various tests to ensure its correctness. Individuals involved in this effort were: Theo de Raadt Niels Provos Todd Miller Allen Briggs Further attributions: AUSCERT David Sacerdote Oliver Friedrichs Alfred Huger Additional Information: ~~~~~~~~~~~~~~~~~~~~~~~ [1] Vixie P. , "DNS and BIND security issues". This was originally published in the proceedings of the 5th USENIX Security Symposium and its included in the BIND distribution under the doc/misc directory. [2] Kumar A., Postel J., Neuman C., Danzig P. , Miller S. "RFC1536: Common DNS implementation errors and suggested fixes" Refer to problem 2 for a description of other weaknesses previously found in the recursion scheme. [3] Lottor, M., "RFC1033: Domain administrators operations guide" [4] Mockapetris, P., "RFC1034: Domain names - Concepts and facilities" [5] Mockapetris, P., "RFC1035: Domain Names - Implementation and specification" [6] Schuba Christopher and Spafford Eugene, "Adressing weaknesses in the Domain Name System Protocol", COAST Laboratory, Department of Computer Science, Purdue University. Comments and questions regarding this advisory can be sent to: Ivan Arce Emiliano Kargieman For more information about CORE S.A. contact: core@secnet.com Or visit: http://www.secnet.com/core Encrypted mail can also be sent to encrypted with the following PGP key: Type Bits/KeyID Date User ID pub 1024/9E55000D 1997/01/13 Secure Networks Inc. Secure Networks - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3ia mQCNAzLaFzIAAAEEAKsVzPR7Y6oFN5VPE/Rp6Sm82oE0y6Mkuof8QzERV6taihn5 uySb31UeNJ4l6Ud9alOPT/0YdeOO9on6eD1iU8qumFxzO3TLm8nTAdZehQSAQfoa rWmpwj7KpXN/3n+VyBWvhpBdKxe08SQN4ZjvV5HXy4YIrE5bTbgIhFKeVQANAAUR tCVTZWN1cmUgTmV0d29ya3MgSW5jLiA8c25pQHNlY25ldC5jb20+iQCVAwUQM1yd EB/bLKAOe7p9AQFptAQAiYpaZCpSmGgr05E698Z3t5r5BPAKUEtgvF53AvZUQLxz ZsYsVU5l5De0qKWJOQ/9LiDyWu1lvKhlTphbLy2RatWD4kO3oQL9v3TpSXm2WQhU uIzyZvj7S5ENodNnKn+gCDIvbou6OMot+7dRbWWgN2oabbru4CSlOxbG++yaTz+J AJUDBRAzTefbtOXez5VgyLkBAd0bA/43eGEgvPOFK+HHWCPpkSWCwtrtDU/dxOVz 9erHnT/CRxeojCI+50f71Qe+kvx9Q1odz2Jl/fLxhnPQdbPnpWblIbu4F8H+Syrj HTilDrl1DWa/nUNgK8sb27SMviELczP1a8gwA1eo5SUCG5TWLLTAzjWOgTxod2Ha OwseUHmqVIkAlQMFEDNOVsr/d6Iw8NVIbQEBxM0D/14XRfgSLwszgJcVbslMHm/B fF6tHoWYojzQle3opOuMYHNN8GsMZRkc1qQ8QuNA9Aj5+qDqEontGjV5IvhBu1fY FM77AhagskaFCZxwqV64Qrk328WDO89NGSd+RuovVNruDdn20TxNCEVuPTHjI0UA 8H+E6FW9jexg6RTHhPXYtCVTZWN1cmUgTmV0d29ya3MgPHNlY3VyaXR5QHNlY25l dC5jb20+iQCVAwUQMtqTKB/bLKAOe7p9AQFw5wQAgUwqJ+ZqfEy/lO1srU3nzxLA X0uHGHrMptRy/LFo8swD6G1TtWExUc3Yv/6g2/YK09b5WmplEJ+Q09maQIw+RU/s cIY+EsPauqIq4JTGh/Nm0Z4UDl2Y1x4GNtm0YqezxUPS0P0A3LHVLJ3Uo5og0G8O gPNrfbVz5ieT14OSCWCJAJUDBRAy2hd2/3eiMPDVSG0BAVNhBACfupfAcNhhnQaq aI03DOOiZSRjvql1xw4V+pPhM+IksdSK3YNUZVJJtANacgDhBT+jAPRaYbBWI3A5 ZMdcSNM8aTG0LWMLIOiOYEm6Lgd3idRBFN0Js08eyITl8mhZ33mDe4I0KQri9UiV ZcPYTbb9CWM6Hv2cMbt6S6kLnFziqIkAlQMFEDLaF0+4CIRSnlUADQEBCLoEAJwt UofDgvyZ4nCDx1KKAPkkXBRaPMWBp46xeTVcxaYiloZfwHfpk1h2mEJAxmAsvizl OtIppHl4isUxcGi/E2mLCLMvis22/IQP/9obPahPvgNaMLVtZljO1Nv3QFEkNciL FEUTNJHR1ko7ibCxkBs4cOpirFuvTMDvWnNaXAf8 =DchE - -----END PGP PUBLIC KEY BLOCK----- Copyright Notice ~~~~~~~~~~~~~~~~ The contents of this advisory are Copyright (C) 1997 Secure Networks Inc and CORE Seguridad de la Informacion S.A., and may be distributed freely provided that no fee is charged for distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers and advisories at ftp://ftp.secnet.com/advisories You can browse our web site at http://www.secnet.com You can subscribe to our security advisory mailing list by sending mail to majordomo@secnet.com with the line "subscribe sni-advisories" Patches ~~~~~~~ --- CUT HERE --- diff -cNr ../bind-4.9.5-P1-rel/contrib/host/host.c ./contrib/host/host.c *** ../bind-4.9.5-P1-rel/contrib/host/host.c Sat Oct 12 16:24:42 1996 - --- ./contrib/host/host.c Wed Apr 9 15:27:05 1997 *************** *** 537,543 **** _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = getpid() & 0x7fff; /* save new defaults */ new_res = _res; - --- 537,543 ---- _res.retrans = DEF_RETRANS; /* timeout in secs between retries */ /* initialize packet id */ ! _res.id = res_randomid(); /* save new defaults */ new_res = _res; diff -cNr ../bind-4.9.5-P1-rel/named/ns_main.c ./named/ns_main.c *** ../bind-4.9.5-P1-rel/named/ns_main.c Tue Nov 26 03:11:23 1996 - --- ./named/ns_main.c Wed Apr 9 00:24:14 1997 *************** *** 1658,1668 **** } /* ! * These are here in case we ever want to get more clever, like perhaps ! * using a bitmap to keep track of outstanding queries and a random ! * allocation scheme to make it a little harder to predict them. Note ! * that the resolver will need the same protection so the cleverness ! * should be put there rather than here; this is just an interface layer. */ void - --- 1658,1668 ---- } /* ! * This just an interface layer to the random number generator ! * used in the resolver. ! * A special random number generator is used to create non predictable ! * and non repeating ids over a long period. It also avoids reuse ! * by switching between two distinct number cycles. */ void *************** *** 1674,1683 **** u_int16_t nsid_next() { ! if (nsid_state == 65535) ! nsid_state = 0; ! else ! nsid_state++; return (nsid_state); } - --- 1674,1680 ---- u_int16_t nsid_next() { ! nsid_state = res_randomid(); return (nsid_state); } diff -cNr ../bind-4.9.5-P1-rel/res/Makefile ./res/Makefile *** ../bind-4.9.5-P1-rel/res/Makefile Thu Aug 8 16:49:48 1996 - --- ./res/Makefile Wed Apr 9 00:32:13 1997 *************** *** 77,89 **** res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o all: libresolv.a - --- 77,91 ---- res_comp.c res_init.c res_mkquery.c res_query.c res_send.c \ getnetbyaddr.c getnetbyname.c getnetent.c getnetnamadr.c \ gethnamaddr.c sethostent.c nsap_addr.c hostnamelen.c inet_addr.c \ ! inet_ntop.c inet_neta.c inet_pton.c inet_net_ntop.c inet_net_pton.c \ ! res_random.c OBJS= base64.o herror.o res_debug.o res_data.o \ res_comp.o res_init.o res_mkquery.o res_query.o res_send.o \ getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o \ gethnamaddr.o sethostent.o nsap_addr.o hostnamelen.o inet_addr.o \ ! inet_ntop.o inet_neta.o inet_pton.o inet_net_ntop.o inet_net_pton.o \ ! res_random.o all: libresolv.a diff -cNr ../bind-4.9.5-P1-rel/res/res_comp.c ./res/res_comp.c *** ../bind-4.9.5-P1-rel/res/res_comp.c Mon Dec 2 02:17:22 1996 - --- ./res/res_comp.c Fri Apr 18 18:45:02 1997 *************** *** 98,103 **** - --- 98,105 ---- dn = exp_dn; cp = comp_dn; + if (length > MAXHOSTNAMELEN-1) + length = MAXHOSTNAMELEN-1; eom = exp_dn + length; /* * fetch next label in domain name diff -cNr ../bind-4.9.5-P1-rel/res/res_init.c ./res/res_init.c *** ../bind-4.9.5-P1-rel/res/res_init.c Sat Sep 28 00:51:07 1996 - --- ./res/res_init.c Wed Apr 9 00:33:30 1997 *************** *** 197,209 **** if (!(_res.options & RES_INIT)) _res.options = RES_DEFAULT; - - /* - - * This one used to initialize implicitly to zero, so unless the app - - * has set it to something in particular, we can randomize it now. - - */ - - if (!_res.id) - - _res.id = res_randomid(); - - #ifdef USELOOPBACK _res.nsaddr.sin_addr = inet_makeaddr(IN_LOOPBACKNET, 1); #else - --- 197,202 ---- *************** *** 644,655 **** return(0); /* if not using DNS configuration from NetInfo */ } #endif /* NeXT */ - - - - u_int - - res_randomid() - - { - - struct timeval now; - - - - gettimeofday(&now, NULL); - - return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); - - } - --- 637,639 ---- diff -cNr ../bind-4.9.5-P1-rel/res/res_mkquery.c ./res/res_mkquery.c *** ../bind-4.9.5-P1-rel/res/res_mkquery.c Sat Sep 28 00:37:58 1996 - --- ./res/res_mkquery.c Wed Apr 9 00:31:30 1997 *************** *** 107,118 **** #endif /* * Initialize header fields. */ if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(++_res.id); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; - --- 107,123 ---- #endif /* * Initialize header fields. + * + * A special random number generator is used to create non predictable + * and non repeating ids over a long period. It also avoids reuse + * by switching between two distinct number cycles. */ + if ((buf == NULL) || (buflen < HFIXEDSZ)) return (-1); bzero(buf, HFIXEDSZ); hp = (HEADER *) buf; ! hp->id = htons(_res.id=res_randomid()); hp->opcode = op; hp->rd = (_res.options & RES_RECURSE) != 0; hp->rcode = NOERROR; diff -cNr ../bind-4.9.5-P1-rel/res/res_random.c ./res/res_random.c *** ../bind-4.9.5-P1-rel/res/res_random.c Wed Dec 31 17:00:00 1969 - --- ./res/res_random.c Tue Apr 22 02:31:25 1997 *************** *** 0 **** - --- 1,262 ---- + /* $OpenBSD: res_random.c,v 1.3 1997/04/19 10:07:01 provos Exp $ */ + + /* + * Copyright 1997 Niels Provos + * All rights reserved. + * + * Theo de Raadt came up with the idea of using + * such a mathematical system to generate more random (yet non-repeating) + * ids to solve the resolver/named problem. But Niels designed the + * actual system based on the constraints. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. All advertising materials mentioning features or use of this software + * must display the following acknowledgement: + * This product includes software developed by Niels Provos. + * 4. The name of the author may not be used to endorse or promote products + * derived from this software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + + /* + * seed = random 15bit + * n = prime, g0 = generator to n, + * j = random so that gcd(j,n-1) == 1 + * g = g0^j mod n will be a generator again. + * + * X[0] = random seed. + * X[n] = a*X[n-1]+b mod m is a Linear Congruential Generator + * with a = 7^(even random) mod m, + * b = random with gcd(b,m) == 1 + * m = 31104 and a maximal period of m-1. + * + * The transaction id is determined by: + * id[n] = seed xor (g^X[n] mod n) + * + * Effectivly the id is restricted to the lower 15 bits, thus + * yielding two different cycles by toggling the msb on and off. + * This avoids reuse issues caused by reseeding. + * + * The 16 bit space is very small and brute force attempts are + * entirly feasible, we skip a random number of transaction ids + * so that an attacker will not get sequential ids. + */ + + #include + #include + #include + #include + + #if defined(BSD) && (BSD >= 199103) + # include + # include + # include + #else + # include "../conf/portability.h" + #endif + + #define RU_OUT 180 /* Time after wich will be reseeded */ + #define RU_MAX 30000 /* Uniq cycle, avoid blackjack prediction */ + #define RU_GEN 2 /* Starting generator */ + #define RU_N 32749 /* RU_N-1 = 2*2*3*2729 */ + #define RU_AGEN 7 /* determine ru_a as RU_AGEN^(2*rand) */ + #define RU_M 31104 /* RU_M = 2^7*3^5 - don't change */ + + #define PFAC_N 3 + const static u_int16_t pfacts[PFAC_N] = { + 2, + 3, + 2729 + }; + + static u_int16_t ru_x; + static u_int16_t ru_seed; + static u_int16_t ru_a, ru_b; + static u_int16_t ru_g; + static u_int16_t ru_counter = 0; + static u_int16_t ru_msb = 0; + static long ru_reseed; + static u_int32_t tmp; /* Storage for unused random */ + static struct timeval tv; + + static u_int32_t pmod __P((u_int32_t, u_int32_t, u_int32_t)); + static void res_initid __P((void)); + + #ifndef __OpenBSD__ + /* + * No solid source of strong random in the system. Sigh. Fake it. + */ + u_long + arc4random() + { + static char state[256]; + char *savestate; + char *setstate(); + static unsigned seed; + static int count; + u_long datum; + + if (++count == 129837 || seed == 0) { + struct timeval tv; + + count = 0; + gettimeofday(&tv, NULL); + seed = getpid() ^ tv.tv_sec ^ tv.tv_usec; + initstate(seed, state, sizeof state); + } + savestate = setstate(state); + datum = random(); + setstate(savestate); + return (datum); + } + + #endif + + /* + * Do a fast modular exponation, returned value will be in the range + * of 0 - (mod-1) + */ + + static u_int32_t + pmod(gen, exp, mod) + u_int32_t gen, exp, mod; + { + u_int32_t s, t, u; + + s = 1; + t = gen; + u = exp; + + while (u) { + if (u & 1) + s = (s*t) % mod; + u >>= 1; + t = (t*t) % mod; + } + return (s); + } + + /* + * Initalizes the seed and chooses a suitable generator. Also toggles + * the msb flag. The msb flag is used to generate two distinct + * cycles of random numbers and thus avoiding reuse of ids. + * + * This function is called from res_randomid() when needed, an + * application does not have to worry about it. + */ + static void + res_initid() + { + u_int16_t j, i; + int noprime = 1; + + tmp = arc4random(); + ru_x = (tmp & 0xFFFF) % RU_M; + + /* 15 bits of random seed */ + ru_seed = (tmp >> 16) & 0x7FFF; + + tmp = arc4random(); + + /* Determine the LCG we use */ + ru_b = (tmp & 0xfffe) | 1; + ru_a = pmod(RU_AGEN, (tmp >> 16) & 0xfffe, RU_M); + while (ru_b % 3 == 0) + ru_b += 2; + + tmp = arc4random(); + j = tmp % RU_N; + tmp = tmp >> 16; + + /* + * Do a fast gcd(j,RU_N-1), so we can find a j with + * gcd(j, RU_N-1) == 1, giving a new generator for + * RU_GEN^j mod RU_N + */ + + while (noprime) { + for (i=0; i=PFAC_N) + noprime = 0; + else + j = (j+1) % RU_N; + } + + ru_g = pmod(RU_GEN,j,RU_N); + ru_counter = 0; + + gettimeofday(&tv, NULL); + ru_reseed = tv.tv_sec + RU_OUT; + ru_msb = ru_msb == 0x8000 ? 0 : 0x8000; + } + + u_int + res_randomid() + { + int i, n; + + gettimeofday(&tv, NULL); + if (ru_counter >= RU_MAX || tv.tv_sec > ru_reseed) + res_initid(); + + if (!tmp) + tmp = arc4random(); + + /* Skip a random number of ids */ + n = tmp & 0x2f; tmp = tmp >> 6; + if (ru_counter + n >= RU_MAX) + res_initid(); + + for (i=0; i<=n; i++) + /* Linear Congruential Generator */ + ru_x = (ru_a*ru_x + ru_b) % RU_M; + + ru_counter += i; + + return (ru_seed ^ pmod(ru_g,ru_x,RU_N)) | ru_msb; + } + + #if 0 + void + main(int argc, char **argv) + { + int i, n; + u_int16_t wert; + + res_initid(); + + printf("Generator: %d\n", ru_g); + printf("Seed: %d\n", ru_seed); + printf("Reseed at %ld\n", ru_reseed); + printf("Ru_X: %d\n", ru_x); + printf("Ru_A: %d\n", ru_a); + printf("Ru_B: %d\n", ru_b); + + n = atoi(argv[1]); + for (i=0;i Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA26412 for security-outgoing; Fri, 13 Jun 1997 05:07:16 -0700 (PDT) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA26407 for ; Fri, 13 Jun 1997 05:07:14 -0700 (PDT) From: cremers@xs4all.nl Received: from magigimmix.xs4all.nl (magigimmix.xs4all.nl [194.109.6.25]) by smtp1.xs4all.nl (8.8.5/XS4ALL) with ESMTP id OAA29399 for ; Fri, 13 Jun 1997 14:07:05 +0200 (MET DST) Received: from xs2.xs4all.nl (xs2.xs4all.nl [194.109.6.43]) by magigimmix.xs4all.nl (8.7.6/XS4ALL) with ESMTP id OAA07916 for ; Fri, 13 Jun 1997 14:07:03 +0200 (MET DST) Received: from cremers.globalxs.nl (ztm04-27.dial.xs4all.nl [194.109.32.124]) by xs2.xs4all.nl (8.7.6/XS4ALL) with SMTP id OAA18594 for ; Fri, 13 Jun 1997 14:07:01 +0200 (MET DST) Message-Id: <199706131207.OAA18594@xs2.xs4all.nl> Comments: Authenticated sender is To: security@FreeBSD.ORG Date: Fri, 13 Jun 1997 13:55:37 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: security-digest V3 #46 Reply-to: cremers@xs4all.nl Priority: normal In-reply-to: <199706122229.PAA24697@hub.freebsd.org> X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Please unsubscribe securma@xs4all.nl From owner-freebsd-security Fri Jun 13 10:48:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA09632 for security-outgoing; Fri, 13 Jun 1997 10:48:14 -0700 (PDT) Received: from sendero-ppp.i-connect.net (sendero-ppp.i-Connect.Net [206.190.143.100]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id KAA09613 for ; Fri, 13 Jun 1997 10:48:03 -0700 (PDT) Received: (qmail 17400 invoked by uid 1000); 13 Jun 1997 17:47:32 -0000 Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=iso-8859-8 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199706062115.RAA12756@khavrinen.lcs.mit.edu> Date: Fri, 13 Jun 1997 10:47:32 -0700 (PDT) Organization: Atlas Telecom From: Simon Shapiro To: Garrett Wollman Subject: Re: sequence predictability (fwd) Cc: security@FreeBSD.ORG Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Garrett Wollman; On 06-Jun-97 you wrote: > < said: > > > Good Idea. /dev/rand, setup properly produces very good results. > > It's also far too slow. > > If I had a working kernel debugger at the moment (it's sick from > version skew at the moment) or BPF (it's in use by something else) I > could document precisely how the ISS changes. In the current design, > it is incremented by a random amount which averages to approximately > the old rate. OK, Bad Idea, then :-) I think the true solution is elsewhere but will not voice my (politically incorrect) idea in public. Simon From owner-freebsd-security Fri Jun 13 17:18:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA28799 for security-outgoing; Fri, 13 Jun 1997 17:18:05 -0700 (PDT) Received: from in4.doitnow.com (in4.doitnow.com [207.98.156.13]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA28794 for ; Fri, 13 Jun 1997 17:18:03 -0700 (PDT) Received: (from tislam@localhost) by in4.doitnow.com (8.8.5/8.8.5) id RAA06458; Fri, 13 Jun 1997 17:18:18 -0700 (MST) Date: Fri, 13 Jun 1997 17:18:18 -0700 (MST) From: Taufik Islam To: security@FreeBSD.ORG Subject: 128MB ram Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am thinging of upgrading my ram size from 64M to 128MB. Do i have to do anything special ? I though I can just shutdown the machine put the extra ram and start the machine and configure the BIOS. From owner-freebsd-security Fri Jun 13 18:15:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA01273 for security-outgoing; Fri, 13 Jun 1997 18:15:17 -0700 (PDT) Received: from delsol.sunfire.net (root@delsol.sunfire.net [199.224.7.165]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA01268 for ; Fri, 13 Jun 1997 18:15:14 -0700 (PDT) Received: from localhost (afurman@localhost) by delsol.sunfire.net (8.8.5/8.6.12) with SMTP id VAA22200; Fri, 13 Jun 1997 21:14:01 -0400 (EDT) Date: Fri, 13 Jun 1997 21:14:00 -0400 (EDT) From: Adam Furman To: Taufik Islam cc: security@FreeBSD.ORG Subject: Re: 128MB ram In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You need to add a special line to your kernel. The line is options "MAXMEM=(128*1024)" # MAXMEM specifies the amount of RAM on the machine; if this is not # specified, FreeBSD will read the amount of memory from the CMOS RAM, # so the amount of memory will be limited to 64MB or 16MB depending on # the BIOS. The amount is in kilobytes, so for a machine with 128MB of # RAM, it would be 131072 (128 * 1024). Adam Adam Furman Assistant System Administrator of United Computer Specialists afurman@amf.net Irc Admin of irc.ucs.net On Fri, 13 Jun 1997, Taufik Islam wrote: > I am thinging of upgrading my ram size from 64M to 128MB. > Do i have to do anything special ? > > I though I can just shutdown the machine put the extra ram and start the > machine and configure the BIOS. > > From owner-freebsd-security Fri Jun 13 18:33:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA02115 for security-outgoing; Fri, 13 Jun 1997 18:33:25 -0700 (PDT) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA02110 for ; Fri, 13 Jun 1997 18:33:22 -0700 (PDT) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.5/8.6.9) with ESMTP id SAA07865; Fri, 13 Jun 1997 18:33:14 -0700 (PDT) To: Taufik Islam cc: security@FreeBSD.ORG Subject: Re: 128MB ram In-reply-to: Your message of "Fri, 13 Jun 1997 17:18:18 PDT." Date: Fri, 13 Jun 1997 18:33:14 -0700 Message-ID: <7862.866251994@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a message which should have been sent to questions@freebsd.org given that it is not a security issue. Jordan > I am thinging of upgrading my ram size from 64M to 128MB. > Do i have to do anything special ? > > I though I can just shutdown the machine put the extra ram and start the > machine and configure the BIOS. > > From owner-freebsd-security Fri Jun 13 20:59:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA07148 for security-outgoing; Fri, 13 Jun 1997 20:59:05 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA07087; Fri, 13 Jun 1997 20:58:04 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.5/8.8.5) id HAA13711; Sat, 14 Jun 1997 07:57:59 +0400 (MSD) Date: Sat, 14 Jun 1997 07:57:57 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: security@freebsd.org cc: peter@freebsd.org Subject: BIND & apostols: recently posted patch not work for them Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It fixes predictable IDs and MAXHOSTNAMELEN while apostols use "cache addition" and not those two techniques, so it does not work! -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/ From owner-freebsd-security Fri Jun 13 21:58:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA08904 for security-outgoing; Fri, 13 Jun 1997 21:58:32 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA08899 for ; Fri, 13 Jun 1997 21:58:30 -0700 (PDT) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id VAA28441 for ; Fri, 13 Jun 1997 21:58:24 -0700 (PDT) Received: from magigimmix.xs4all.nl (magigimmix.xs4all.nl [194.109.6.25]) by smtp1.xs4all.nl (8.8.5/XS4ALL) with ESMTP id GAA01027 for ; Sat, 14 Jun 1997 06:57:11 +0200 (MET DST) Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.6.42]) by magigimmix.xs4all.nl (8.7.6/XS4ALL) with ESMTP id GAA03419 for ; Sat, 14 Jun 1997 06:57:07 +0200 (MET DST) Received: from cremers.globalxs.nl (ztm08-03.dial.xs4all.nl [194.109.48.196]) by xs1.xs4all.nl (8.7.6/XS4ALL) with SMTP id GAA06673 for ; Sat, 14 Jun 1997 06:57:06 +0200 (MET DST) Message-Id: <199706140457.GAA06673@xs1.xs4all.nl> Comments: Authenticated sender is From: Museum.Security.Network@xs4all.nl To: security@FreeBSD.ORG Date: Sat, 14 Jun 1997 06:58:40 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: security-digest V3 #47 Reply-to: cremers@xs4all.nl Priority: normal In-reply-to: <199706140133.SAA02124@hub.freebsd.org> X-mailer: Pegasus Mail for Win32 (v2.53/R1) Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk signoff securma@xs4all.nl unsubscribe securma@xs4all.nl From owner-freebsd-security Sat Jun 14 12:13:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04463 for security-outgoing; Sat, 14 Jun 1997 12:13:00 -0700 (PDT) Received: from ns2.harborcom.net (root@ns2.harborcom.net [206.158.4.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04453 for ; Sat, 14 Jun 1997 12:12:48 -0700 (PDT) Received: from localhost (bradley@localhost) by ns2.harborcom.net (8.8.5/8.8.5) with SMTP id PAA14755; Sat, 14 Jun 1997 15:11:52 -0400 (EDT) Date: Sat, 14 Jun 1997 15:11:52 -0400 (EDT) From: Bradley Dunn X-Sender: bradley@ns2.harborcom.net Reply-To: Bradley Dunn To: Karl Denninger cc: freebsd-security@FreeBSD.ORG Subject: Re: DNS abuse (fwd) In-Reply-To: <19970612131353.63083@Jupiter.Mcs.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, 12 Jun 1997, Karl Denninger wrote: > > > Test this URL to see if your DNS is abusable. > > > > > > http://apostols.org/toolz/dnshack.cgi > > > > > > ======================================= > > Build BIND 8.1? :-) This CGI script is able to insert the "Ohhh.shit.My.DNS.server.is.vulnerable" into a server running BIND 8.1-REL. The following is from a dump: $ORIGIN shit.My.DNS.server.is.vulnerable. Ohhh 291 IN NS ns.Ohhh.shit.My.DNS.server.is.vulnerable. ;Cr=addtnl [194.179.44.34] 291 IN A 194.179.44.35 ;Cr=answer [194.179.44.34] $ORIGIN Ohhh.shit.My.DNS.server.is.vulnerable. ns 291 IN A 194.179.44.35 ;Cr=addtnl [194.179.44.34] pbd -- You can make it illegal, but you can't make it unpopular.