Bug 125485

Summary: [patch] updates to developers handbook: security section
Product: Documentation Reporter: Gavin Atkinson <gavin>
Component: Books & ArticlesAssignee: Gabor Pali <pgj>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
devh-secure.diff none

Description Gavin Atkinson freebsd_committer freebsd_triage 2008-07-10 21:50:02 UTC
	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
Comment 1 Gabor Pali freebsd_committer freebsd_triage 2008-07-11 06:19:03 UTC
Responsible Changed
From-To: freebsd-doc->pgj

Grab.
Comment 2 Gabor Pali freebsd_committer freebsd_triage 2008-07-19 07:41:58 UTC
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++."
Comment 3 Gavin Atkinson freebsd_committer freebsd_triage 2008-07-22 10:30:08 UTC
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
Comment 4 dfilter service freebsd_committer freebsd_triage 2008-07-23 22:41:10 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"
Comment 5 Gabor Pali freebsd_committer freebsd_triage 2008-07-23 23:09:36 UTC
State Changed
From-To: open->closed

Committed with indentation fixes and a suggestion to change 
chroot() to chroot(8) by gabor.  Thank you!