From ga9@buffy.york.ac.uk  Thu Jul 10 20:41:01 2008
Return-Path: <ga9@buffy.york.ac.uk>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id C31651065671
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 10 Jul 2008 20:41:01 +0000 (UTC)
	(envelope-from ga9@buffy.york.ac.uk)
Received: from mail-gw2.york.ac.uk (mail-gw2.york.ac.uk [144.32.128.247])
	by mx1.freebsd.org (Postfix) with ESMTP id 749408FC18
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 10 Jul 2008 20:41:00 +0000 (UTC)
	(envelope-from ga9@buffy.york.ac.uk)
Received: from mail-gw6.york.ac.uk (mail-gw6.york.ac.uk [144.32.129.26])
	by mail-gw2.york.ac.uk (8.13.6/8.13.6) with ESMTP id m6AKewm2018900
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 10 Jul 2008 21:40:58 +0100 (BST)
Received: from buffy-128.york.ac.uk ([144.32.128.160] helo=buffy.york.ac.uk)
	by mail-gw6.york.ac.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.63)
	(envelope-from <ga9@buffy.york.ac.uk>)
	id 1KH2wk-0003JO-Jn
	for FreeBSD-gnats-submit@freebsd.org; Thu, 10 Jul 2008 21:40:58 +0100
Received: from buffy.york.ac.uk (localhost [127.0.0.1])
	by buffy.york.ac.uk (8.14.2/8.14.2) with ESMTP id m6AKew6Z069199
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 10 Jul 2008 21:40:58 +0100 (BST)
	(envelope-from ga9@buffy.york.ac.uk)
Received: (from ga9@localhost)
	by buffy.york.ac.uk (8.14.2/8.14.2/Submit) id m6AKewRa069198;
	Thu, 10 Jul 2008 21:40:58 +0100 (BST)
	(envelope-from ga9)
Message-Id: <200807102040.m6AKewRa069198@buffy.york.ac.uk>
Date: Thu, 10 Jul 2008 21:40:58 +0100 (BST)
From: Gavin Atkinson <gavin@freebsd.org>
Reply-To: Gavin Atkinson <gavin@freebsd.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: [patch] updates to developers handbook: security section
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         125485
>Category:       docs
>Synopsis:       [patch] updates to developers handbook: security section
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    pgj
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Jul 10 20:50:02 UTC 2008
>Closed-Date:    Wed Jul 23 22:19:07 UTC 2008
>Last-Modified:  Wed Jul 23 22:19:07 UTC 2008
>Originator:     Gavin Atkinson
>Release:        FreeBSD 7.0-STABLE amd64
>Organization:
>Environment:
System: FreeBSD buffy.york.ac.uk 7.0-STABLE FreeBSD 7.0-STABLE #3: Fri Jun 20 09:21:51 UTC 2008 root@buffy.york.ac.uk:/usr/obj/usr/src/sys/GENERIC amd64

>Description:
	A couple of updates to the "Secure Programming" section of the
developers handbook:
- Remove an example that is sufficiently old to not really be meaningful.
- StackGuard is no more, replace the mention with a section on ProPolice.
- Clarify a use of "jail" to mean a chroot() jail.
Note that this section also has a section on POSIX Process Capabilities
in need of an update, I'll do that on the next sweep.
>How-To-Repeat:
	N/A
>Fix:

--- devh-secure.diff begins here ---
Index: doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml
===================================================================
RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml,v
retrieving revision 1.28
diff -u -r1.28 chapter.sgml
--- doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml	4 Aug 2007 08:11:40 -0000	1.28
+++ doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml	10 Jul 2008 20:34:44 -0000
@@ -57,13 +57,7 @@
 
       <indexterm><primary>Morris Internet worm</primary></indexterm>
 
-      effective today.  Of the 17 CERT security advisories of 1999, 10
-
-      <indexterm>
-        <primary>CERT</primary><secondary>security advisories</secondary>
-      </indexterm>
-
-      of them were directly caused by buffer-overflow software bugs.
+      effective today.
       By far the most common type of buffer overflow attack is based
       on corrupting the stack.</para>
 
@@ -259,39 +253,32 @@
         code in public use which blindly copies memory around without
         using any of the bounded copy routines we just discussed.
         Fortunately, there is another solution.  Several compiler
-        add-ons and libraries exist to do Run-time bounds checking in
+        features and libraries exist to do Run-time bounds checking in
         C/C++.</para> 
 
+	<indexterm><primary>ProPolice</primary></indexterm> 
 	<indexterm><primary>StackGuard</primary></indexterm> 
 	<indexterm><primary>gcc</primary></indexterm>  
 
