From owner-freebsd-security@FreeBSD.ORG Mon Oct 31 16:25:16 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 AA91316A42A for ; Mon, 31 Oct 2005 16:25:16 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: from galois.wahtec.com.br (galois.wahtec.com.br [200.96.65.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id B061A43D49 for ; Mon, 31 Oct 2005 16:25:13 +0000 (GMT) (envelope-from suporte@wahtec.com.br) Received: (qmail 21005 invoked by uid 98); 31 Oct 2005 16:26:35 -0000 Received: from 127.0.0.1 by brasil.intranet (envelope-from , uid 1024) with qmail-scanner-1.24 (f-prot: 4.4.7/3.14.13. spamassassin: 2.63. Clear:RC:1(127.0.0.1):. Processed in 0.106335 secs); 31 Oct 2005 16:26:35 -0000 X-Qmail-Scanner-Mail-From: suporte@wahtec.com.br via brasil.intranet X-Qmail-Scanner: 1.24 (Clear:RC:1(127.0.0.1):. Processed in 0.106335 secs) Received: from unknown (HELO buddyguy) (arisjr@unknown) by unknown with SMTP; 31 Oct 2005 16:26:35 -0000 From: suporte@wahtec.com.br To: freebsd-security@freebsd.org Date: Mon, 31 Oct 2005 16:25:45 +0000 User-Agent: KMail/1.8 References: <20051030120107.CD5CF16A422@hub.freebsd.org> In-Reply-To: <20051030120107.CD5CF16A422@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200510311625.46334.suporte@wahtec.com.br> Subject: More on freebsd-update (WAS: Is the server portion of freebsd-update open source?) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 16:25:17 -0000 > Date: Sat, 29 Oct 2005 07:34:28 -0700 > From: Colin Percival > Subject: Re: Is the server portion of freebsd-update open source? > To: markzero > Cc: freebsd-security@freebsd.org > Message-ID: <43638874.2020004@freebsd.org> > Content-Type: text/plain; charset=ISO-8859-1 > > markzero wrote: > > No this isn't insufficient, what is insufficient is that I currently > > can't run a local freebsd-update server. I'm quite limited by bandwidth > > here, you see. What would make more sense in my situation would be to > > have a local mirror of the 'official' freebsd-update server so that > > all of my machines can sync to that rather than all of them downloading > > over the WAN. > > Go ahead. :-):-) > > FreeBSD Update relies entirely upon static files served over HTTP, so if > you point your favourite HTTP mirroring tool at update.daemonology.net > you can create a local mirror. > > Another approach which is likely to be more useful is to set up an HTTP > proxy: Since many files on the FreeBSD Update web server won't be fetched > by most systems (FreeBSD Update attempts to use binary patches, and only > falls back to fetching complete files if the patching fails), using a > caching HTTP proxy will use far less bandwidth than mirroring everything. > > Colin Percival Hi, I have two questions to add to this thread... 1- if and when freebsd-update will be the official freebsd system binary update? Like, when it will be part of freebsd structure, with a dedicated server and stuff? ... It's far better then updating by cvs. 2- for future plans, is there any possibility to customize or add some features to kernels on official freebsd-update server? IPSEC is quite important on security. Since there isn't a LKM to use IPSEC (correct me if I'm wrong), when someone compiles the kernel to add it, he looses the freebsd-update kernel update. Regards, --aristeu PS: is there a way to use IPSEC without compiling the kernel? From owner-freebsd-security@FreeBSD.ORG Tue Nov 1 08:55:08 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 347A116A41F for ; Tue, 1 Nov 2005 08:55:08 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4D4A43D46 for ; Tue, 1 Nov 2005 08:55:07 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr5so.prod.shaw.ca (pd2mr5so-qfe3.prod.shaw.ca [10.0.141.8]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IP9009L9Q3ULG50@l-daemon> for freebsd-security@freebsd.org; Tue, 01 Nov 2005 01:55:06 -0700 (MST) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd2mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IP9005Q7Q3UK3A0@pd2mr5so.prod.shaw.ca> for freebsd-security@freebsd.org; Tue, 01 Nov 2005 01:55:06 -0700 (MST) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IP900C4EQ3TSY@l-daemon> for freebsd-security@freebsd.org; Tue, 01 Nov 2005 01:55:06 -0700 (MST) Date: Tue, 01 Nov 2005 00:55:05 -0800 From: Colin Percival In-reply-to: <200510311625.46334.suporte@wahtec.com.br> To: suporte@wahtec.com.br Message-id: <43672D69.2000208@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.93.0.0 References: <20051030120107.CD5CF16A422@hub.freebsd.org> <200510311625.46334.suporte@wahtec.com.br> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) Cc: freebsd-security@freebsd.org Subject: Re: More on freebsd-update (WAS: Is the server portion of freebsd-update open source?) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2005 08:55:08 -0000 suporte@wahtec.com.br wrote: > 1- if and when freebsd-update will be the official freebsd system binary > update? Like, when it will be part of freebsd structure, with a dedicated > server and stuff? ... It's far better then updating by cvs. FreeBSD Update is now semi-officially supported, in the sense that I make sure that it works but the rest of the security team isn't involved. As I mentioned earlier, I'm planning on rewriting the build code to make it far simpler and more reliable; this will make it possible for someone else to take over if I get hit by a bus, at which point FreeBSD Update will become officially supported. :-) > 2- for future plans, is there any possibility to customize or add some > features to kernels on official freebsd-update server? IPSEC is quite > important on security. Since there isn't a LKM to use IPSEC (correct me if > I'm wrong), when someone compiles the kernel to add it, he looses the > freebsd-update kernel update. Right now I provide prebuilt GENERIC and SMP kernels; I could build some other kernel configurations, but there's obviously a limit to what is practical. After I rewrite the build code I'll have to consult with the release engineering team and the user community about which kernels would be most useful. Colin Percival From owner-freebsd-security@FreeBSD.ORG Wed Nov 2 12:30:59 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 C103316A424 for ; Wed, 2 Nov 2005 12:30:59 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 496B743D45 for ; Wed, 2 Nov 2005 12:30:59 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id DAE8E2085; Wed, 2 Nov 2005 13:30:53 +0100 (CET) X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -4.4/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id C01222083; Wed, 2 Nov 2005 13:30:53 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 9CB6833C1D; Wed, 2 Nov 2005 13:30:53 +0100 (CET) To: db References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Wed, 02 Nov 2005 13:30:53 +0100 In-Reply-To: <200510291412.57656.db@traceroute.dk> (db@traceroute.dk's message of "Sat, 29 Oct 2005 14:12:57 +0000") Message-ID: <86pspjz0xu.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org, Jimmy Scott Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 12:30:59 -0000 db writes: > Memory on ia32 can be writable and readable. When it is readable it > is also executable. On other arch's like AMD64 and IA64, I believe > memory can be readable, writable and executable. Not quite. IA32 can make individual segments readable, writable and / or executable, but lacks the ability to do so on a per-page basis. Since we have trampoline code at the top of the stack, the entire stack segment must be executable. Moving the trampoline off the stack would solve the problem on all platforms. W^X across the board is not an option - it would break HotSpot and other JIT-based software. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Wed Nov 2 15:41:26 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 B7EBD16A41F for ; Wed, 2 Nov 2005 15:41:26 +0000 (GMT) (envelope-from db@traceroute.dk) Received: from cicero0.cybercity.dk (cicero0.cybercity.dk [212.242.40.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C00343D53 for ; Wed, 2 Nov 2005 15:41:26 +0000 (GMT) (envelope-from db@traceroute.dk) Received: from user3.cybercity.dk (user3.cybercity.dk [212.242.41.36]) by cicero0.cybercity.dk (Postfix) with ESMTP id 1A81629F62; Wed, 2 Nov 2005 16:41:24 +0100 (CET) Received: from trinita (port132.ds1-arsy.adsl.cybercity.dk [212.242.239.73]) by user3.cybercity.dk (Postfix) with ESMTP id 91C2993C1A; Wed, 2 Nov 2005 16:41:23 +0100 (CET) From: db To: "Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=" , freebsd-security@freebsd.org Date: Wed, 2 Nov 2005 15:41:26 +0000 User-Agent: KMail/1.8.2 References: <200510270608.51571.db@traceroute.dk> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> In-Reply-To: <86pspjz0xu.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511021541.26986.db@traceroute.dk> Cc: Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 15:41:26 -0000 On Wednesday 02 November 2005 12:30, you wrote: > Not quite. IA32 can make individual segments readable, writable and / > or executable, but lacks the ability to do so on a per-page basis. > Since we have trampoline code at the top of the stack, the entire > stack segment must be executable. Moving the trampoline off the stack > would solve the problem on all platforms. > > W^X across the board is not an option - it would break HotSpot and > other JIT-based software. Ah I see, but how about making the patch without touching the trampoline code section? I'm not talking about doing it on all platforms (if ia32 sucks) or making it default, just to give us security minded admins and users a kernel option. br db From owner-freebsd-security@FreeBSD.ORG Wed Nov 2 19:14:58 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 7820816A424; Wed, 2 Nov 2005 19:14:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35E7A43D45; Wed, 2 Nov 2005 19:14:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 02 Nov 2005 11:06:41 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43690E40.5040705@elischer.org> Date: Wed, 02 Nov 2005 11:06:40 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> In-Reply-To: <86pspjz0xu.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 03 Nov 2005 14:02:31 +0000 Cc: Jimmy Scott , Robert Watson , freebsd-security@freebsd.org Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2005 19:14:58 -0000 Dag-Erling Smørgrav wrote: >db writes: > > >>Memory on ia32 can be writable and readable. When it is readable it >>is also executable. On other arch's like AMD64 and IA64, I believe >>memory can be readable, writable and executable. >> >> > >Not quite. IA32 can make individual segments readable, writable and / >or executable, but lacks the ability to do so on a per-page basis. >Since we have trampoline code at the top of the stack, the entire >stack segment must be executable. Moving the trampoline off the stack >would solve the problem on all platforms. > > There has been recent talk of a shared kernel/user memory page.. that could be used for trampoline code. >W^X across the board is not an option - it would break HotSpot and >other JIT-based software. > >DES > > From owner-freebsd-security@FreeBSD.ORG Thu Nov 3 15:28:21 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 660FF16A41F; Thu, 3 Nov 2005 15:28:21 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) Received: from mail.npubs.com (mail.zoneseven.net [209.66.100.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AB443D48; Thu, 3 Nov 2005 15:28:21 +0000 (GMT) (envelope-from nielsen-list@memberwebs.com) From: Nate Nielsen User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Colin Percival References: <20051027233106.377D070DCE3@mail.npubs.com> <4361CD31.1080707@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20051103153958.4609E70DD46@mail.npubs.com> X-Virus-Scanned: ClamAV using ClamSMTP Date: Thu, 3 Nov 2005 15:39:58 +0000 (GMT) Cc: freebsd-security@freebsd.org, Nielsen Subject: Re: Is the server portion of freebsd-update open source? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nielsen@memberwebs.com List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Nov 2005 15:28:21 -0000 Colin Percival wrote: > The FreeBSD Update build code is... umm... somewhere in between. I think > the best way to explain it is to say that I don't care about copyright on > the build code, but the code is a stinking pile of hacks upon hacks with > multiple known bugs -- so I don't particularly want to expose it to public > scrutiny and I doubt that it will be very useful either. > > Rewriting the build code is approaching the top of my todo list, but isn't > there quite yet; in the meantime, if you can send me more details about what > you want to do I'll see if I can accommodate you. Thanks. Sorry for not getting back to you right away. The guys I'm developing this project for have bought into open source and are hesitant about using technology which isn't totally transparent and open to peer review. But in any case (after discussion), it seems like freebsd-update is in fact the closest thing to what we need. We have a many little embedded boxes in the field, and they need to pull down updates. The updates are obviously non-standard: - Built with NOSHARED=no (all dynamic linking, no static). - Updates of various ports, like isc-dhcpd, quagga, vpn stuff etc. - Updates of our own customized binaries. - Custom kernel. - Greatly reduced fileset. Getting access to the build code would keep us from having to implement our own system (which would probably end up being based on bsdiff/bspatch anyway). Of course this is not a demand, but a request. BTW, thanks for all you do toward security on FreeBSD. Cheers, Nate Nielsen From owner-freebsd-security@FreeBSD.ORG Fri Nov 4 00:11:35 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 D9AC916A41F for ; Fri, 4 Nov 2005 00:11:35 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D51D43D46 for ; Fri, 4 Nov 2005 00:11:35 +0000 (GMT) (envelope-from freebsd-security@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1EXpAS-0004Ty-QW for freebsd-security@freebsd.org; Fri, 04 Nov 2005 01:10:52 +0100 Received: from r5k101.chello.upc.cz ([86.49.10.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Nov 2005 01:10:52 +0100 Received: from martinkov by r5k101.chello.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 04 Nov 2005 01:10:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-security@freebsd.org From: martinko Date: Fri, 04 Nov 2005 00:39:54 +0100 Lines: 37 Message-ID: References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> <43690E40.5040705@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r5k101.chello.upc.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050925 X-Accept-Language: sk, cs, en-gb, en-us, en In-Reply-To: <43690E40.5040705@elischer.org> Sender: news Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 00:11:36 -0000 Julian Elischer wrote: > Dag-Erling Smørgrav wrote: > >> db writes: >> >> >>> Memory on ia32 can be writable and readable. When it is readable it >>> is also executable. On other arch's like AMD64 and IA64, I believe >>> memory can be readable, writable and executable. >>> >> >> >> Not quite. IA32 can make individual segments readable, writable and / >> or executable, but lacks the ability to do so on a per-page basis. >> Since we have trampoline code at the top of the stack, the entire >> stack segment must be executable. Moving the trampoline off the stack >> would solve the problem on all platforms. >> >> > > There has been recent talk of a shared kernel/user memory page.. > that could be used for trampoline code. > >> W^X across the board is not an option - it would break HotSpot and >> other JIT-based software. >> >> DES >> >> > _______________________________________________ > 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" > > and what exactly is that trampoline btw/pls ? From owner-freebsd-security@FreeBSD.ORG Fri Nov 4 10:38:45 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 C138B16A41F for ; Fri, 4 Nov 2005 10:38:45 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 492A643D45 for ; Fri, 4 Nov 2005 10:38:45 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id B5BE82083; Fri, 4 Nov 2005 11:38:37 +0100 (CET) X-Spam-Tests: ALL_TRUSTED,AWL,BAYES_00 X-Spam-Learn: ham X-Spam-Score: -4.4/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on tim.des.no Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 9C3CB2082; Fri, 4 Nov 2005 11:38:37 +0100 (CET) Received: by xps.des.no (Postfix, from userid 1001) id 7AE3033C1D; Fri, 4 Nov 2005 11:38:37 +0100 (CET) To: martinko References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> <43690E40.5040705@elischer.org> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 04 Nov 2005 11:38:37 +0100 In-Reply-To: (martinkov@pobox.sk's message of "Fri, 04 Nov 2005 00:39:54 +0100") Message-ID: <86sluchf4i.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-security@freebsd.org Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 10:38:45 -0000 martinko writes: > and what exactly is that trampoline btw/pls ? When a process receives a signal, the kernel needs to call the appropriate signal handler (in user space), then do some cleanup when the signal handler returns, and pass control back to whatever code was interrupted by the signal. The cleanup is handled by the sigreturn() syscall. To avoid having to manually add a call to sigreturn() at the end of each signal handler, we use a small piece of trampoline code (sigcode in locore.S) which calls the signal handler, then issues a sigreturn() syscall. This trampoline needs to be in a fixed location so the kernel knows where to find it, and it needs to be present at all times, so we can't just put it in the crt and then have the crt report its location to the kernel somehow. Currently, it is copied into place at the top of the stack by execve(). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-security@FreeBSD.ORG Fri Nov 4 00:23:51 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 53BCE16A41F for ; Fri, 4 Nov 2005 00:23:51 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 103DC43D45 for ; Fri, 4 Nov 2005 00:23:50 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.23.117]) ([10.251.23.117]) by a50.ironport.com with ESMTP; 03 Nov 2005 16:23:49 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <436AAA14.7020603@elischer.org> Date: Thu, 03 Nov 2005 16:23:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: martinko References: <200510270608.51571.db@traceroute.dk> <200510291242.16461.db@traceroute.dk> <20051029131519.GA22254@ada.devbox.be> <200510291412.57656.db@traceroute.dk> <86pspjz0xu.fsf@xps.des.no> <43690E40.5040705@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 04 Nov 2005 13:59:13 +0000 Cc: freebsd-security@freebsd.org Subject: Re: Non-executable stack X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 00:23:51 -0000 martinko wrote: > Julian Elischer wrote: > >> Dag-Erling Smørgrav wrote: >> >>> db writes: >>> >>> >>>> Memory on ia32 can be writable and readable. When it is readable it >>>> is also executable. On other arch's like AMD64 and IA64, I believe >>>> memory can be readable, writable and executable. >>>> >>> >>> >>> >>> Not quite. IA32 can make individual segments readable, writable and / >>> or executable, but lacks the ability to do so on a per-page basis. >>> Since we have trampoline code at the top of the stack, the entire >>> stack segment must be executable. Moving the trampoline off the stack >>> would solve the problem on all platforms. >>> >>> >> >> There has been recent talk of a shared kernel/user memory page.. >> that could be used for trampoline code. >> >>> W^X across the board is not an option - it would break HotSpot and >>> other JIT-based software. >>> >>> DES >>> >>> >> _______________________________________________ >> 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" >> >> > > and what exactly is that trampoline btw/pls ? the way that signals are deliverred in non threaded code, is that they are always delivered when the processor is returning to userland after having been in the kernel for some reason (a hardware interrupt, or a sheduler change or a syscall or a pagefault, it doesn't matter why). The kernel places code on the user stack, that calls the signal handler and then returns, returning to whatever is next on the stack, which is the return address that it would have gone to when returning from the kernel had the signal not happenned. The code has to know how to get ready to call a signal handler, call it and cleanup anything that needs to be cleaned up after a signal handler. It's placed on the stack as it's guaranteed to exist and it all cleans up after itself., requiring no further work from the kernel. It does however require that the stack is executable. it allows the kernel to always supply a working signal handling stub. With a shared page (readonly to the user), the kernel could permanently place a good stub handler there. > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to > "freebsd-security-unsubscribe@freebsd.org" From owner-freebsd-security@FreeBSD.ORG Sat Nov 5 13:09:19 2005 Return-Path: X-Original-To: freebsd-security@freebsd.org 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 9176F16A41F; Sat, 5 Nov 2005 13:09:19 +0000 (GMT) (envelope-from scheidell@secnap.net) Received: from 0.mail.spammertrap.net (0.mail.spammertrap.net [204.89.241.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D97943D58; Sat, 5 Nov 2005 13:09:16 +0000 (GMT) (envelope-from scheidell@secnap.net) Received: from localhost (localhost [127.0.0.1]) by 0.mail.spammertrap.net (Postfix) with ESMTP id 1119218F3E7; Sat, 5 Nov 2005 08:09:16 -0500 (EST) Received: from secnap2.secnap.com (secnap2.secnap.com [204.89.241.128]) by 0.mail.spammertrap.net (Postfix) with ESMTP id 6891218F3E0; Sat, 5 Nov 2005 08:09:13 -0500 (EST) Received: from 0.mail.spammertrap.net ([204.89.241.173]) by secnap2.secnap.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Nov 2005 15:16:26 -0500 Received: from localhost (localhost [127.0.0.1]) by 0.mail.spammertrap.net (Postfix) with ESMTP id 90D8218F3E4 for ; Fri, 4 Nov 2005 15:16:26 -0500 (EST) Received: from outgoing.securityfocus.com (outgoing.securityfocus.com [205.206.231.26]) by 0.mail.spammertrap.net (Postfix) with ESMTP id 3930D18F3E0 for ; Fri, 4 Nov 2005 15:16:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Received: from outgoing.securityfocus.com by outgoing.securityfocus.com via smtpd (for 0.mail.spammertrap.net [204.89.241.173]) with ESMTP; Fri, 4 Nov 2005 12:16:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20]) by outgoing2.securityfocus.com (Postfix) with QMQP id 8E484146106; Fri, 4 Nov 2005 11:35:46 -0700 (MST) Received: (qmail 5051 invoked from network); 4 Nov 2005 11:10:45 -0000 content-class: urn:content-classes:message Date: Sat, 5 Nov 2005 08:09:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Freebsd port issue: ZDI-05-002: Clam Antivirus Remote Code Execution Thread-Index: AcXhfKKGdaPvPjHiT/6d4Ee70BRFQg== From: "Michael Scheidell" To: X-Virus-Scanned: SpammerTrap(tm) SME-250 1.45 at spammertrap.net X-Spam-Status: No, score=-6.401 tagged_above=-999 required=6.9 tests=[AWL=-0.003, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6, LOCAL_RCVD=-5, UNPARSEABLE_RELAY=0.001] X-Spam-Score: -6.401 X-Spam-Level: Cc: ports@freebsd.org, rob@debank.tv Subject: Freebsd port issue: ZDI-05-002: Clam Antivirus Remote Code Execution X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2005 13:09:19 -0000 This was in bugtraq, and hasn't shown up in portaudit yet so I thought I would send it and the fix to you. I submitted a pr for a patch as well. (but for some reason, ir bounced) Problem #1: Clamav 87 has been found to have a security vulnerability that could lead to remote code execution Problem #2 patch patch-clamav-milter_clamav-milter.c won't apply cleanly (and I have't the slightest idea why, or even WHAT the patch does: --- clamav-milter/clamav-milter.c.orig +++ clamav-milter/clamav-milter.c @@ -3439,9 +3439,9 @@ { fd_set rfds; struct timeval tv; + int ret; assert(sock >=3D 0); - int ret; if(readTimeout =3D=3D 0) { do >How-To-Repeat: See: http://www.zerodayinitiative.com/advisories/ZDI-05-002.html when trying to compile new clamav, get this: Applying FreeBSD patches for clamav-0.87.1 Ignoring previously applied (or reversed) patch. 1 out of 1 hunks ignored--saving rejects to clamav-milter/clamav-milter.c.rej =3D> Patch patch-clamav-milter_clamav-milter.c failed to apply cleanly. >Fix: remove patch (it looks like a dunsel) rm files/patch-clamav-milter_clamav-milter.c --- Makefile.orig Fri Nov 4 17:57:18 2005 +++ Makefile Sat Nov 5 07:26:14 2005 @@ -6,8 +6,7 @@ # PORTNAME=3D clamav -PORTVERSION=3D 0.87 -PORTREVISION=3D 2 +PORTVERSION=3D 0.87.1 CATEGORIES=3D security MASTER_SITES=3D ${MASTER_SITE_SOURCEFORGE_EXTENDED} MASTER_SITE_SUBDIR=3D clamav --- distinfo.orig Fri Nov 4 17:57:23 2005 +++ distinfo Sat Nov 5 07:26:02 2005 @@ -1,2 +1,2 @@ -MD5 (clamav-0.87.tar.gz) =3D dd0a12deb4f48f760fa1fcd378ae7c24 -SIZE (clamav-0.87.tar.gz) =3D 4273714 +MD5 (clamav-0.87.1.tar.gz) =3D bf9f038edf0b6d5f76552e1b8d014b81 SIZE=20 +(clamav-0.87.1.tar.gz) =3D 4468992 ZDI-05-002: Clam Antivirus Remote Code Execution Vulnerability http://www.zerodayinitiative.com/advisories/ZDI-05-002.html November 4th, 2005 -- CVE ID: CAN-2005-3303 -- Affected Vendor: Clam AntiVirus -- Affected Products: Clam AntiVirus 0.80 through 0.87 -- TippingPoint(TM) IPS Customer Protection: TippingPoint IPS customers have been protected against this vulnerability since October 24th, 2005 by Digital Vaccine protection filter ID 3874. For further product information on the TippingPoint IPS: http://www.tippingpoint.com=20 -- Vulnerability Details: This vulnerability allows remote attackers to execute arbitrary code on vulnerable ClamAV installations. Authentication is not required to exploit this vulnerability. This specific flaw exists within libclamav/fsg.c during the unpacking of executable files compressed with FSG v1.33. Due to invalid bounds checking when copying user-supplied data to heap allocated memory, an exploitable memory corruption condition is created. The unpacking algorithm for other versions of FSG is not affected.=20 -- Vendor Response: The bug has been fixed in version 0.87.1. Release notes: http://www.sourceforge.net/project/shownotes.php?release_id=3D368319 = -- Disclosure Timeline: 2005.10.24 - Vulnerability reported to vendor 2005.10.24 - Digital Vaccine released to TippingPoint customers 2005.10.25 - Vulnerability information provided to ZDI security partners 2005.11.04 - Public release of advisory -- Credit: This vulnerability was discovered by an anonymous ZDI researcher. -- About the Zero Day Initiative (ZDI): Established by TippingPoint, a division of 3Com, The Zero Day Initiative (ZDI) represents a best-of-breed model for rewarding security researchers for responsibly disclosing discovered vulnerabilities. Researchers interested in getting paid for their security research through the ZDI can find more information and sign-up at: http://www.zerodayinitiative.com The ZDI is unique in how the acquired vulnerability information is used. 3Com does not re-sell the vulnerability details or any exploit code. Instead, upon notifying the affected product vendor, 3Com provides its customers with zero day protection through its intrusion prevention technology. Explicit details regarding the specifics of the vulnerability are not exposed to any parties until an official vendor patch is publicly available. Furthermore, with the altruistic aim of helping to secure a broader user base, 3Com provides this vulnerability information confidentially to security vendors (including competitors) who have a vulnerability protection or mitigation product.