- 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

en_US.ISO8859-1/books/developers-handbook/secure/chapter.sgml

@@ -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,32 @@ int main() {
         <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>:
+	<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>
 
-        <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 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 +364,8 @@ int main() {
       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 &man.chroot.8;
+      environment, or in
       many other creative ways.</para>
       
       <para>The behavior of the <function>chroot()</function> system