-        <para>StackGuard is one such add-on that is implemented as a
-        small patch to the gcc code generator.  From the <ulink
-          url="http://immunix.org/stackguard.html">StackGuard
-          website</ulink>:
-
-        <blockquote><para>"StackGuard detects and defeats stack
-        smashing attacks by protecting the return address on the stack
-        from being altered.  StackGuard places a "canary" word next to
-        the return address when a function is called.  If the canary
-        word has been altered when the function returns, then a stack
-        smashing attack has been attempted, and the program responds
-        by emitting an intruder alert into syslog, and then
-        halts."</para></blockquote> 
-
-        <blockquote><para>"StackGuard is implemented as a small patch
-        to the gcc code generator, specifically the function_prolog()
-        and function_epilog() routines.  function_prolog() has been
-        enhanced to lay down canaries on the stack when functions
-        start, and function_epilog() checks canary integrity when the
-        function exits.  Any attempt at corrupting the return address
-        is thus detected before the function
-        returns."</para></blockquote>
-        </para>
+	<para>ProPolice is one such compiler feature, and is
+	integrated into &man.gcc.1; version 4.1 and later.  It
+	replaces and extends the earlier StackGuard &man.gcc.1;
+	extension.</para>
+
+	<para>ProPolice helps to protect against stack-based buffer
+	overflows and other attacks by laying pseudo-random numbers
+	in key areas of the stack before calling any function.  On
+	the function return these "canaries" are checked, and if
+	they are found to have been changed the executable is
+	immediately aborted.  Thus any attempt to modify the return
+	address or other variable stored on the stack in an attempt
+	to get malicious code to run is unlikely to succeed, as the
+	attacker would have to also manage to leave the pseudo-random
+	canaries untouched.</para>
 
         <indexterm><primary>buffer overflow</primary></indexterm>
 
-        <para>Recompiling your application with StackGuard is an
+        <para>Recompiling your application with ProPolice is an
         effective means of stopping most buffer-overflow attacks, but
         it can still be compromised.</para>
 
@@ -378,7 +365,8 @@
       should also be noted that a process can easily break out of a
       chroot environment if it has root privilege.  This could be
       accomplished by creating device nodes to read kernel memory,
-      attaching a debugger to a process outside of the jail, or in
+      attaching a debugger to a process outside of the
+      <function>chroot()</function> jail, or in
       many other creative ways.</para>
       
       <para>The behavior of the <function>chroot()</function> system
--- devh-secure.diff ends here ---


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-doc->pgj 
Responsible-Changed-By: pgj 
Responsible-Changed-When: Fri Jul 11 05:19:03 UTC 2008 
Responsible-Changed-Why:  
Grab. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=125485 

From: Gabor PALI <pgj@FreeBSD.org>
To: bug-followup@FreeBSD.org, Gavin Atkinson <gavin@FreeBSD.org>
Cc:  
Subject: Re: docs/125485: [patch] updates to developers handbook: security
 section
Date: Sat, 19 Jul 2008 08:41:58 +0200

 I received some recommendations for this PR:
 
 - probably better to use the plural ``versions'' in "gcc versions 4.1
 and later"
 
 - "On the function return" --> "When a function returns, ..."
 
 - "canaries" --> <quote>canaries</quote>
 
 - just say chroot() instead of chroot() jail -- jail means something
 else in almost all &os; contexts; definitely not "chroot() jail",
 they're different things these days.  Least in *BSD.
 
 - "Several compiler features and libraries exist to do Run-time bounds
 checking" is not quite right.  It seems a bit odd to talk about features
 existing; It would be better to have run-time lowercase.
 -->
 "Fortunately, there is a way to stop many attacks on such code &mdash;
 run-time bounds checking, which is implemented by several compilers for
 C/C++."
 

From: Gavin Atkinson <gavin@FreeBSD.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: docs/125485: [patch] updates to developers handbook: security
 section
