cvs commit: de-docproj/books/developers-handbook/secure chapter.sgml

From: Martin <miwi(at)doc.bsdgroup.de>
Date: Sat, 4 Aug 2007 20:58:16 GMT

miwi 2007-08-04 20:58:16 UTC

  FreeBSD ports repository

  Modified files:
    books/developers-handbook/secure chapter.sgml
  Log:
  - Fehlerbehebung/Rechschreibung [1]
  - Whitespaces/Format [2]
  
  Submitted by: Hagen Kuehl [1]
                  miwi [2]
  
  Revision Changes Path
  1.4 +50 -49 de-docproj/books/developers-handbook/secure/chapter.sgml
  
  Index: chapter.sgml
  ===================================================================
  RCS file: /home/cvs/de-docproj/books/developers-handbook/secure/chapter.sgml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -I$FreeBSDde.*$ -r1.3 -r1.4
  --- chapter.sgml 4 Aug 2007 05:41:42 -0000 1.3
  +++ chapter.sgml 4 Aug 2007 20:58:16 -0000 1.4
  @@ -18,9 +18,9 @@
       </chapterinfo>
   
       <title>Sicheres Programmieren</title>
  -
  +
       <sect1 id="secure-synopsis">
  - <title>Synopsis</title>
  + <title>Zusammenfassung</title>
   
         <para>Dieses Kapitel beschreibt einige Sicherheitsprobleme,
           die &unix;-Programmierer seit Jahrzehnten qu&auml;len und
  @@ -33,13 +33,13 @@
         <title>Methoden des sicheren Entwurfs</title>
   
         <para>Sichere Anwendungen zu schreiben erfordert eine sehr
  - skeptische und pessimistische Einstellung zum Leben.
  + skeptische und pessimistische Lebenseinstellung.
           Anwendungen sollten nach dem Prinzip der
           <quote>geringsten Privilegien</quote> ausgef&uuml;hrt
           werden, sodass kein Prozess mit mehr als dem absoluten
           Minimum an Zugriffsrechten arbeitet, die er zum
           erf&uuml;llen seiner Aufgabe ben&ouml;tigt. Wo es
  - m&ouml;glich ist,sollte Quelltext, der bereits
  + m&ouml;glich ist, sollte Quelltext, der bereits
           &uuml;berpr&uuml;ft wurde, wiederverwendet werden, um
           h&auml;ufige Fehler, die andere schon korrigiert haben,
           zu vermeiden.</para>
  @@ -54,15 +54,15 @@
       </sect1>
   
       <sect1 id="secure-bufferov">
  - <title>Puffer-&Uuml;brl&auml;ufe</title>
  + <title>Puffer-&Uuml;berl&auml;ufe</title>
   
         <para>Puffer-&Uuml;berl&auml;ufe gibt es sch&ouml;n seit den
           Anf&auml;ngen der Von-Neuman-Architektur <xref linkend="COD">.
   
  - <indexterm><primary>Puffer-&Uuml;berlauf</primary></indexterm>
  + <indexterm><primary>Puffer-&Uuml;berlauf</primary></indexterm>
           <indexterm><primary>Von-Neuman</primary></indexterm>
   
  - Sie fanden zum ersten Mal verbreitete Beachtung, durch den
  + Sie fanden zum ersten Mal verbreitete Beachtung durch den
           Internetwurm Morris im Jahr 1988. Ungl&uuml;cklicherweise
   
           <indexterm><primary>Morris Internetwurm</primary></indexterm>
  @@ -80,22 +80,22 @@
           Puffer-&Uuml;berlauf-Angriffs basiert darauf den Stack
           zu korrumpieren.</para>
   
  - <indexterm><primary>Stack</primary></indexterm>
  - <indexterm><primary>Arguments</primary></indexterm>
  + <indexterm><primary>Stack</primary></indexterm>
  + <indexterm><primary>Arguments</primary></indexterm>
   
         <para>Die meisten modernen Computer-Systeme verwenden einen
           Stack, um Argumente an Prozeduren zu &uuml;bergeben und
  - lokale Variable zu speichern. Ein Stack ist ein
  + lokale Variable zu speichern. Ein Stack ist ein
           last-in-first-out-Puffer (LIFO) im hohen Speicherbereich
           eines Prozessabbilds. Wenn ein Programm eine Funktion
  -
  +
           <indexterm><primary>LIFO</primary></indexterm>
           <indexterm>
             <primary>Prozessabbild</primary>
               <secondary>Stack-Pointer</secondary>
           </indexterm>
   
  - aufruft, wird eine neuer "Stack-Frame" erzeugt. Dieser
  + aufruft, wird ein neuer "Stack-Frame" erzeugt. Dieser
           besteht aus den Argumenten, die der Funktion &uuml;bergeben
           wurden und einer dynamischen Speichermenge f&uuml;r lokale
           Variablen. Der "Stack-Pointer" ist ein Register, das die
  @@ -111,16 +111,16 @@
           zu adressieren. <xref linkend="COD">
           Die R&uuml;cksprungadresse
   
  - <indexterm><primary>Frame-Pointer</primary></indexterm>
  + <indexterm><primary>Frame-Pointer</primary></indexterm>
           <indexterm>
             <primary>Prozessabbild</primary>
               <secondary>Frame-Pointer</secondary>
           </indexterm>
  - <indexterm><primary>R&uuml;cksprungadresse</primary></indexterm>
  + <indexterm><primary>R&uuml;cksprungadresse</primary></indexterm>
           <indexterm><primary>Stack-&Uuml;berlauf</primary></indexterm>
   
           f&uuml;r Funktionsaufrufe wird ebenfalls auf dem Stack
  - gespeichert und das ist der Grund f&uuml;
  + gespeichert und das ist der Grund f&uuml;r
           Stack-&Uuml;berlauf-Exploits, da ein b&ouml;swilliger Nutzer,
           indem er eine lokale Variable in einer Funktion
           &uuml;berlaufen l&auml;sst, die R&uuml;cksprungadresse der
  @@ -213,7 +213,7 @@
     int i=0;
   
     while ((buffer[i++] = getchar()) != '\n') {};
  -
  +
     i=1;
     manipulate(buffer);
     i=2;
  @@ -246,7 +246,7 @@
             <indexterm>
               <primary>Zeichenketten-Kopierfunktioen</primary>
               <secondary>strncpy</secondary>
  - </indexterm>
  + </indexterm>
             <indexterm>
               <primary>Zeichenketten-Kopierfunktionen</primary>
               <secondary>strncat</secondary>
  @@ -262,7 +262,7 @@
   
             <indexterm><primary>NUL-Terminierung</primary></indexterm>
   
  - des Eingabepuffers so gro&szlig; ist, wie das Ziel.
  + des Eingabepuffers so gro&szlig; ist wie das Ziel.
             Au&szlig;erdem wird der Parameter length zwischen strncpy
             und strncat inkonsistent benutzt, weshalb Programmierer
             leicht bez&uuml;glich der korrekten Verwendung durcheinander
  @@ -315,22 +315,22 @@
               Es gibt einige Compiler-Erweiterungen und Bibliotheken,
               die Grenzen in C/C++ zur Laufzeit &uuml;berpr&uuml;fen.
             </para>
  -
  - <indexterm><primary>StackGuard</primary></indexterm>
  - <indexterm><primary>GCC</primary></indexterm>
  +
  + <indexterm><primary>StackGuard</primary></indexterm>
  + <indexterm><primary>GCC</primary></indexterm>
   
             <para>StackGuard ist eine solche Erweiterung, die als
               kleiner Patch f&uuml;r den GCC-Code-Generator
               implementiert ist. Von der <ulink
               url="http://immunix.org/stackguard.html">StackGuard
  - Webseite</ulink>(&uuml;bersetzt):
  + Webseite</ulink> (&uuml;bersetzt):
   
               <blockquote>
  - <para>"StackGuard erkennt und verhintert
  + <para>"StackGuard erkennt und verhindert
                   sogenannte Stack-Smashing-Angriffe, indem es die
                   R&uuml;cksprungadresse auf dem Stack davor
                   sch&uuml;tzt ge&auml;ndert zu werden. StackGuard
  - platziert ein "canary"-Wort (Anmerkung des
  + platziert ein "Canary"-Wort (Anmerkung des
                   &Uuml;bersetzers: Kanarienvogel, nach einer
                   Sicherheitsvorkehrung von Bergleuten, um Gas
                   fr&uuml;hzeitig zu erkennen) neben der
  @@ -344,8 +344,9 @@
   
               <blockquote>
                 <para>"StackGuard ist als ein kleiner Patch f&uuml;r
  - den GCC-Code-Generator implementiert, genauer die
  - Routinen function_prolog() und function_epilog().
  + den GCC-Code-Generator implementiert, um genau zu
  + sein f&uuml;r die Routinen function_prolog() und
  + function_epilog().
                   function_prolog() wurde erweitert, um Canaries beim
                   Start einer Funktion auf den Stack zu legen und
                   function_epilog() &uuml;berpr&uuml;ft die
  @@ -360,7 +361,7 @@
   
             <para>Ihre Anwendungen mit StackGuard neu zu kompilieren ist
               eine effektive Ma&szlig;nahme, um sie vor den meisten
  - Puffer-&Uuml;berlauf-Angriffen zu sch&uuml;tzen, sie
  + Puffer-&Uuml;berlauf-Angriffen zu sch&uuml;tzen, aber sie
               k&ouml;nnen noch immer gef&auml;hrdet sein.</para>
           </sect3>
   
  @@ -375,11 +376,11 @@
   
             <para>Compiler-basierte Mechanismen sind bei Software,
               die nur im Bin&auml;rformat vertrieben wird und die somit
  - nicht neu kompiliert werden kann, v&ouml;llig nutzlos.
  - F&uuml;r diesen Fall gibt es einige Bibliotheken, die die
  - unsicheren Funktionen der C-Bibliothek
  + nicht neu kompiliert werden kann v&ouml;llig nutzlos.
  + F&uuml;r diesen Fall gibt es einige Bibliotheken, welche
  + die unsicheren Funktionen der C-Bibliothek
               (<function>strcpy</function>, <function>fscanf</function>,
  - <function>getwd</function>, etc..) neuimplementieren und
  + <function>getwd</function>, etc..) neu implementieren und
               sicherstellen, dass nicht hinter den Stack-Pointer
               geschrieben werden kann.</para>
   
  @@ -392,10 +393,10 @@
             <para>Leider haben diese Bibliotheks-basierten
               Verteidigungen mehrere Schw&auml;chen. Diese Bibliotheken
               sch&uuml;tzen nur vor einer kleinen Gruppe von

----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Sat 04 Aug 2007 - 23:18:44 CEST

search this site