From owner-freebsd-security@FreeBSD.ORG Sun May 8 05:18:28 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C04216A4E0; Sun, 8 May 2005 05:18:28 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23CE643D95; Sun, 8 May 2005 05:18:28 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (cperciva@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j485ISn7011487; Sun, 8 May 2005 05:18:28 GMT (envelope-from security-advisories@freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j485IRLh011485; Sun, 8 May 2005 05:18:27 GMT (envelope-from security-advisories@freebsd.org) Date: Sun, 8 May 2005 05:18:27 GMT Message-Id: <200505080518.j485IRLh011485@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-05:06.iir [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2005 05:18:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:06.iir Security Advisory The FreeBSD Project Topic: Incorrect permissions on /dev/iir Category: core Module: sys_dev Announced: 2005-05-06 Credits: Christian S.J. Peron Andre Guibert de Bruet Affects: All FreeBSD 4.x releases since 4.6-RELEASE All FreeBSD 5.x releases prior to 5.4-RELEASE Corrected: 2005-05-06 02:33:46 UTC (RELENG_5, 5.4-STABLE) 2005-05-06 02:34:18 UTC (RELENG_5_4, 5.4-RELEASE) 2005-05-06 02:34:01 UTC (RELENG_5_3, 5.3-RELEASE-p11) 2005-05-06 02:32:54 UTC (RELENG_4, 4.11-STABLE) 2005-05-06 02:33:28 UTC (RELENG_4_11, 4.11-RELEASE-p5) 2005-05-06 02:33:12 UTC (RELENG_4_10, 4.10-RELEASE-p10) CVE Name: CAN-2005-1399 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2005-05-06 Initial release. v1.1 2005-05-07 Updated credits to include Andre Guibert de Bruet, who was inadvertantly omitted from the original advisory. I. Background The iir(4) driver provides support for the Intel Integrated RAID controllers and ICP Vortex RAID controllers. II. Problem Description The default permissions on the /dev/iir device node allow unprivileged local users to open the device and execute ioctl calls. III. Impact Unprivileged local users can send commands to the hardware supported by the iir(4) driver, allowing destruction of data and possible disclosure of data. IV. Workaround Systems without hardware supported by the iir(4) driver are not affected by this issue. On systems which are affected, as a workaround, the permissions on /dev/iir can be changed manually. As root, execute the following command: # chmod 0600 /dev/iir* On 5.x, the following commands are also needed to ensure that the correct permissions are used after rebooting. # echo 'perm iir* 0600' >> /etc/devfs.conf # echo 'devfs_enable="YES"' >> /etc/rc.conf If the administrator has created additional device nodes, or mounted additional instances of devfs(5) elsewhere in the file system name space, attention should be paid to ensure that either the iir device node is not visible in those name spaces, or is similarly protected. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.10, 4.11, and 5.3 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:06/iir.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:06/iir.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/dev/iir/iir_ctrl.c 1.2.2.5 RELENG_4_11 src/UPDATING 1.73.2.91.2.6 src/sys/conf/newvers.sh 1.44.2.39.2.9 src/sys/dev/iir/iir_ctrl.c 1.2.2.4.12.1 RELENG_4_10 src/UPDATING 1.73.2.90.2.11 src/sys/conf/newvers.sh 1.44.2.34.2.12 src/sys/dev/iir/iir_ctrl.c 1.2.2.4.10.1 RELENG_5 src/sys/dev/iir/iir_ctrl.c 1.15.2.2 RELENG_5_4 src/UPDATING 1.342.2.24.2.5 src/sys/dev/iir/iir_ctrl.c 1.15.2.1.2.1 RELENG_5_3 src/UPDATING 1.342.2.13.2.14 src/sys/conf/newvers.sh 1.62.2.15.2.16 src/sys/dev/iir/iir_ctrl.c 1.15.4.1 - ------------------------------------------------------------------------- The latest revision of this advisory is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:06.iir.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCfEXyFdaIBMps37IRAu6WAJ9qBjsIfH7GGPRiHsvXwlkuau5kswCfXhan YhoUBZ4gHuIXJFM1gOEAyVk= =zRAR -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sun May 8 22:28:34 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 136FD16A4EA; Sun, 8 May 2005 22:28:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D32643D99; Sun, 8 May 2005 22:28:33 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (cperciva@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j48MSX6l067426; Sun, 8 May 2005 22:28:33 GMT (envelope-from security-advisories@freebsd.org) Received: (from cperciva@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j48MSXbO067424; Sun, 8 May 2005 22:28:33 GMT (envelope-from security-advisories@freebsd.org) Date: Sun, 8 May 2005 22:28:33 GMT Message-Id: <200505082228.j48MSXbO067424@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: cperciva set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-05:08.kmem [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 May 2005 22:28:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:08.kmem Security Advisory The FreeBSD Project Topic: Local kernel memory disclosure Category: core Module: sys Announced: 2005-05-06 Credits: Christian S.J. Peron Uwe Doering Affects: All FreeBSD releases prior to 5.4-RELEASE Corrected: 2005-05-08 10:19:37 UTC (RELENG_5, 5.4-STABLE) 2005-05-07 03:58:26 UTC (RELENG_5_4, 5.4-RELEASE) 2005-05-08 10:23:52 UTC (RELENG_5_3, 5.3-RELEASE-p14) 2005-05-08 10:26:42 UTC (RELENG_4, 4.11-STABLE) 2005-05-08 10:29:54 UTC (RELENG_4_11, 4.11-RELEASE-p8) 2005-05-08 10:35:56 UTC (RELENG_4_10, 4.10-RELEASE-p13) CVE Name: CAN-2005-1406 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2005-05-06 Initial release. v1.1 2005-05-07 Updated patch to include related issues reported by Uwe Doering. I. Background In many parts of the FreeBSD kernel, names (of mount points, devices, files, etc.) are manipulated as NULL-terminated strings, but are provided to applications within fixed-length buffers. II. Problem Description In several places, variable-length strings were copied into fixed-length buffers without zeroing the unused portion of the buffer. III. Impact The previous contents of part of the fixed-length buffers will be disclosed to applications. Such memory might contain sensitive information, such as portions of the file cache or terminal buffers. This information might be directly useful, or it might be leveraged to obtain elevated privileges in some way. For example, a terminal buffer might include a user-entered password. IV. Workaround No workaround is available. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.10, 4.11, and 5.3 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. [FreeBSD 4.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem4x.patch.asc [FreeBSD 5.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem5x.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:08/kmem5x.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/kern/uipc_usrreq.c 1.54.2.11 src/sys/kern/vfs_subr.c 1.249.2.32 src/sys/net/if_mib.c 1.8.2.3 src/sys/netinet/ip_divert.c 1.42.2.8 src/sys/netinet/raw_ip.c 1.64.2.20 src/sys/netinet/tcp_subr.c 1.73.2.34 src/sys/netinet/udp_usrreq.c 1.64.2.20 RELENG_4_11 src/UPDATING 1.72.2.91.2.9 src/sys/conf/newvers.sh 1.44.2.39.2.12 src/sys/kern/uipc_usrreq.c 1.54.2.10.8.1 src/sys/kern/vfs_subr.c 1.249.2.31.6.1 src/sys/net/if_mib.c 1.8.2.2.2.1 src/sys/netinet/ip_divert.c 1.42.2.7.2.1 src/sys/netinet/raw_ip.c 1.64.2.19.2.1 src/sys/netinet/tcp_subr.c 1.73.2.33.4.1 src/sys/netinet/udp_usrreq.c 1.64.2.19.6.1 RELENG_4_10 src/UPDATING 1.73.2.90.2.14 src/sys/conf/newvers.sh 1.44.2.34.2.15 src/sys/kern/uipc_usrreq.c 1.54.2.10.6.1 src/sys/kern/vfs_subr.c 1.249.2.31.4.1 src/sys/net/if_mib.c 1.8.2.1.16.2 src/sys/netinet/ip_divert.c 1.42.2.6.6.1 src/sys/netinet/raw_ip.c 1.64.2.18.4.1 src/sys/netinet/tcp_subr.c 1.73.2.33.2.1 src/sys/netinet/udp_usrreq.c 1.64.2.19.4.1 RELENG_5 src/sys/kern/subr_bus.c 1.156.2.7 src/sys/kern/uipc_usrreq.c 1.138.2.14 src/sys/kern/vfs_subr.c 1.522.2.5 src/sys/net/if_mib.c 1.13.4.2 src/sys/netinet/ip_divert.c 1.98.2.3 src/sys/netinet/raw_ip.c 1.142.2.5 src/sys/netinet/tcp_subr.c 1.201.2.18 src/sys/netinet/udp_usrreq.c 1.162.2.8 RELENG_5_4 src/UPDATING 1.342.2.24.2.9 src/sys/kern/subr_bus.c 1.156.2.5.2.1 src/sys/kern/uipc_usrreq.c 1.138.2.13.2.1 src/sys/kern/vfs_subr.c 1.522.2.4.2.1 src/sys/net/if_mib.c 1.13.4.1.2.1 src/sys/netinet/ip_divert.c 1.98.2.2.2.1 src/sys/netinet/raw_ip.c 1.142.2.4.2.1 src/sys/netinet/tcp_subr.c 1.201.2.15.2.1 src/sys/netinet/udp_usrreq.c 1.162.2.7.2.1 RELENG_5_3 src/UPDATING 1.342.2.13.2.17 src/sys/conf/newvers.sh 1.62.2.15.2.19 src/sys/kern/subr_bus.c 1.156.2.2.2.1 src/sys/kern/uipc_usrreq.c 1.138.2.2.2.2 src/sys/kern/vfs_subr.c 1.522.2.1.2.1 src/sys/net/if_mib.c 1.13.6.1 src/sys/netinet/ip_divert.c 1.98.4.1 src/sys/netinet/raw_ip.c 1.142.2.2.2.1 src/sys/netinet/tcp_subr.c 1.201.2.1.2.2 src/sys/netinet/udp_usrreq.c 1.162.2.3.2.1 - ------------------------------------------------------------------------- The latest revision of this advisory is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:08.kmem.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCfe9TFdaIBMps37IRAoANAJ9SvXgbD8c2Pw4akOWba95PklG1NgCeOPce Ib7DiBQuu7LR2ZG70BP+eKQ= =8wrv -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Mon May 9 00:38:46 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC58A16A4E6 for ; Mon, 9 May 2005 00:38:46 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7296943D53 for ; Mon, 9 May 2005 00:38:46 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so643971rnf for ; Sun, 08 May 2005 17:38:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=DR/Jhe70aY8pyvjoDLYBQhoN3OZeVdO3JAWITlQ1vv2Ty0ldYofs5zL7ZnxwwC56rumGxPN1dM/fsTEE63NHAW+RDqtcWX0hvP+rgk7bEcW1gEHEOBFaUC9G6sj5DFzvoo9ILSu9Q69Yf5fhH8JJRmHXid7PUPTeNesOqLBRvg8= Received: by 10.38.78.47 with SMTP id a47mr649187rnb; Sun, 08 May 2005 17:38:46 -0700 (PDT) Received: by 10.38.101.1 with HTTP; Sun, 8 May 2005 17:38:46 -0700 (PDT) Message-ID: <245f0df105050817385e256c16@mail.gmail.com> Date: Mon, 9 May 2005 10:38:46 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: RE: Mozilla cross patforming code X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2005 00:38:46 -0000 Please be aware of 2 exploits currently running wild, one of wich is cross platform and verified as running on BSD, here is a 1.0.2 crossplatforming code PoC i found in a search -> http://www.milw0rm.com/id.php?id=3D943 There is 'newer' code and PoC of this (k-otik.com,other publics), however it is not mentionioned as it is not 100% verified as cross platforming yet. I recommend people keep speedy with browser updating, Mozilla is not as solid as it once was. I hope this can help anyone out there, it was brought to my attention by a colleague who was plagued with this all week last week. Regards, --=20 ------------------------------------------ Drew B. /* Security researcher/expert,threat-focus,Freelance */ ------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Wed May 11 20:43:13 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0884316A4CE for ; Wed, 11 May 2005 20:43:13 +0000 (GMT) Received: from web41527.mail.yahoo.com (web41527.mail.yahoo.com [66.218.94.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 7179243D88 for ; Wed, 11 May 2005 20:43:12 +0000 (GMT) (envelope-from thewolfro@yahoo.com) Received: (qmail 32862 invoked by uid 60001); 11 May 2005 20:43:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=RBxEslxGwKypNQkUfpnH6bN0VL4PrWIlz+swudH/uokyV3iTZUgjAwXzlz6yjy5Kim+Z/j4ErIyZQHP8kdTTxF+Y2cTZwvDm5UfNb5r6Qut33pqbYk3LYKDKsj6tNjy2NITdV5gXA9Z44QP0Sno1yBG9RftCipGNxiGgb3LNdZ8= ; Message-ID: <20050511204312.32860.qmail@web41527.mail.yahoo.com> Received: from [81.181.70.11] by web41527.mail.yahoo.com via HTTP; Wed, 11 May 2005 13:43:12 PDT Date: Wed, 11 May 2005 13:43:12 -0700 (PDT) From: george roman To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 20:43:13 -0000 hi i have a problem with my icmp, i have a router that performs nat. i cannot ping to internet hosts from more than one stations situated behind NAT at once. if i want to ping from another station i have to stop the ping that was initiated from the first host, and after a few seconds i can ping from another station.i've checked firewll and i have no ipfw rules that could stop icmp traffic. where should i continue my search and what can i do to resolv this problem. i really have to get ping wrking from more than one stations at once. 10x for your help Discover Yahoo! Get on-the-go sports scores, stock quotes, news and more. Check it out! http://discover.yahoo.com/mobile.html From owner-freebsd-security@FreeBSD.ORG Wed May 11 20:57:27 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECB7316A4CE for ; Wed, 11 May 2005 20:57:27 +0000 (GMT) Received: from web41210.mail.yahoo.com (web41210.mail.yahoo.com [66.218.93.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BA4D43D78 for ; Wed, 11 May 2005 20:57:27 +0000 (GMT) (envelope-from arne_woerner@yahoo.com) Received: (qmail 48286 invoked by uid 60001); 11 May 2005 20:57:23 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=rgaKAMyNhZI/Tsi8kW5kM8j984tuh/ddbLD56h8Ib3jUoLrCUkgu+9LqHwioknT5fPnAPqtwtfFN5Hx1eKb9Sn8pLFStcf9BWvv9x02pIyTzfaMyb9evXEPua4DTaoy//u+i0FNtfSXWnHbSSviitU92YZTJucZr5tW0S+4IF50= ; Message-ID: <20050511205723.48284.qmail@web41210.mail.yahoo.com> Received: from [83.129.183.66] by web41210.mail.yahoo.com via HTTP; Wed, 11 May 2005 13:57:23 PDT Date: Wed, 11 May 2005 13:57:23 -0700 (PDT) From: Arne "Wörner" To: george roman , freebsd-security@freebsd.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2005 20:57:28 -0000 --- george roman wrote: > hi i have a problem with my icmp, i have a router that > performs nat. i cannot ping to internet hosts from > more than one stations situated behind NAT at once. if > i want to ping from another station i have to stop the > ping that was initiated from the first host, and after > a few seconds i can ping from another station.i've > checked firewll and i have no ipfw rules that could > stop icmp traffic. where should i continue my search > and what can i do to resolv this problem. i really > have to get ping wrking from more than one stations at > once. > Hi! I would guess, that ICMP packets do not have a port number (just a request/response id), so that the NAT cannot distinguish multiple ICMP packet sources (I mean: The response from the ICMP requestee cannot be mapped back to the appropriate ICMP requester). Hmm... I just think, that (if you have multiple ICMP requestees) the NAT could be able to map back the ICMP requester IP by the IP of the ICMP requestee. But I do not know, how your router works... Maybe your computer-pool could elect an ICMP-master, who coordinates all the ICMP traffic through the NAT. Bye Arne __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From owner-freebsd-security@FreeBSD.ORG Thu May 12 09:18:05 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A949C16A4D0 for ; Thu, 12 May 2005 09:18:05 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3113743D5C for ; Thu, 12 May 2005 09:18:05 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so27580rne for ; Thu, 12 May 2005 02:18:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=IyzA5uHg2ly35nBYk/McVdC5RBeCOhsENi5p+DI0TfqDRr28EFRV27jqxFExx/v79WWph7FoNLS1o+fOcgIxxWJhvMgpbWE5qgKHtgAB2WPAP0h0Hntu0hPUUEC5/XZ3YHJXYNR1ikN08lrcRRO6y0nqXSzpO+Gpu+w676DmlvA= Received: by 10.38.208.18 with SMTP id f18mr109339rng; Thu, 12 May 2005 02:18:04 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Thu, 12 May 2005 02:18:04 -0700 (PDT) Message-ID: <245f0df10505120218730440a4@mail.gmail.com> Date: Thu, 12 May 2005 19:18:04 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: RE: Mozilla 1.0.4 security update (Just install it, will keep all settings) + Important note from me,please read,those uninterested,please dont flame ;) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 09:18:05 -0000 Update to the mozilla vulnerabilities wich were not Publicly reported (To MY standard, for BSD/Cros platform users) , so i performed my own research,PoC's etc, and have submitted all my results. I wont say i had ANYTHING atall todo with the Update, BUT please Update a.s.a.p to mozilla v1.0.4 , that should stop atleast ONE exploit, the other may be a simple matter oif not allowing your Javascript to 'perform certain commands' , atm,my setting is to 'allow window resizing' only, wich seems all it needs to function, and it is 'handy', (unfortunately). http://mozilla.mirrors.tds.net/pub/mozilla.org/firefox/releases/1.0.4/ ^^ thats one mirror. This was the first 'major' exploitation, so it is trying to be kept under relative control. If i had some more 'company' support, as my recent Isp has become tired with amount of work I have had to putin (Hence =3D $$ basically to pay me). ~~~~ Some comments from Me personally to ANYONE interested (I will work seriously on this,at a Very LOW fee(If any..), only if certain things are met), but anyhow this is the stuff wich is iportant. First 2 Points, 1. No one seems to give a rats bum about spamming, and i have got a non public scanner+exploiter wich infects BSD mailservers,and can massmail, i receive this 2 weeks ago, but dues to my limited knowledge, was only able to have the place shutdown,however, not before a colleague had to sit down and manually deleye about 40,000 emails. So it is NOT just a small prolem, the real problem, is educating Admins and Techs, and I will tel you right now, it does NOT matter about where you come from, it is what you know, so ignore people from symantec thinking they have a "solution to everything" , say one word to them "Mophine by Holy-Father", and that should shutup 99% of the A/V. 2. The situation is now beyond just a "joke" , it is now for profit,I have intercepted unpacked binaries,unfortately,as I have limited support,I can only trace the major attackers,using the attackers equipment,sire,i could find many "roots' etc. I mean the actual "offender address/details". I dont think this has ever been successfully done,I am willing to start a project, anti-spam or similar, and will start with Victoria. Asin - Remote disinfection, well,if people WONT secure, then i will secure theyre machine for them, or , spit me ideas..im waiting,have been along time. Note also, I am not nor, have ever been a "hacker", so you can make whatever presumptions you like. I am a 30yr old, who was compromised about 10times,then tried to attack the comromisers,but realised they were MUCH more powerful than me, so i had to backoff...heres a quick ref if you like, one small example:: http://www.airscanner.com/pubs/hacked1.pdf http://www.airscanner.com/pubs/hacked2.pdf This is what i mean by ... educating people, the people who this happens to, it shouldnt be happening to, and some of that is not updating due to piracy etc,BUT alo is done on purpose, and for many reasons wich i cannot draw into here nor now, it is much larger than this,although xdcc wrezkits will be a focus,as i can easily find these,logins,passwords,and complete info, only because I have personally developed MY OWN app for that.So i can confidentally say, I have done my homework. However it is time to open up, ive had enough seeing silly spams everyday and reporting to spoof@ebay.com etc. I am offering to shutdown MAJOR hacking orgs,such as makers of these exploits, but i have ONE problem, who do i speak to, who do i trust,who will indeed work with me to try and legalise a section for "sertain experienced people"?!?! This is a NEW area, wich should really be inputted by some people who have done 'extensive' testing, to point of stuff i cannot mention here even,these people will understand my post,and know what i am saying. Please Note:: I can supply much more simple searches etc wich have yielded me extremnely sensitive info, yes i had to poke about on hackers websites,but err, isnt that what they are doing? This is the major problem, I need authority to 'investigate' , and in this area,it is not really funded,however,imagine if all .au dns and normal servers were running @ Peak. I think , alot more Isps would get success,as with the users mainly,connection and everything would be improved majorly.Just remember, you can maybe ignore it, but the problem is no longer ignoreable to system admins, so I am acting,those with me, are welcome to join me and we will register it as a project etc. I am currently looking through the ports to find a better security feature for FreeBSD,i thikk it should be bettered/improved. So ANY offers to aid me in my research, would be welcomed greatly, Regards, Drew B. --=20 ------------------------------------------ Drew B. /* Security researcher/expert,threat-focus,Freelance */ ------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Thu May 12 10:24:19 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 762FE16A4CE for ; Thu, 12 May 2005 10:24:19 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id DC71743D2D for ; Thu, 12 May 2005 10:24:18 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 15359 invoked by uid 1001); 12 May 2005 10:24:17 -0000 Date: Thu, 12 May 2005 06:24:17 -0400 From: "Peter C. Lai" To: "Drew B. [Security Expertise/Freelance Security research]." Message-ID: <20050512102417.GA608@cowbert.2y.net> References: <245f0df10505120218730440a4@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <245f0df10505120218730440a4@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-security@freebsd.org Subject: Re: Mozilla 1.0.4 security update (Just install it, will keep all settings) + Important note from me,please read,those uninterested,please dont flame ;) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 10:24:19 -0000 On Thu, May 12, 2005 at 07:18:04PM +1000, Drew B. [Security Expertise/Freelance Security research]. wrote: > Update to the mozilla vulnerabilities wich were not Publicly reported > (To MY standard, for BSD/Cros platform users) , so i performed my own These have been documented in vuxml already. Thanks anyway. -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-security@FreeBSD.ORG Thu May 12 14:17:30 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9DCB16A4CE for ; Thu, 12 May 2005 14:17:30 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 486A543D53 for ; Thu, 12 May 2005 14:17:30 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so61550rne for ; Thu, 12 May 2005 07:17:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=j7wMuy1MqGeDLav2vLHACNK0+UHw5YcXqOgtzLpBOV4IsckKtqIsCEqryIkt2h+bXo+/rB4JalnDeezLByCH2W4VAOxMdeJz8u/eHL7VBWylF8NGLIGYrjjTbKg5xlZFts8idYhXq/vOztGL6qH9hEgJehRcuSkEvkC6K0Q/AdI= Received: by 10.38.208.18 with SMTP id f18mr225416rng; Thu, 12 May 2005 07:17:29 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Thu, 12 May 2005 07:17:29 -0700 (PDT) Message-ID: <245f0df1050512071761b30fab@mail.gmail.com> Date: Fri, 13 May 2005 00:17:29 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: "Peter C. Lai" In-Reply-To: <20050512102417.GA608@cowbert.2y.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <245f0df10505120218730440a4@mail.gmail.com> <20050512102417.GA608@cowbert.2y.net> cc: freebsd-security@freebsd.org Subject: Re: Mozilla 1.0.4 security update (Just install it, will keep all settings) + Important note from me,please read,those uninterested,please dont flame ;) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 14:17:30 -0000 These have been documented in vuxml already. Thanks anyway. Ohh , i am mising somewhere i should be looking then perhaps, thankyou for letting me know, FreeBSD mailing lists, and the asociated Cvs etc, its so large ,thankyou for pointing that out, was a flaw in my Information gathering system, thankyou for notifying me. :-) Regards, Drew B. On 5/12/05, Peter C. Lai wrote: > On Thu, May 12, 2005 at 07:18:04PM +1000, Drew B. [Security Expertise/Fre= elance Security research]. wrote: > > Update to the mozilla vulnerabilities wich were not Publicly reported > > (To MY standard, for BSD/Cros platform users) , so i performed my own >=20 > These have been documented in vuxml already. Thanks anyway. >=20 > >=20 > -- > Peter C. Lai > University of Connecticut > Dept. of Molecular and Cell Biology > Yale University School of Medicine > SenseLab | Research Assistant > http://cowbert.2y.net/ >=20 >=20 --=20 ------------------------------------------ Drew B. /* Security researcher/expert,threat-focus,Freelance */ ------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Thu May 12 16:38:07 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19DAF16A4D0 for ; Thu, 12 May 2005 16:38:07 +0000 (GMT) Received: from web20424.mail.yahoo.com (web20424.mail.yahoo.com [66.163.170.247]) by mx1.FreeBSD.org (Postfix) with SMTP id 88B8143D31 for ; Thu, 12 May 2005 16:38:06 +0000 (GMT) (envelope-from dhutch9999@yahoo.com) Received: (qmail 98444 invoked by uid 60001); 12 May 2005 16:38:06 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=VrHwT40QmhgiIjUssMToQ4Da2vzD/FgghMFJetryAHP1gm4eFlBVJkjsKnPIAGgOzXoyDCW1ZFudfoRXjw5d4CHUFYZrzuMlRS+1JqEUkP2gmrmgZuEUNYjNTDimjwWG5yznfUoeWAw+PSPg2TLOXYFRkueDDG/7dfbS7EHbjgg= ; Message-ID: <20050512163806.98442.qmail@web20424.mail.yahoo.com> Received: from [12.153.72.219] by web20424.mail.yahoo.com via HTTP; Thu, 12 May 2005 09:38:06 PDT Date: Thu, 12 May 2005 09:38:06 -0700 (PDT) From: DH To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-911594080-1115915886=:97759" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: Do I have an infected init file? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 16:38:07 -0000 --0-911594080-1115915886=:97759 Content-Type: text/plain; charset=us-ascii Hello; I'm running a FreeBSD 4.10-release-p2 box and both chkrootkit 0.44 & 0.45 report that my /sbin/init file is infected. It appears as though the egrep for "UPX" in the output of "strings" triggers the infected notice. When I copy the init file from an uninfected box to this one chkrootkit continues to report it as infected. Is chkrootkit reading a copy of the /sbin/init file stored in active memory? If my machine is compromised, which rootkit is installed / how can I find out which rootkit is installed? As a side note, neither Kaspersky AV nor rkhunter report any infections. Attached is some of the debug output. Thanks in advance to any respondents. Sincerely; David Hutchens III --------------------------------- Discover Yahoo! Find restaurants, movies, travel & more fun for the weekend. Check it out! --0-911594080-1115915886=:97759-- From owner-freebsd-security@FreeBSD.ORG Thu May 12 21:00:10 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B72716A4CE for ; Thu, 12 May 2005 21:00:10 +0000 (GMT) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA89543D62 for ; Thu, 12 May 2005 21:00:09 +0000 (GMT) (envelope-from piechota@argolis.org) Received: from acropolis.argolis.org ([69.250.108.21]) by comcast.net (rwcrmhc14) with ESMTP id <2005051220574501400cempve>; Thu, 12 May 2005 20:57:45 +0000 Received: from acropolis.argolis.org (localhost [127.0.0.1]) by acropolis.argolis.org (8.13.3/8.13.1) with ESMTP id j4CKvYKo040132; Thu, 12 May 2005 16:57:34 -0400 (EDT) (envelope-from piechota@argolis.org) Received: from localhost (piechota@localhost)j4CKvYRA040129; Thu, 12 May 2005 16:57:34 -0400 (EDT) (envelope-from piechota@argolis.org) X-Authentication-Warning: acropolis.argolis.org: piechota owned process doing -bs Date: Thu, 12 May 2005 16:57:30 -0400 (EDT) From: Matt Piechota To: DH In-Reply-To: <20050512163806.98442.qmail@web20424.mail.yahoo.com> Message-ID: <20050512160348.J38870@acropolis.argolis.org> References: <20050512163806.98442.qmail@web20424.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-security@freebsd.org Subject: Re: Do I have an infected init file? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2005 21:00:10 -0000 On Thu, 12 May 2005, DH wrote: > I'm running a FreeBSD 4.10-release-p2 box and both chkrootkit 0.44 & > 0.45 report that my /sbin/init file is infected. I should mention that 4.10-release is up to p13. You should really think about patching up to current. > It appears as though the egrep for "UPX" in the output of "strings" > triggers the infected notice. When I copy the init file from an > uninfected box to this one chkrootkit continues to report it as > infected. Is chkrootkit reading a copy of the /sbin/init file stored in > active memory? If my machine is compromised, which rootkit is installed > / how can I find out which rootkit is installed? The easiest way to figure out if you are rooted is probably to download or create a clean version of /sbin/init, and compare the two files. Creating might take some work, you'd have to install a clean 4.10, patch it to p2, and make world. -- Matt Piechota Key Available from pgp.mit.edu PGP Key fingerprint = FC90 4D65 2F8A 38E9 D1A8 FABB 7AE8 C194 5EC8 9CAD From owner-freebsd-security@FreeBSD.ORG Fri May 13 00:38:35 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B76EE16A4CE; Fri, 13 May 2005 00:38:35 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6379D43D2D; Fri, 13 May 2005 00:38:35 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (nectar@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4D0cZJe085982; Fri, 13 May 2005 00:38:35 GMT (envelope-from security-advisories@freebsd.org) Received: (from nectar@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4D0cZvx085980; Fri, 13 May 2005 00:38:35 GMT (envelope-from security-advisories@freebsd.org) Date: Fri, 13 May 2005 00:38:35 GMT Message-Id: <200505130038.j4D0cZvx085980@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: nectar set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-05:09.htt X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 00:38:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:09.htt Security Advisory The FreeBSD Project Topic: information disclosure when using HTT Category: core Module: sys Announced: 2005-05-13 Revised: 2005-05-13 Credits: Colin Percival Affects: All FreeBSD/i386 and FreeBSD/amd64 releases. Corrected: 2005-05-13 00:13:00 UTC (RELENG_5, 5.4-STABLE) 2005-05-13 00:13:00 UTC (RELENG_5_4, 5.4-RELEASE-p1) 2005-05-13 00:13:00 UTC (RELENG_5_3, 5.3-RELEASE-p15) 2005-05-13 00:13:00 UTC (RELENG_4, 4.11-STABLE) 2005-05-13 00:13:00 UTC (RELENG_4_11, 4.11-RELEASE-p9) 2005-05-13 00:13:00 UTC (RELENG_4_10, 4.10-RELEASE-p14) CVE Name: CAN-2005-0109 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background "Hyper-Threading Technology" is the name used for the implementation of simultaneous multithreading on Intel Pentium 4, Mobile Pentium 4, and Xeon processors. II. Problem Description A security flaw involving operating systems running on Hyper-Threading Technology processors was has been reported. Complete details are not available at the time of this writing. However, a workaround has been issued. It is expected that more details will be available tomorrow, at which time a revised version of this advisory will be published. III. Impact Information may be disclosed to local users, allowing in many cases for privilege escalation. IV. Workaround Systems not using processors with Hyper-Threading support are not affected by this issue. On systems which are affected, the security flaw can be eliminated by setting the "machdep.hlt_logical_cpus" tunable: # echo "machdep.hlt_logical_cpus=1" >> /boot/loader.conf The system must be rebooted in order for tunables to take effect. Use of this workaround is not recommended on "dual-core" systems, as this workaround will also disable one of the processor cores. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_4, RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.10, 4.11, 5.3, and 5.4 systems. a) Download the relevant patch from the location below and verify the detached PGP signature using your PGP utility. [FreeBSD 4.10] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt410.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt410.patch.asc [FreeBSD 4.11] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt411.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt411.patch.asc [FreeBSD 5.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. NOTE: For users that are certain that their environment is not affected by this vulnerability, such as single-user systems, Hyper-Threading Technology may be re-enabled by setting the tunable "machdep.hyperthreading_allowed". VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/i386/i386/mp_machdep.c 1.115.2.23 src/sys/i386/include/cpufunc.h 1.96.2.4 RELENG_4_11 src/UPDATING 1.73.2.91.2.10 src/sys/conf/newvers.sh 1.44.2.39.2.13 src/sys/i386/i386/mp_machdep.c 1.115.2.22.2.1 src/sys/i386/include/cpufunc.h 1.96.2.3.12.1 RELENG_4_10 src/UPDATING 1.73.2.90.2.15 src/sys/conf/newvers.sh 1.44.2.34.2.16 src/sys/i386/i386/mp_machdep.c 1.115.2.20.2.1 src/sys/i386/include/cpufunc.h 1.96.2.3.10.1 RELENG_5 src/sys/amd64/amd64/mp_machdep.c 1.242.2.11 src/sys/amd64/include/cpufunc.h 1.145.2.1 src/sys/i386/i386/mp_machdep.c 1.235.2.10 src/sys/i386/include/cpufunc.h 1.142.2.1 RELENG_5_4 src/UPDATING 1.342.2.24.2.10 src/sys/amd64/amd64/mp_machdep.c 1.242.2.7.2.4 src/sys/amd64/include/cpufunc.h 1.145.6.1 src/sys/conf/newvers.sh 1.62.2.18.2.6 src/sys/i386/i386/mp_machdep.c 1.235.2.6.2.3 src/sys/i386/include/cpufunc.h 1.142.6.1 RELENG_5_3 src/UPDATING 1.342.2.13.2.18 src/sys/amd64/amd64/mp_machdep.c 1.242.2.2.2.2 src/sys/amd64/include/cpufunc.h 1.145.4.1 src/sys/conf/newvers.sh 1.62.2.15.2.20 src/sys/i386/i386/mp_machdep.c 1.235.2.3.2.2 src/sys/i386/include/cpufunc.h 1.142.4.1 - ------------------------------------------------------------------------- VII. References http://www.daemonology.net/hyperthreading-considered-harmful/ The latest revision of this advisory is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:09.htt.asc -----BEGIN PGP SIGNATURE----- iD8DBQFCg/RTFdaIBMps37IRAsPSAJ4tjVMklYy1N4QOWlDyVEAORkz+hACgmwMB vDnIfC+nobvQbb6onu7XkBc= =Yawq -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri May 13 01:51:12 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1B5716A4CE for ; Fri, 13 May 2005 01:51:12 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78BB643D82 for ; Fri, 13 May 2005 01:51:12 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so139446rne for ; Thu, 12 May 2005 18:51:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=A3jIleMCjkEYQhf/CfXJTrhgolGvv2CHjHK92FX+gD4wwLLAAdu1JLfDzv4Do0rfKjiI6s1+Pwwrj6KvbrwhVc7hkxuaKDFCs2VsMs4yMb4gi5NnnUKqVNtm9SdRz18HKUK/c5p/1xvlnS7eAXLm9yKVW3180mlWJIhyBHJOR/E= Received: by 10.39.3.47 with SMTP id f47mr506928rni; Thu, 12 May 2005 18:51:12 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Thu, 12 May 2005 18:51:12 -0700 (PDT) Message-ID: <245f0df105051218514285cc49@mail.gmail.com> Date: Fri, 13 May 2005 11:51:12 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: Matt Piechota In-Reply-To: <20050512160348.J38870@acropolis.argolis.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050512163806.98442.qmail@web20424.mail.yahoo.com> <20050512160348.J38870@acropolis.argolis.org> cc: freebsd-security@freebsd.org Subject: Re: Do I have an infected init file? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 01:51:13 -0000 Hello, I have used rootkit-hunter for Bsd, it can download MD5sums from whitehat which contains 'current' sigs, not that this matters, it only takes a good packagee,(ie file is encrypted, to bypass any rootkit revealer etc) However i do recommend rootkit-hunter, http://www.rootkit.nl ,it just runs when needed, (/rkhunter -c, /rkhunter --update), and it does a VERY thorough job, I recommend runing it without update forst,then update it, you will no doubt find some multiple package installs, wich seems to be a major problem with this, older package info staying in root,after package is updated. Hope this info is of any help, i can provide a detailed log of a rootkithunter.log..just ask me to attach a copy. Regards, Drew B. On 5/13/05, Matt Piechota wrote: > On Thu, 12 May 2005, DH wrote: >=20 > > I'm running a FreeBSD 4.10-release-p2 box and both chkrootkit 0.44 & > > 0.45 report that my /sbin/init file is infected. >=20 > I should mention that 4.10-release is up to p13. You should really think > about patching up to current. >=20 > > It appears as though the egrep for "UPX" in the output of "strings" > > triggers the infected notice. When I copy the init file from an > > uninfected box to this one chkrootkit continues to report it as > > infected. Is chkrootkit reading a copy of the /sbin/init file stored in > > active memory? If my machine is compromised, which rootkit is installed > > / how can I find out which rootkit is installed? >=20 > The easiest way to figure out if you are rooted is probably to download o= r > create a clean version of /sbin/init, and compare the two files. > Creating might take some work, you'd have to install a clean 4.10, patch > it to p2, and make world. >=20 > -- > Matt Piechota > Key Available from pgp.mit.edu > PGP Key fingerprint =3D FC90 4D65 2F8A 38E9 D1A8 FABB 7AE8 C194 5EC8 9CA= D > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >=20 --=20 ------------------------------------------ Drew B. /* Security researcher/expert,threat-focus,Freelance */ ------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Fri May 13 04:00:10 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56C1516A4D0 for ; Fri, 13 May 2005 04:00:10 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id C233843D86 for ; Fri, 13 May 2005 04:00:09 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so149237rne for ; Thu, 12 May 2005 21:00:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I8kUvrKzepSFHDgseMg2304djPTIyxHp5AsH2Dm1q8KGbIxQxX27Qt2aaqGIBVutAcYgsGLSaI7On4e15kQ7FuFUXCVaXRNbyNBK9/2d1XN/RTXiLzaWGUjOvny+O3HIp5VhlsoK85XDnSYOF1m031Qj5seJBTzScjHz/wS3FeE= Received: by 10.38.208.18 with SMTP id f18mr567298rng; Thu, 12 May 2005 21:00:09 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Thu, 12 May 2005 21:00:09 -0700 (PDT) Message-ID: <245f0df105051221002b33085a@mail.gmail.com> Date: Fri, 13 May 2005 14:00:09 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: Matt Piechota In-Reply-To: <245f0df105051218514285cc49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050512163806.98442.qmail@web20424.mail.yahoo.com> <20050512160348.J38870@acropolis.argolis.org> <245f0df105051218514285cc49@mail.gmail.com> cc: freebsd-security@freebsd.org Subject: Re: Do I have an infected init file? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 04:00:10 -0000 To Update on this, I did some quick checks for you, and now i ca give you a better runndown from an administrators p.o.v :: www.rootkit.nl/ this has helped me GREATLY thus far in removing 'kiddie pests' , although for an experienced unix malicious user, i assume it would maybe require more, however, i am against using such apps as F-prot 'secure' etc, that gives off the impression you are completely secure to the web, when infact,i could do many simple PoC in 5minnutes infront of any A/V company gladly,using public tools, and proove how easy it is to make an app hide from the actual scanner. Anyhow,the mentioned URL and file rkhunter,are not my property nor even had heard of them before I myself was compromised myself by an experienced unix kitter,however i am using the product and can definately say one thing,it will do alot more than pathetic a/v scanners made for profit.(Until im involved in making an a/v product, i will never back one) Now lets get to rootkit hunter config, I am going by the assumption that you coonfigure the apps conf file , to include MD5 hash checking, wich is one way most other rootkit revealing software is lacking,even this one by default is "off".I had turned mine on from day1 of usage. I have instaled v1.6.2, it keeps a regular .rkhunter.log in ~/. and its updater seems to operate fine with me on 3 machines tested today (Fri 13th May-2005) 5.2.1fBSD-Stable,5.3-fBSD-Stable,5.4-fBSD-RelENG. I see no reason not to use it, I am only offering additional advice with this on the MD5 checking section, and also, try perform tests using an older or un updated version, log it, then run it /rkhunter --update , rescan, you will surely find changes,well you will be a first if you do not. I have discovered on my sytsem,that even using the BSD Ports and pkg_add applications,i have been left with reports such as this,wich has left me extremely unhappy with the ports system,and/or handling of multiple packages,wich can pose as a potential major security risk (log details of what i mean exactly) :: - OpenSSL 0.9.7c [ Vulnerable = ] - OpenSSL 0.9.7e [ Unknown ] Now this is fromrunning rkhunter in simple mode, then updating, and finding i have previously 'unclean' and vulnerable parts still attached, sofar it has happeend with Bind and OpenSSH , OpenSSH was quite easy to adjust, although the OpenSSL is a completely new install, meaning that from when i Installed via CD to this system in particular (5.2.1), it automatically installed some features, now why were these not removed when they were updated by me manually in ports using updating, and making clean reinstalls,i do not understand. Especially to have comeup security advisories,(rkhunter runs a sec advisory checker,indeed handy),so should grab all BSD advisories and makesure you are NOT vuln to any,combined with the MD5 sig checking + most importantly now,an 'unkown' version of something, wich is the way most 'rootkits' seem to be injected. A vulnerability could not even ever showup in anything, if its say crafted specially,perhaps targetted at a specific sytem, and then patched up by an experienced 'rootkitter' (I know...what a great sounding job,"Hi im a r00tkitter!" but it may perhaps show a version of something you are no longer running, or have never infact ran, but was injected for usage after infection , (ie, a ttyshell or telnetD backdoor, or Bindshell), wich will then reveal somethng like Warning! otdated Bind8.0.2,Please check! , thus, you would know you do not run Bind,nor ever have, so it would atleast lead to the admin 'investigating'. Sample of what you would see, >>Your system contains some unknown version numbers. Please run Rootkit Hun= ter >>with the --update parameter etc. Ok well if anyone has ANY input or suggestions on anything I have said, like 'want evidence' etc, I have not a problem in supplying it, i wouldnt have joined this list otherwise. I just hope I am making people more aware that sometimes the simplest and oldest of tricks are re-used,and often those are the worst threats, but still a Vigilant admin who has some security morals (Ie: Updates theyre own server products), will always carry you through even the toughest of times. In regards to Linux and BSD 'hacking' and rootkitting I found while again doing research on a backdoor found on a SuSe box,simply by using very clear and specific targets in my searches,ie- i target a name,so if i get told THC rootkit,i will enter thc+rootkit+release (or download often works). It brought me across this, wich shows some products I have proof of being used in current 'kits' -> http://www.s0ftpj.org/en/tools.html This scared me when i looked, and still is, as i have discovered alot of sections of the code being written, is involved in recent property and email,even IP Hijack-massmail crime. I only wish i had the power to Investigate the people and online activities more,my resources are extremely limited,my donators are companies and isps, but they do not offer actual cash :) I try what i can and when something "p**es me off" , like having to wipe 4000000 emails due to firewall blocking them in (due to bodgy,kiddy-kits),i think i have good reason. I just hope Im reaching you guys, security is a really tough area for many people to comprehend exactly how deep the problem is now that it involves making money. -Sorry for such a large post,I will pre-comment on that: "Writing text needs time,writing short and easy to understand text needs more time". -inspired by a freebsd current researcher :-) -A quote on what you may find in your OWN searching: "You can have a handgun to protect yourself,or use it to rob a bank". -who knows but true! Regards, Drew B. On 5/13/05, Drew B. [Security Expertise/Freelance Security research]. wrote: > Hello, > I have used rootkit-hunter for Bsd, it can download MD5sums from > whitehat which contains 'current' sigs, not that this matters, it only > takes a good packagee,(ie file is encrypted, to bypass any rootkit > revealer etc) > However i do recommend rootkit-hunter, http://www.rootkit.nl ,it just > runs when needed, (/rkhunter -c, /rkhunter --update), and it does a > VERY thorough job, I recommend runing it without update forst,then > update it, you will no doubt find some multiple package installs, wich > seems to be a major problem with this, older package info staying in > root,after package is updated. > Hope this info is of any help, i can provide a detailed log of a > rootkithunter.log..just ask me to attach a copy. > Regards, > Drew B. >=20 > On 5/13/05, Matt Piechota wrote: > > On Thu, 12 May 2005, DH wrote: > > > > > I'm running a FreeBSD 4.10-release-p2 box and both chkrootkit 0.44 & > > > 0.45 report that my /sbin/init file is infected. > > > > I should mention that 4.10-release is up to p13. You should really thi= nk > > about patching up to current. > > > > > It appears as though the egrep for "UPX" in the output of "strings" > > > triggers the infected notice. When I copy the init file from an > > > uninfected box to this one chkrootkit continues to report it as > > > infected. Is chkrootkit reading a copy of the /sbin/init file stored = in > > > active memory? If my machine is compromised, which rootkit is install= ed > > > / how can I find out which rootkit is installed? > > > > The easiest way to figure out if you are rooted is probably to download= or > > create a clean version of /sbin/init, and compare the two files. > > Creating might take some work, you'd have to install a clean 4.10, patc= h > > it to p2, and make world. > > > > -- > > Matt Piechota > > Key Available from pgp.mit.edu > > PGP Key fingerprint =3D FC90 4D65 2F8A 38E9 D1A8 FABB 7AE8 C194 5EC8 9= CAD > > _______________________________________________ > > freebsd-security@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-security > > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.= org" > > >=20 > -- > ------------------------------------------ > Drew B. > /* Security researcher/expert,threat-focus,Freelance */ > ------------------------------------------ >=20 --=20 ------------------------------------------ Drew B. /* Security researcher/expert,threat-focus,Freelance */ ------------------------------------------ From owner-freebsd-security@FreeBSD.ORG Fri May 13 06:03:10 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E392716A4CE for ; Fri, 13 May 2005 06:03:10 +0000 (GMT) Received: from h2.prohosting.com.ua (h2.prohosting.com.ua [217.16.18.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DD7043D1D for ; Fri, 13 May 2005 06:03:10 +0000 (GMT) (envelope-from news@625.ru) Received: from [194.84.94.11] (helo=[192.168.5.24]) by h2.prohosting.com.ua with esmtpa (Exim 4.50 (FreeBSD)) id 1DWTGN-000PwY-AK for freebsd-security@freebsd.org; Fri, 13 May 2005 10:03:09 +0400 Date: Fri, 13 May 2005 10:02:45 +0400 From: "Danil V. Gerun" Organization: =?Windows-1251?Q?=CC=D3=CF_=E3=2E_=D1=EE=F7=E8_=22=C2=EE=E4=EE=EA=E0=ED?= =?Windows-1251?Q?=E0=EB=22_/_Water_Supply_and_Water_Treatment_Municipal?= =?Windows-1251?Q?_Unitary_Undertaking_of_city_Sochi?= X-Priority: 3 (Normal) Message-ID: <1682287017.20050513100245@625.ru> To: freebsd-security@freebsd.org In-Reply-To: <20050511205723.48284.qmail@web41210.mail.yahoo.com> References: 6667 <20050511205723.48284.qmail@web41210.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - h2.prohosting.com.ua X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - 625.ru X-Source: X-Source-Args: X-Source-Dir: Subject: Re[2]: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Danil V. Gerun" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 06:03:11 -0000 Hello. Another possible solution came to my mind this morning :) ICMP doesn't have ports like TCP and UDP do, but it does have the contents of the ICMP packets ;) What if the contents of the ICMP Echo Request, sent by the gateway to the Internet, is for example equal to: SHA1 ( original private src_ip + some (constant) garbage ) It can be used like a NAT "port-table" by a "special" ping utility: the real "private" sender gets all expected ICMP Replies. Such ping utility might be found or created. It would work with natd or with Netgraph (or with both :) ). AW> I would guess, that ICMP packets do not have a port number (just a AW> request/response id), so that the NAT cannot distinguish multiple AW> ICMP packet sources (I mean: The response from the ICMP requestee AW> cannot be mapped back to the appropriate ICMP requester). AW> Hmm... I just think, that (if you have multiple ICMP requestees) AW> the NAT could be able to map back the ICMP requester IP by the IP AW> of the ICMP requestee. But I do not know, how your router works... AW> Maybe your computer-pool could elect an ICMP-master, who AW> coordinates all the ICMP traffic through the NAT. AW> Bye AW> Arne -- Best regards, Danil V. Gerun. From owner-freebsd-security@FreeBSD.ORG Fri May 13 06:35:18 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5237B16A4CE for ; Fri, 13 May 2005 06:35:18 +0000 (GMT) Received: from mail.duth.gr (mail.duth.gr [192.108.114.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED9E43D3F for ; Fri, 13 May 2005 06:35:17 +0000 (GMT) (envelope-from bigbrother@bonbon.net) Received: from bigb3server.ath.cx (b9-29.xan.duth.gr [193.92.211.29]) by mail.duth.gr (8.13.1/8.13.1) with ESMTP id j4D6ZA9m030432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 09:35:15 +0300 (EEST) (envelope-from bigbrother@bonbon.net) Received: from bigb3server.bbcluster.gr (localhost [127.0.0.1]) by bigb3server.ath.cx (8.13.1/8.13.1) with ESMTP id j4D6X8mC087312 for ; Fri, 13 May 2005 09:33:08 +0300 (EEST) (envelope-from bigbrother@bonbon.net) Received: from localhost (bigbrother@localhost)j4D6X8Au087309 for ; Fri, 13 May 2005 09:33:08 +0300 (EEST) (envelope-from bigbrother@bonbon.net) X-Authentication-Warning: bigb3server.bbcluster.gr: bigbrother owned process doing -bs Date: Fri, 13 May 2005 09:33:08 +0300 (EEST) From: BigBrother-{BigB3} Cc: freebsd-security@freebsd.org In-Reply-To: <1682287017.20050513100245@625.ru> Message-ID: <20050513092907.J73276@bigb3server.bbcluster.gr> References: 6667 <20050511205723.48284.qmail@web41210.mail.yahoo.com> <1682287017.20050513100245@625.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.51 on 192.108.114.110 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (mail.duth.gr [192.108.114.110]); Fri, 13 May 2005 09:35:15 +0300 (EEST) X-Mailman-Approved-At: Fri, 13 May 2005 13:05:03 +0000 Subject: Re[2]: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 06:35:18 -0000 On Fri, 13 May 2005, Danil V. Gerun wrote: > > AW> I would guess, that ICMP packets do not have a port number (just a > AW> request/response id), so that the NAT cannot distinguish multiple > AW> ICMP packet sources (I mean: The response from the ICMP requestee > AW> cannot be mapped back to the appropriate ICMP requester). > > AW> Hmm... I just think, that (if you have multiple ICMP requestees) > AW> the NAT could be able to map back the ICMP requester IP by the IP > AW> of the ICMP requestee. But I do not know, how your router works... > > AW> Maybe your computer-pool could elect an ICMP-master, who > AW> coordinates all the ICMP traffic through the NAT. > > AW> Bye > AW> Arne > > In my NATED (ipfw+natd) lan EVERY internal host (192.168.XX) can ping simultaneously any external host and ALL getting their proper ICMP replies. If you have a straightforward setup you wont have any problems. Just try a simple test...Run ipfw with one divert rule only, and the "natd" application and see what happens if you ping. I think that you are using some limiters in your ipfw rules. Rgz, BB --- Dreams have no limits! From owner-freebsd-security@FreeBSD.ORG Fri May 13 13:26:07 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DDF116A4CE for ; Fri, 13 May 2005 13:26:07 +0000 (GMT) Received: from h2.prohosting.com.ua (h2.prohosting.com.ua [217.16.18.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E6C843D81 for ; Fri, 13 May 2005 13:26:06 +0000 (GMT) (envelope-from news@625.ru) Received: from [194.84.94.11] (helo=[192.168.5.24]) by h2.prohosting.com.ua with esmtpa (Exim 4.50 (FreeBSD)) id 1DWaB2-0001Sy-EB for freebsd-security@freebsd.org; Fri, 13 May 2005 17:26:04 +0400 Date: Fri, 13 May 2005 17:25:59 +0400 From: "Danil V. Gerun" Organization: =?Windows-1251?Q?=CC=D3=CF_=E3=2E_=D1=EE=F7=E8_=22=C2=EE=E4=EE=EA=E0=ED?= =?Windows-1251?Q?=E0=EB=22_/_Water_Supply_and_Water_Treatment_Municipal?= =?Windows-1251?Q?_Unitary_Undertaking_of_city_Sochi?= X-Priority: 3 (Normal) Message-ID: <1121231288.20050513172559@625.ru> To: freebsd-security@freebsd.org In-Reply-To: <20050513092907.J73276@bigb3server.bbcluster.gr> References: 6667 <20050511205723.48284.qmail@web41210.mail.yahoo.com> <1682287017.20050513100245@625.ru> <20050513092907.J73276@bigb3server.bbcluster.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=Windows-1251 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - h2.prohosting.com.ua X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - 625.ru X-Source: X-Source-Args: X-Source-Dir: Subject: Re[3]: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Danil V. Gerun" List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 13:26:07 -0000 BB> In my NATED (ipfw+natd) lan EVERY internal host (192.168.XX) can ping BB> simultaneously any external host and ALL getting their proper ICMP BB> replies. Well, I didn't configure "ICMP NAT" for my LAN, but I'm just wondering: what if _some_ internal hosts start pinging one external host? Is each of them going to recieve all the icmp replies?.. -- Best regards, Danil V. Gerun danil@hate.spam.625.ru From owner-freebsd-security@FreeBSD.ORG Fri May 13 15:25:01 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72AC216A4CE; Fri, 13 May 2005 15:25:01 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2713B43D7C; Fri, 13 May 2005 15:25:01 +0000 (GMT) (envelope-from security-advisories@freebsd.org) Received: from freefall.freebsd.org (nectar@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4DFP1Ja029322; Fri, 13 May 2005 15:25:01 GMT (envelope-from security-advisories@freebsd.org) Received: (from nectar@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4DFP1h7029320; Fri, 13 May 2005 15:25:01 GMT (envelope-from security-advisories@freebsd.org) Date: Fri, 13 May 2005 15:25:01 GMT Message-Id: <200505131525.j4DFP1h7029320@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: nectar set sender to security-advisories@freebsd.org using -f From: FreeBSD Security Advisories To: FreeBSD Security Advisories Precedence: bulk Subject: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Reply-To: security-advisories@freebsd.org List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 15:25:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ============================================================================= FreeBSD-SA-05:09.htt Security Advisory The FreeBSD Project Topic: information disclosure when using HTT Category: core Module: sys Announced: 2005-05-13 Revised: 2005-05-13 Credits: Colin Percival Affects: All FreeBSD/i386 and FreeBSD/amd64 releases. Corrected: 2005-05-13 00:13:00 UTC (RELENG_5, 5.4-STABLE) 2005-05-13 00:13:00 UTC (RELENG_5_4, 5.4-RELEASE-p1) 2005-05-13 00:13:00 UTC (RELENG_5_3, 5.3-RELEASE-p15) 2005-05-13 00:13:00 UTC (RELENG_4, 4.11-STABLE) 2005-05-13 00:13:00 UTC (RELENG_4_11, 4.11-RELEASE-p9) 2005-05-13 00:13:00 UTC (RELENG_4_10, 4.10-RELEASE-p14) CVE Name: CAN-2005-0109 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . 0. Revision History v1.0 2005-05-13 Initial release. v1.1 2005-05-13 Additional details. I. Background Sharing the execution resources of a superscalar processor between multiple execution threads is referred to as "simultaneous multithreading". "Hyper-Threading Technology" or HTT is the name used for the implementation of simultaneous multithreading on Intel Pentium 4, Mobile Pentium 4, and Xeon processors. HTT involves sharing certain CPU resources between multiple threads, including memory caches. FreeBSD supports HTT when using a kernel compiled with the SMP option. II. Problem Description When running on processors supporting Hyper-Threading Technology, it is possible for a malicious thread to monitor the execution of another thread. NOTE: Similar problems may exist in other simultaneous multithreading implementations, or even some systems in the absence of simultaneous multithreading. However, current research has only demonstrated this flaw in Hyper-Threading Technology, where shared memory caches are used. III. Impact Information may be disclosed to local users, allowing in many cases for privilege escalation. For example, on a multi-user system, it may be possible to steal cryptographic keys used in applications such as OpenSSH or SSL-enabled web servers. IV. Workaround Systems not using processors with Hyper-Threading Technology support are not affected by this issue. On systems which are affected, the security flaw can be eliminated by setting the "machdep.hlt_logical_cpus" tunable: # echo "machdep.hlt_logical_cpus=1" >> /boot/loader.conf The system must be rebooted in order for tunables to take effect. Use of this workaround is not recommended on "dual-core" systems, as this workaround will also disable one of the processor cores. V. Solution Disable Hyper-Threading Technology on processors that support it. NOTE: It is expected that future work in cryptographic libraries and operating system schedulers may remedy this problem for many or most users, without necessitating the disabling of Hyper-Threading Technology. Future advisories will address individual cases. Perform one of the following: 1) Upgrade your vulnerable system to 4-STABLE or 5-STABLE, or to the RELENG_5_4, RELENG_5_3, RELENG_4_11, or RELENG_4_10 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 4.10, 4.11, 5.3, and 5.4 systems. a) Download the relevant patch from the location below and verify the detached PGP signature using your PGP utility. [FreeBSD 4.10] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt410.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt410.patch.asc [FreeBSD 4.11] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt411.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt411.patch.asc [FreeBSD 5.x] # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch # fetch ftp://ftp.FreeBSD.org/pub/FreeBSD/CERT/patches/SA-05:09/htt5.patch.asc b) Apply the patch. # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. NOTE: For users that are certain that their environment is not affected by this vulnerability, such as single-user systems, Hyper-Threading Technology may be re-enabled by setting the tunable "machdep.hyperthreading_allowed". VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - ------------------------------------------------------------------------- RELENG_4 src/sys/i386/i386/mp_machdep.c 1.115.2.23 src/sys/i386/include/cpufunc.h 1.96.2.4 RELENG_4_11 src/UPDATING 1.73.2.91.2.10 src/sys/conf/newvers.sh 1.44.2.39.2.13 src/sys/i386/i386/mp_machdep.c 1.115.2.22.2.1 src/sys/i386/include/cpufunc.h 1.96.2.3.12.1 RELENG_4_10 src/UPDATING 1.73.2.90.2.15 src/sys/conf/newvers.sh 1.44.2.34.2.16 src/sys/i386/i386/mp_machdep.c 1.115.2.20.2.1 src/sys/i386/include/cpufunc.h 1.96.2.3.10.1 RELENG_5 src/sys/amd64/amd64/mp_machdep.c 1.242.2.11 src/sys/amd64/include/cpufunc.h 1.145.2.1 src/sys/i386/i386/mp_machdep.c 1.235.2.10 src/sys/i386/include/cpufunc.h 1.142.2.1 RELENG_5_4 src/UPDATING 1.342.2.24.2.10 src/sys/amd64/amd64/mp_machdep.c 1.242.2.7.2.4 src/sys/amd64/include/cpufunc.h 1.145.6.1 src/sys/conf/newvers.sh 1.62.2.18.2.6 src/sys/i386/i386/mp_machdep.c 1.235.2.6.2.3 src/sys/i386/include/cpufunc.h 1.142.6.1 RELENG_5_3 src/UPDATING 1.342.2.13.2.18 src/sys/amd64/amd64/mp_machdep.c 1.242.2.2.2.2 src/sys/amd64/include/cpufunc.h 1.145.4.1 src/sys/conf/newvers.sh 1.62.2.15.2.20 src/sys/i386/i386/mp_machdep.c 1.235.2.3.2.2 src/sys/i386/include/cpufunc.h 1.142.4.1 - ------------------------------------------------------------------------- VII. References http://www.daemonology.net/hyperthreading-considered-harmful/ The latest revision of this advisory is available at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:09.htt.asc -----BEGIN PGP SIGNATURE----- iD8DBQFChJA4FdaIBMps37IRAo8nAJ9w7xtIF0atnxiKDhFOpBXEZQDtZQCghWdM qc5lGST7l+iJEYN/7zTNUPY= =WqEa -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Fri May 13 16:11:01 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A315816A4CE for ; Fri, 13 May 2005 16:11:01 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528B143D7D for ; Fri, 13 May 2005 16:11:01 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j4DG7EwE032923 for ; Fri, 13 May 2005 12:07:14 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j4DG7E9W032922 for freebsd-security@FreeBSD.ORG; Fri, 13 May 2005 12:07:14 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Fri, 13 May 2005 12:07:14 -0400 From: David Schultz To: freebsd-security@FreeBSD.ORG Message-ID: <20050513160714.GB32677@VARK.MIT.EDU> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <200505131525.j4DFP1h7029320@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505131525.j4DFP1h7029320@freefall.freebsd.org> Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 16:11:01 -0000 On Fri, May 13, 2005, FreeBSD Security Advisories wrote: > II. Problem Description > > When running on processors supporting Hyper-Threading Technology, it is > possible for a malicious thread to monitor the execution of another > thread. > > NOTE: Similar problems may exist in other simultaneous multithreading > implementations, or even some systems in the absence of simultaneous > multithreading. However, current research has only demonstrated this > flaw in Hyper-Threading Technology, where shared memory caches are used. But isn't this a well-known and fundamental problem with SMT? Someone at Sun pointed out a similar attack to me in 2003; it turns out that it's possible for a thread to monitor which of the processor's functional units another thread is using. For instance, you can sample the number of shifts vs. adds vs. multiplies and use this information to mount a differential timing attack. Also, recent work [1] shows that programs with key-dependent cache behavior can be attacked even without SMT. So this sounds like trying to solve in the OS a problem that can only be solved in the application. Is there something more subtle that's going on? P.S. I'm getting on a plane in a few hours, and I may be unable to respond for a few days. [1] http://cr.yp.to/antiforgery/cachetiming-20050414.pdf From owner-freebsd-security@FreeBSD.ORG Fri May 13 16:15:04 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BF6B16A4CE; Fri, 13 May 2005 16:15:04 +0000 (GMT) Received: from lists.soekris.com (lists.soekris.com [64.105.92.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id B196943D78; Fri, 13 May 2005 16:15:03 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by lists.soekris.com (8.12.11/8.12.11) with ESMTP id j4DGFHbf044995; Fri, 13 May 2005 09:15:18 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) To: David Schultz From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 May 2005 12:07:14 EDT." <20050513160714.GB32677@VARK.MIT.EDU> Date: Fri, 13 May 2005 18:15:02 +0200 Message-ID: <63567.1116000902@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 16:15:04 -0000 In message <20050513160714.GB32677@VARK.MIT.EDU>, David Schultz writes: >But isn't this a well-known and fundamental problem with SMT? Yes. The news being only the speed: you can get 300 bits of the 512 bit RSA key in a single observation of a single shot run of the crypto. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Sat May 14 01:56:32 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EABEF16A4CE for ; Sat, 14 May 2005 01:56:31 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83B2943D95 for ; Sat, 14 May 2005 01:56:30 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so287224rne for ; Fri, 13 May 2005 18:56:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oncwFzJXTWp2L0aLuKJ0oEwQVpfyDckfjHPZGcLWFOdv3VunZDKIsPqF7dCguerJoM/W/l9+Q/TcP/JmZAFj4VQLEc1DJEqrxoO8jHJgVZDnILjkSM2p0hBAhZ3E4YlAIcSgeI/XRD1e9vF7nUwDY3BRBJnksFWXzbQDpyOlA6Y= Received: by 10.38.97.15 with SMTP id u15mr1144997rnb; Fri, 13 May 2005 18:56:30 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Fri, 13 May 2005 18:56:30 -0700 (PDT) Message-ID: <245f0df105051318564b1ffb6b@mail.gmail.com> Date: Sat, 14 May 2005 11:56:30 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: das@freebsd.org In-Reply-To: <63567.1116000902@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050513160714.GB32677@VARK.MIT.EDU> <63567.1116000902@critter.freebsd.dk> cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 01:56:32 -0000 So this sounds like trying to solve in the OS a problem that can only be solved in the application. Is there something more subtle that's going on? -> This is a strange but interesting problem, if indeed the SMT is not 'needed' , then perhaps there is something more malicious in the code, (Internally), wich may need more corrections and addressing directly,the FreeBSD team I am sure will know what todo,Im merely suggesting a method. I cannot see an immediate threat,but wouldnt looking into the source code abit more perhaps and see whats going on,and also perhaps some more specifics from that SunOS test would be useful,some info so that the actual multiple memory cache problem itself could be addressed on its own to begin with,localise the problem perhaps, then dissect? Anyhow just a suggestion, It is not really my area so i should poke my nose out now :) Regards, Drew B. On 5/14/05, Poul-Henning Kamp wrote: > In message <20050513160714.GB32677@VARK.MIT.EDU>, David Schultz writes: >=20 > >But isn't this a well-known and fundamental problem with SMT? >=20 > Yes. >=20 > The news being only the speed: you can get 300 bits of the 512 bit > RSA key in a single observation of a single shot run of the crypto. >=20 > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >=20 --=20 -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance. From owner-freebsd-security@FreeBSD.ORG Sat May 14 02:20:24 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AADF416A4CE; Sat, 14 May 2005 02:20:23 +0000 (GMT) Received: from lists.soekris.com (lists.soekris.com [64.105.92.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCED543D7F; Sat, 14 May 2005 02:20:20 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by lists.soekris.com (8.12.11/8.12.11) with ESMTP id j4E2Ka1Y047755; Fri, 13 May 2005 19:20:37 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) To: "Drew B. [Security Expertise/Freelance Security research]." From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 14 May 2005 11:56:30 +1000." <245f0df105051318564b1ffb6b@mail.gmail.com> Date: Sat, 14 May 2005 04:20:19 +0200 Message-ID: <94145.1116037219@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-security@freebsd.org cc: das@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 02:20:24 -0000 In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Security Expe rtise/Freelance Security research]." writes: >this sounds like trying to solve in the OS a problem that can only >be solved in the application. Is there something more subtle >that's going on? Well, the application could theoretically do something and Colin advocated it this morning: make the crypto code footprint data and key independent. While possible, it is both very tricky to do (in particular in highlevel languages) and generally found to be much slower than speed-optimized code. And while that could solve the immediate panic with OpenSSL and similar, it does not solve the general problem that you can spy very efficiently on the behaviour of another program. The fact that one user would be able to spy on another users editor application and be able to extract for instance the word lengths and layout of a document would also be considered a major security problem in many installations. Or how about just being able to monitor another customers apache instance to figure out how much traffic they get and which pages they get it on ? The fundamental trouble is that HTT makes the spying far more efficient than it is with SMP or even UP (I think we are talking in the order of a million times more efficient). That takes the attack from the "if you were really lucky" to the "almost always in first try" category. The correct (technical) workaround (IMO) is to restrict HTT to be used only for threads from the same process. The political problem is that if all operating systems do that, Intel has a pretty dud feature on their hands, and they are not particularly eager to accept that fact. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Sat May 14 05:35:03 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7226416A4CE for ; Sat, 14 May 2005 05:35:03 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 163A943D82 for ; Sat, 14 May 2005 05:35:03 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so299386rne for ; Fri, 13 May 2005 22:35:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VtP5ICypu2/O4rSddww9r/lZ6QmsaPa4HVUYHZs18e165MOkWkgpS9UBW4QvV1L4OBp7MTE+00BBUzB3FA6L4EDj3vkBeT3K4rgB1cAs3N6ucrpWEHv8PDCOv5riDhUq3OdgnYYODlwjEpbqGhoUUkWBe2UuAz7ZN8vRGKrYJTY= Received: by 10.38.104.2 with SMTP id b2mr1211281rnc; Fri, 13 May 2005 22:35:02 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Fri, 13 May 2005 22:35:02 -0700 (PDT) Message-ID: <245f0df105051322354e8e86eb@mail.gmail.com> Date: Sat, 14 May 2005 15:35:02 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: Poul-Henning Kamp In-Reply-To: <94145.1116037219@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> cc: freebsd-security@freebsd.org Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 05:35:03 -0000 The political problem is that if all operating systems do that, Intel has a pretty dud feature on their hands, and they are not particularly eager to accept that fact. Hehehe... I cannot help but giigle abit, I didnt think this went that deep :o , definately interesting stuff regarding the future of HT and O/S Types,ty even though the answer may help someone else more, Regards, Drew B. (Enlightening myself to inspire others is my answer to everything *No-Comme= nt*) On 5/14/05, Poul-Henning Kamp wrote: > In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Securit= y Expe > rtise/Freelance Security research]." writes: >=20 > >this sounds like trying to solve in the OS a problem that can only > >be solved in the application. Is there something more subtle > >that's going on? >=20 > Well, the application could theoretically do something and Colin > advocated it this morning: make the crypto code footprint data > and key independent. While possible, it is both very tricky to > do (in particular in highlevel languages) and generally found > to be much slower than speed-optimized code. >=20 > And while that could solve the immediate panic with OpenSSL and > similar, it does not solve the general problem that you can spy > very efficiently on the behaviour of another program. >=20 > The fact that one user would be able to spy on another users editor > application and be able to extract for instance the word lengths > and layout of a document would also be considered a major security > problem in many installations. >=20 > Or how about just being able to monitor another customers apache > instance to figure out how much traffic they get and which pages > they get it on ? >=20 > The fundamental trouble is that HTT makes the spying far more > efficient than it is with SMP or even UP (I think we are talking > in the order of a million times more efficient). >=20 > That takes the attack from the "if you were really lucky" to the > "almost always in first try" category. >=20 > The correct (technical) workaround (IMO) is to restrict HTT to be > used only for threads from the same process. >=20 > The political problem is that if all operating systems do that, > Intel has a pretty dud feature on their hands, and they are not > particularly eager to accept that fact. >=20 > Poul-Henning >=20 > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetenc= e. >=20 --=20 -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance. From owner-freebsd-security@FreeBSD.ORG Sat May 14 07:06:31 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 57A0916A4CE for ; Sat, 14 May 2005 07:06:31 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1ED643D81 for ; Sat, 14 May 2005 07:06:30 +0000 (GMT) (envelope-from chrcoluk@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so497540rng for ; Sat, 14 May 2005 00:06:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WNmm+xin3HHzOo+Le4J/yU0u/vZ0akiuqKRvDN/sCwwaltCTY2Lm/3BrkFcM97ZvkHz/B7XIHInXWKT3IWh/BYjw4On8YIyJ+glzFc4jbFCzP85lg89Q8e0X2IuKiIPEbGlNRQWvD98Z5TJkb1xiq81H3tGhHQl08F1wUULevcA= Received: by 10.38.71.27 with SMTP id t27mr1856768rna; Sat, 14 May 2005 00:06:30 -0700 (PDT) Received: by 10.39.1.30 with HTTP; Sat, 14 May 2005 00:06:30 -0700 (PDT) Message-ID: <3aaaa3a050514000629cc8427@mail.gmail.com> Date: Sat, 14 May 2005 08:06:30 +0100 From: Chris To: "Drew B. [Security Expertise/Freelance Security research]." In-Reply-To: <245f0df105051322354e8e86eb@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> <245f0df105051322354e8e86eb@mail.gmail.com> cc: freebsd-security@freebsd.org cc: Poul-Henning Kamp Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Chris List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 07:06:31 -0000 I am somewhat confused by applying the patch, does this disable HTT functionality? or does a patched server close the issue and keep HTT enabled? Chris On 5/14/05, Drew B. [Security Expertise/Freelance Security research]. wrote: > The political problem is that if all operating systems do that, > Intel has a pretty dud feature on their hands, and they are not > particularly eager to accept that fact. >=20 > Hehehe... I cannot help but giigle abit, I didnt think this went that > deep :o , definately interesting stuff regarding the future of HT and > O/S Types,ty even though the answer may help someone else more, > Regards, > Drew B. >=20 > (Enlightening myself to inspire others is my answer to everything *No-Com= ment*) >=20 >=20 > On 5/14/05, Poul-Henning Kamp wrote: > > In message <245f0df105051318564b1ffb6b@mail.gmail.com>, "Drew B. [Secur= ity Expe > > rtise/Freelance Security research]." writes: > > > > >this sounds like trying to solve in the OS a problem that can only > > >be solved in the application. Is there something more subtle > > >that's going on? > > > > Well, the application could theoretically do something and Colin > > advocated it this morning: make the crypto code footprint data > > and key independent. While possible, it is both very tricky to > > do (in particular in highlevel languages) and generally found > > to be much slower than speed-optimized code. > > > > And while that could solve the immediate panic with OpenSSL and > > similar, it does not solve the general problem that you can spy > > very efficiently on the behaviour of another program. > > > > The fact that one user would be able to spy on another users editor > > application and be able to extract for instance the word lengths > > and layout of a document would also be considered a major security > > problem in many installations. > > > > Or how about just being able to monitor another customers apache > > instance to figure out how much traffic they get and which pages > > they get it on ? > > > > The fundamental trouble is that HTT makes the spying far more > > efficient than it is with SMP or even UP (I think we are talking > > in the order of a million times more efficient). > > > > That takes the attack from the "if you were really lucky" to the > > "almost always in first try" category. > > > > The correct (technical) workaround (IMO) is to restrict HTT to be > > used only for threads from the same process. > > > > The political problem is that if all operating systems do that, > > Intel has a pretty dud feature on their hands, and they are not > > particularly eager to accept that fact. > > > > Poul-Henning > > > > -- > > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > > phk@FreeBSD.ORG | TCP/IP since RFC 956 > > FreeBSD committer | BSD since 4.3-tahoe > > Never attribute to malice what can adequately be explained by incompete= nce. > > >=20 > -- > -------------------------------------------------------------------- > Drew B. > Independant Security analysis,for Aussies. > Security researcher/expert,threat-focus,Freelance. > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" > From owner-freebsd-security@FreeBSD.ORG Sat May 14 07:15:00 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8340116A4CE for ; Sat, 14 May 2005 07:15:00 +0000 (GMT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4009743D7E for ; Sat, 14 May 2005 07:15:00 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr6so.prod.shaw.ca (pd3mr6so-qfe3.prod.shaw.ca [10.0.141.21])2004))freebsd-security@freebsd.org; Sat, 14 May 2005 01:14:52 -0600 (MDT) Received: from pn2ml6so.prod.shaw.ca ([10.0.121.150]) by pd3mr6so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGG00I1YXGS0RG0@pd3mr6so.prod.shaw.ca> for freebsd-security@freebsd.org; Sat, 14 May 2005 01:14:52 -0600 (MDT) Received: from [127.0.0.1] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) 2003))freebsd-security@freebsd.org; Sat, 14 May 2005 01:14:52 -0600 (MDT) Date: Sat, 14 May 2005 03:14:50 -0400 From: Colin Percival In-reply-to: <3aaaa3a050514000629cc8427@mail.gmail.com> To: Chris Message-id: <4285A56A.1030106@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> <245f0df105051322354e8e86eb@mail.gmail.com> <3aaaa3a050514000629cc8427@mail.gmail.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-security@freebsd.org cc: Poul-Henning Kamp cc: "Drew B. \[Security Expertise/Freelance Security research\]." Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 07:15:00 -0000 Chris wrote: > I am somewhat confused by applying the patch, does this disable HTT > functionality? or does a patched server close the issue and keep HTT > enabled? The patch adds a new loader tunable, machdep.hyperthreading_allowed, which is set to 0 by default. Regardless of how you try to set the machdep.hlt_cpus_mask and machdep.hlt_logical_cpus sysctls, if machdep.hyperthreading_allowed is set to zero then you will not have any process threads executing on the second hyper-thread from each core. If you're on a system where this isn't a problem (e.g., anything with no local users), you can set machdep.hyperthreading_allowed=1 in /boot/loader.conf or via the sysctl after booting, and get the benefit of hyperthreading. Colin Percival From owner-freebsd-security@FreeBSD.ORG Sat May 14 11:17:23 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2B2816A4CE for ; Sat, 14 May 2005 11:17:23 +0000 (GMT) Received: from lists.soekris.com (lists.soekris.com [64.105.92.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DC843D41 for ; Sat, 14 May 2005 11:17:23 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by lists.soekris.com (8.12.11/8.12.11) with ESMTP id j4EBHcAs049263; Sat, 14 May 2005 04:17:39 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) To: Garrett Wollman From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 13 May 2005 22:33:30 EDT." <17029.25466.587442.577866@khavrinen.csail.mit.edu> Date: Sat, 14 May 2005 13:17:19 +0200 Message-ID: <94462.1116069439@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 11:17:23 -0000 In message <17029.25466.587442.577866@khavrinen.csail.mit.edu>, Garrett Wollman writes: >< said: > >> The political problem is that if all operating systems do that, >> Intel has a pretty dud feature on their hands, and they are not >> particularly eager to accept that fact. > >Intel already had a pretty dud feature on their hands; just ask anyone >in the architecture community (probably including those who work for >Intel). While quite likely true, that is not really the issue here. The question is what it will take to make Intel warn their customers. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Sat May 14 11:18:28 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1454316A4CE for ; Sat, 14 May 2005 11:18:28 +0000 (GMT) Received: from lists.soekris.com (lists.soekris.com [64.105.92.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id D03F943D3F for ; Sat, 14 May 2005 11:18:27 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by lists.soekris.com (8.12.11/8.12.11) with ESMTP id j4EBIjpb049266; Sat, 14 May 2005 04:18:46 -0700 (PDT) (envelope-from phk@critter.freebsd.dk) To: Chris From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 14 May 2005 08:06:30 BST." <3aaaa3a050514000629cc8427@mail.gmail.com> Date: Sat, 14 May 2005 13:18:26 +0200 Message-ID: <94533.1116069506@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-security@freebsd.org cc: "Drew B. \[Security Expertise/Freelance Security research\]." Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 11:18:28 -0000 In message <3aaaa3a050514000629cc8427@mail.gmail.com>, Chris writes: >I am somewhat confused by applying the patch, does this disable HTT >functionality? or does a patched server close the issue and keep HTT >enabled? It disabled HTT functionality. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-security@FreeBSD.ORG Fri May 13 15:54:55 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FFFB16A4CE for ; Fri, 13 May 2005 15:54:55 +0000 (GMT) Received: from web53302.mail.yahoo.com (web53302.mail.yahoo.com [206.190.39.231]) by mx1.FreeBSD.org (Postfix) with SMTP id D06B543D66 for ; Fri, 13 May 2005 15:54:54 +0000 (GMT) (envelope-from non_secure@yahoo.com) Received: (qmail 63843 invoked by uid 60001); 13 May 2005 15:54:54 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=u7ErIMaC+Pfcs31P0MxGpVV1HYwHpythIsL5j2rtoCa0mP9+JQwL7o5Xy8vQWqowk9zdL/N/xvP9Yt8eui74E86JudJswx7tm7TpIkGhEBVwKHDliJxRUKjFA0gzX4urXcMGIAprhgpDEBTj6SyCaYmrgZwf6zvnJHQFin14kIc= ; Message-ID: <20050513155454.63841.qmail@web53302.mail.yahoo.com> Received: from [140.209.242.255] by web53302.mail.yahoo.com via HTTP; Fri, 13 May 2005 08:54:54 PDT Date: Fri, 13 May 2005 08:54:54 -0700 (PDT) From: Joe Schmoe To: freebsd-security@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 14 May 2005 12:46:32 +0000 Subject: different ways to disable https in apache... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 15:54:55 -0000 Hello, I built apache+openssl+mod_ssl. It is working fine, and I have been starting the server with: apachectl startssl Recently, however, I have decided that I will not be doing anything over https (for a while, at least) with this web server, so for security reasons, I want to only run on port 80. So now I start the server with: apachectl start And it runs without SSL. My question is, is starting the SSl enabled apache like this, and running it without SSL exactly the same security-wise as running a copy of apache without SSL at all ? That is, SSL libraries, etc., can have vulnerabilities in them, and am I still vulnerable to those problems even if I am running only on port 80 ? What kinds of attacks might I _not_ be insulating myself against by simply not running SSL, vs. reinstalling without it ? thanks, __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From owner-freebsd-security@FreeBSD.ORG Fri May 13 16:45:13 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 086FA16A4CE for ; Fri, 13 May 2005 16:45:13 +0000 (GMT) Received: from mail.duth.gr (mail.duth.gr [192.108.114.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C06843D70 for ; Fri, 13 May 2005 16:45:11 +0000 (GMT) (envelope-from bigbrother@bonbon.net) Received: from bigb3server.ath.cx (b9-29.xan.duth.gr [193.92.211.29]) by mail.duth.gr (8.13.1/8.13.1) with ESMTP id j4DGjAVA051210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 May 2005 19:45:10 +0300 (EEST) (envelope-from bigbrother@bonbon.net) Received: from bigb3server.bbcluster.gr (localhost [127.0.0.1]) by bigb3server.ath.cx (8.13.1/8.13.1) with ESMTP id j4DGhLuo093036 for ; Fri, 13 May 2005 19:43:21 +0300 (EEST) (envelope-from bigbrother@bonbon.net) Received: from localhost (bigbrother@localhost)j4DGhL8h093033 for ; Fri, 13 May 2005 19:43:21 +0300 (EEST) (envelope-from bigbrother@bonbon.net) X-Authentication-Warning: bigb3server.bbcluster.gr: bigbrother owned process doing -bs Date: Fri, 13 May 2005 19:43:21 +0300 (EEST) From: BigBrother-{BigB3} Cc: freebsd-security@freebsd.org In-Reply-To: <1121231288.20050513172559@625.ru> Message-ID: <20050513193813.W73276@bigb3server.bbcluster.gr> References: 6667 <20050511205723.48284.qmail@web41210.mail.yahoo.com> <20050513092907.J73276@bigb3server.bbcluster.gr> <1121231288.20050513172559@625.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.51 on 192.108.114.110 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (mail.duth.gr [192.108.114.110]); Fri, 13 May 2005 19:45:10 +0300 (EEST) X-Mailman-Approved-At: Sat, 14 May 2005 12:46:32 +0000 Subject: Re[3]: icmp problem X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2005 16:45:13 -0000 On Fri, 13 May 2005, Danil V. Gerun wrote: > BB> In my NATED (ipfw+natd) lan EVERY internal host (192.168.XX) can ping > BB> simultaneously any external host and ALL getting their proper ICMP > BB> replies. > > Well, I didn't configure "ICMP NAT" for my LAN, but I'm just > wondering: what if _some_ internal hosts start pinging one external > host? Is each of them going to recieve all the icmp replies?.. > > > As I told you If _some_ internal hosts start pinging one external host, everyone gets their proper answer. They are not going to receive all the icmp replies. Everyone receives his reply. Use natd -v to figure out Here is a snip: Out [ICMP] [ICMP] 192.168.???.130 -> 192.108.???.43 8(0) aliased to [ICMP] 193.92.???.26 -> 192.108.???.43 8(0) In [ICMP] [ICMP] 192.108.???.43 -> 193.92.???.26 0(0) aliased to [ICMP] 192.108.???.43 -> 192.168.???.130 0(0) Make some experiments with natd -v and you will understand this. --- Dreams have no limits! From owner-freebsd-security@FreeBSD.ORG Sat May 14 02:33:37 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8943D16A4CE for ; Sat, 14 May 2005 02:33:37 +0000 (GMT) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id E894D43D7E for ; Sat, 14 May 2005 02:33:36 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) j4E2XV3C018478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Fri, 13 May 2005 22:33:33 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j4E2XUWX018475; Fri, 13 May 2005 22:33:30 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17029.25466.587442.577866@khavrinen.csail.mit.edu> Date: Fri, 13 May 2005 22:33:30 -0400 To: "Poul-Henning Kamp" In-Reply-To: <94145.1116037219@critter.freebsd.dk> References: <245f0df105051318564b1ffb6b@mail.gmail.com> <94145.1116037219@critter.freebsd.dk> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Fri, 13 May 2005 22:33:33 -0400 (EDT) X-Virus-Scanned: ClamAV 0.84/876/Thu May 12 19:14:29 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Sat, 14 May 2005 12:46:32 +0000 cc: freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 02:33:37 -0000 < said: > The political problem is that if all operating systems do that, > Intel has a pretty dud feature on their hands, and they are not > particularly eager to accept that fact. Intel already had a pretty dud feature on their hands; just ask anyone in the architecture community (probably including those who work for Intel). Pentium 4 CPUs simply don't have enough I/O bandwidth to maintain two simultaneous, independent instruction streams. The value to the feature can't be realized until you have enough cache (in both size and bandwidth) to be able to partition it among logical CPUs in exactly the manner that Colin has suggested. (The fundamental problem in computer architecture for the past several years has been how to deal with the fact that gates are cheap and easy to make, but wires -- particularly external I/O wires -- are expensive and hard.) The only way to get full performance out of an HTT processor today is for both threads to be running out of L1 cache. Multimedia and numerical benchmarks are often parallelizable in this way (assuming the OS provides gang scheduling); general-purpose applications rarely are. -GAWollman From owner-freebsd-security@FreeBSD.ORG Sat May 14 13:07:08 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E486E16A4CE for ; Sat, 14 May 2005 13:07:07 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FBAD43D58 for ; Sat, 14 May 2005 13:07:07 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so323244rne for ; Sat, 14 May 2005 06:07:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eztdOWdNZpucCiNecrkkG1LtziO4zINYzQSjNfHAy2lzdgcTwdqHoZqIaV5b7GUQIcQzwbWD9QBQgc7ZMFxYZ82qO4v6aiEPV7OyiPIvq+Fnso3Fa9XmuMzeNFz12pvTOsurLvStOWx9LAX+ExuXY8I6Y5KB0uS5FhQ77sI4LI4= Received: by 10.39.2.21 with SMTP id e21mr1325654rni; Sat, 14 May 2005 06:07:06 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Sat, 14 May 2005 06:07:06 -0700 (PDT) Message-ID: <245f0df105051406074418cae@mail.gmail.com> Date: Sat, 14 May 2005 23:07:06 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: Joe Schmoe In-Reply-To: <20050513155454.63841.qmail@web53302.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050513155454.63841.qmail@web53302.mail.yahoo.com> cc: freebsd-security@freebsd.org Subject: Re: different ways to disable https in apache... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 13:07:08 -0000 What kinds of attacks might I _not_ be insulating myself against by simply not running SSL, vs. reinstalling without it ? A quick one; SSL as you know encrypts that link and makes it secure,hence the 'handshake' name so without this, you are opening your port 80 to any connection,that is bottom line. If you look at i on a 'grande' scale it aint such a big deal, for some people it would be seen as a no, but then how many sites do you see running Only SSL clients? Not many.... it all depends on who you want to attract. My opinion - depending on your confidence in your own web skills, and your familiarity with apache itself i would use it and monitor port 80 alot more than previous, also note your traffice will most likely increase. As for actual exploitations, i cannot disclose that information simply, but it will always be vulnerable without a vigilant web admin anyhow, i say go for it. Regards, Drew. On 5/14/05, Joe Schmoe wrote: > Hello, >=20 > I built apache+openssl+mod_ssl. It is working fine, > and I have been starting the server with: >=20 > apachectl startssl >=20 > Recently, however, I have decided that I will not be > doing anything over https (for a while, at least) with > this web server, so for security reasons, I want to > only run on port 80. >=20 > So now I start the server with: >=20 > apachectl start >=20 > And it runs without SSL. My question is, is starting > the SSl enabled apache like this, and running it > without SSL exactly the same security-wise as running > a copy of apache without SSL at all ? That is, SSL > libraries, etc., can have vulnerabilities in them, and > am I still vulnerable to those problems even if I am > running only on port 80 ? >=20 > What kinds of attacks might I _not_ be insulating > myself against by simply not running SSL, vs. > reinstalling without it ? >=20 > thanks, >=20 > __________________________________ > Yahoo! Mail Mobile > Take Yahoo! Mail with you! Check email on your mobile phone. > http://mobile.yahoo.com/learn/mail > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.or= g" >=20 --=20 -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance. From owner-freebsd-security@FreeBSD.ORG Sat May 14 13:08:31 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C19E16A4CE; Sat, 14 May 2005 13:08:31 +0000 (GMT) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E373F43D48; Sat, 14 May 2005 13:08:30 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGH0029BJP41GD0@osl1smout1.broadpark.no>; Sat, 14 May 2005 17:15:04 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IGH00LHEE0H6QA0@osl1sminn1.broadpark.no>; Sat, 14 May 2005 15:12:17 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 3A4CC45165; Sat, 14 May 2005 15:08:29 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 83F2945131; Sat, 14 May 2005 15:08:25 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 761B933C3B; Sat, 14 May 2005 15:08:25 +0200 (CEST) Date: Sat, 14 May 2005 15:08:25 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <94145.1116037219@critter.freebsd.dk> To: Poul-Henning Kamp Message-id: <86fywqdkfq.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <94145.1116037219@critter.freebsd.dk> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: cc: freebsd-security@freebsd.org cc: das@freebsd.org cc: "Drew B. \[Security Expertise/Freelance Security research\]." Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 13:08:31 -0000 "Poul-Henning Kamp" writes: > The correct (technical) workaround (IMO) is to restrict HTT to be > used only for threads from the same process. > > The political problem is that if all operating systems do that, > Intel has a pretty dud feature on their hands, and they are not > particularly eager to accept that fact. No. Intel themselves recommend only scheduling threads from the same address space on the same physical core, simply because it improves cache efficiency. Scheduling threads from separate processes on the same physical core can actually *reduce* performance due to cache churn. Fixing our scheduler to avoid scheduling threads from different processes on the same physical core is likely to increase performance across the board, because heavily multithreaded software will get a bigger boost and single-threaded software will be penalized less than it is today. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Sat May 14 15:29:21 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B890716A4CE for ; Sat, 14 May 2005 15:29:21 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60A8443D7C for ; Sat, 14 May 2005 15:29:21 +0000 (GMT) (envelope-from d4rkstorm@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so332760rne for ; Sat, 14 May 2005 08:29:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pYGDJolNesynsiWg4bmjgo/vnRB3ySQkYYuAopFoU4TBs+NSNvXOPPvoTV9eNOLzCkEza5mJSmYw4LLFsuttdM8JHrBOOkB+62q+dqc3jjU5+ZHXs0yVseD4ks1M38/PZUTrurLUVMYQtJnE1jIRHELkxysvQJ+lxdlIS7QoFG8= Received: by 10.38.104.76 with SMTP id b76mr1387617rnc; Sat, 14 May 2005 08:29:21 -0700 (PDT) Received: by 10.38.101.18 with HTTP; Sat, 14 May 2005 08:29:21 -0700 (PDT) Message-ID: <245f0df105051408291dd3b641@mail.gmail.com> Date: Sun, 15 May 2005 01:29:21 +1000 From: "Drew B. [Security Expertise/Freelance Security research]." To: freebsd-security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: RE: Need some help X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Drew B. \[Security Expertise/Freelance Security research\]." List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 15:29:21 -0000 Hello, I would like to ask for some specialist assistance in dissecting a 'rootkit' (seems to be massmailing specific,crafted somehow from another kit perhaps) It was found running on 5.x machines belonging (sofar) to my knowledge, 2 companies,one of wich was an isp and another a webhosting service running bsd. I will provide the kit and further details as soon as i am sure the thing will be dealt with by someone official. Being properly examined so all exploits within it can be marked out,whether new and/or old-modified is important and I cannot successfully complete dissection with my current equipment. The atacks are still happening, the familiar 'ebay' login page or paypal, however, the bug itself is Linux-platform speciic, extremely stable, and extremly hard to remove. Anyone interested who has the abality,especially an A/V tech/worker with a certificate from the company or atleast email header,or anyone associated that can link this to freebsd security offically. I can confirm that it is stable and running on v5.x FreeBSD now, and have no idea how long it has been around. Regards, (&&assist) -------------------------------------------------------------------- Drew B. Independant Security analysis,for Aussies. Security researcher/expert,threat-focus,Freelance. From owner-freebsd-security@FreeBSD.ORG Sat May 14 22:21:07 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD78A16A4CE for ; Sat, 14 May 2005 22:21:07 +0000 (GMT) Received: from dfmm.org (treehorn.dfmm.org [66.180.195.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A47143D68 for ; Sat, 14 May 2005 22:21:06 +0000 (GMT) (envelope-from freebsd-security@dfmm.org) Received: (qmail 31905 invoked by uid 1000); 14 May 2005 22:21:04 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 May 2005 22:21:04 -0000 Date: Sat, 14 May 2005 15:21:04 -0700 (PDT) From: Jason Stone X-X-Sender: jason@treehorn.dfmm.org To: Joe Schmoe In-Reply-To: <20050513155454.63841.qmail@web53302.mail.yahoo.com> Message-ID: <20050514151248.J99949@treehorn.dfmm.org> References: <20050513155454.63841.qmail@web53302.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-security@freebsd.org Subject: Re: different ways to disable https in apache... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 22:21:07 -0000 > My question is, is starting the SSl enabled apache like this, and > running it without SSL exactly the same security-wise as running a copy > of apache without SSL at all ? no, it is certainly not exactly the same. as you note, you will still link against the openssl libraries, and even though you won't be directly calling functions in them, I can certainly imagine an exploit that could take advantage of their availability. more importantly, mod_ssl modifies the apache module api, since the standard api in 1.3 was not powerful enought for ssl to just drop in like other modules - so the internal architecture of a mod_ssl/eapi-enabled apache will be noticeably different from that of a normal apache, even if all ssl functionality is disabled. bottom line is, even if ssl functionality is turned off, it's still in there, and it increases the complexity of the server significantly. and increased complexity almost always means decreased security. if you're not using it, and don't have immediate plans to use it, don't build it. -Jason From owner-freebsd-security@FreeBSD.ORG Sat May 14 22:30:32 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBEDE16A4CE for ; Sat, 14 May 2005 22:30:32 +0000 (GMT) Received: from mortis.over-yonder.net (adsl-222-87-60.jan.bellsouth.net [68.222.87.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38FE643D7D for ; Sat, 14 May 2005 22:30:32 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id ADED820FB2; Sat, 14 May 2005 17:30:30 -0500 (CDT) Date: Sat, 14 May 2005 17:30:30 -0500 From: "Matthew D. Fuller" To: Jason Stone Message-ID: <20050514223030.GA93984@over-yonder.net> References: <20050513155454.63841.qmail@web53302.mail.yahoo.com> <20050514151248.J99949@treehorn.dfmm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050514151248.J99949@treehorn.dfmm.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 cc: freebsd-security@freebsd.org cc: Joe Schmoe Subject: Re: different ways to disable https in apache... X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 22:30:32 -0000 On Sat, May 14, 2005 at 03:21:04PM -0700 I heard the voice of Jason Stone, and lo! it spake thus: > > more importantly, mod_ssl modifies the apache module api, It should be noted that one implication of this is that other modules go squirrely when the API changes. For instance, if you install the regular Apache, build mod_php, then switch to the apache+mod_ssl, PHP will blow up and have to be recompiled. And going the other way, as well. So, if you DO have plans to use the SSL side, better to have it in place early so you don't forget. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-security@FreeBSD.ORG Sat May 14 22:32:08 2005 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5512C16A4CE for ; Sat, 14 May 2005 22:32:08 +0000 (GMT) Received: from dfmm.org (treehorn.dfmm.org [66.180.195.213]) by mx1.FreeBSD.org (Postfix) with ESMTP id 192DE43D72 for ; Sat, 14 May 2005 22:32:08 +0000 (GMT) (envelope-from freebsd-security@dfmm.org) Received: (qmail 33754 invoked by uid 1000); 14 May 2005 22:32:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 14 May 2005 22:32:07 -0000 Date: Sat, 14 May 2005 15:32:07 -0700 (PDT) From: Jason Stone X-X-Sender: jason@treehorn.dfmm.org To: Chris In-Reply-To: <3aaaa3a050514000629cc8427@mail.gmail.com> Message-ID: <20050514152716.D99949@treehorn.dfmm.org> References: <245f0df105051318564b1ffb6b@mail.gmail.com> <245f0df105051322354e8e86eb@mail.gmail.com> <3aaaa3a050514000629cc8427@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-security@freebsd.org cc: Poul-Henning Kamp Subject: Re: FreeBSD Security Advisory FreeBSD-SA-05:09.htt [REVISED] X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2005 22:32:08 -0000 > I am somewhat confused by applying the patch, does this disable HTT > functionality? or does a patched server close the issue and keep HTT > enabled? it disables htt by default. I wasn't able to tell by looking at it, though, does it also disable the second core on a dual-core cpu, or is it specific to htt? also, I wonder, is there an intention of advertising more loudly the fact that htt is henceforth always going to be disabled by default? is there any intention of having the installer offer an option to set the loader tunable? -Jason