Date: Tue, 22 Jul 2008 10:30:08 +0100 (BST)

 Updated patch.
 
 Index: doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml
 ===================================================================
 RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml,v
 retrieving revision 1.28
 diff -u -r1.28 chapter.sgml
 --- doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml	4 Aug 2007 08:11:40 -0000	1.28
 +++ doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml	22 Jul 2008 09:28:21 -0000
 @@ -57,13 +57,7 @@
 
         <indexterm><primary>Morris Internet worm</primary></indexterm>
 
 -      effective today.  Of the 17 CERT security advisories of 1999, 10
 -
 -      <indexterm>
 -        <primary>CERT</primary><secondary>security advisories</secondary>
 -      </indexterm>
 -
 -      of them were directly caused by buffer-overflow software bugs.
 +      effective today.
         By far the most common type of buffer overflow attack is based
         on corrupting the stack.</para>
 
 @@ -258,40 +252,33 @@
           <para>Unfortunately there is still a very large assortment of
           code in public use which blindly copies memory around without
           using any of the bounded copy routines we just discussed.
 -        Fortunately, there is another solution.  Several compiler
 -        add-ons and libraries exist to do Run-time bounds checking in
 -        C/C++.</para> 
 +        Fortunately, there is a way to help prevent such attacks &mdash;
 +        run-time bounds checking, which is implemented by several
 +        C/C++ compilers.</para>
 
 +	<indexterm><primary>ProPolice</primary></indexterm>
   	<indexterm><primary>StackGuard</primary></indexterm>
   	<indexterm><primary>gcc</primary></indexterm>
 
 -        <para>StackGuard is one such add-on that is implemented as a
 -        small patch to the gcc code generator.  From the <ulink
 -          url="http://immunix.org/stackguard.html">StackGuard
 -          website</ulink>:
 -
 -        <blockquote><para>"StackGuard detects and defeats stack
 -        smashing attacks by protecting the return address on the stack
 -        from being altered.  StackGuard places a "canary" word next to
 -        the return address when a function is called.  If the canary
 -        word has been altered when the function returns, then a stack
 -        smashing attack has been attempted, and the program responds
 -        by emitting an intruder alert into syslog, and then
 -        halts."</para></blockquote> 
 -
 -        <blockquote><para>"StackGuard is implemented as a small patch
 -        to the gcc code generator, specifically the function_prolog()
 -        and function_epilog() routines.  function_prolog() has been
 -        enhanced to lay down canaries on the stack when functions
 -        start, and function_epilog() checks canary integrity when the
 -        function exits.  Any attempt at corrupting the return address
 -        is thus detected before the function
 -        returns."</para></blockquote>
 -        </para>
 +	<para>ProPolice is one such compiler feature, and is
 +	integrated into &man.gcc.1; versions 4.1 and later.  It
 +	replaces and extends the earlier StackGuard &man.gcc.1;
 +	extension.</para>
 +
 +	<para>ProPolice helps to protect against stack-based buffer
 +	overflows and other attacks by laying pseudo-random numbers
 +	in key areas of the stack before calling any function.  When
 +	a function returns, these <quote>canaries</quote> are checked
 +	and if they are found to have been changed the executable is
 +	immediately aborted.  Thus any attempt to modify the return
 +	address or other variable stored on the stack in an attempt
 +	to get malicious code to run is unlikely to succeed, as the
 +	attacker would have to also manage to leave the pseudo-random
 +	canaries untouched.</para>
 
           <indexterm><primary>buffer overflow</primary></indexterm>
 
 -        <para>Recompiling your application with StackGuard is an
 +        <para>Recompiling your application with ProPolice is an
           effective means of stopping most buffer-overflow attacks, but
           it can still be compromised.</para>
 
 @@ -378,7 +365,8 @@
         should also be noted that a process can easily break out of a
         chroot environment if it has root privilege.  This could be
         accomplished by creating device nodes to read kernel memory,
 -      attaching a debugger to a process outside of the jail, or in
 +      attaching a debugger to a process outside of the
 +      <function>chroot()</function> environment, or in
         many other creative ways.</para>
 
         <para>The behavior of the <function>chroot()</function> system

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: docs/125485: commit references a PR
Date: Wed, 23 Jul 2008 21:41:10 +0000 (UTC)

 pgj         2008-07-23 21:40:57 UTC
 
   FreeBSD doc repository
 
   Modified files:
     en_US.ISO8859-1/books/developers-handbook/secure chapter.sgml 
   Log:
   - A couple of updates to the "Secure Programming" section of the
     developers handbook
   
   PR:             docs/125485
   Submitted by:   gavin
   Reviewed by:    trhodes, gabor, Ben Kaduk <minimarmot (at) gmail (dot) com>
   Approved by:    gabor
   
   Revision  Changes    Path
   1.29      +22 -35    doc/en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml
 _______________________________________________
 cvs-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/cvs-all
 To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
 
State-Changed-From-To: open->closed 
State-Changed-By: pgj 
State-Changed-When: Wed Jul 23 22:09:36 UTC 2008 
State-Changed-Why:  
Committed with indentation fixes and a suggestion to change 
chroot() to chroot(8) by gabor.  Thank you! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=125485 
>Unformatted:
