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

From: Aron Schlesinger <as(at)doc.bsdgroup.de>
Date: Sat, 4 Aug 2007 05:41:43 GMT

as 2007-08-04 05:41:43 UTC

FreeBSD ports repository

  Modified files:
    books/developers-handbook/secure chapter.sgml
  Log:
  Nach den FDP-Vorgaben formatiert.

  Revision Changes Path
  1.3 +343 -339 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.2
  retrieving revision 1.3
  diff -u -I$FreeBSDde.*$ -r1.2 -r1.3
  --- chapter.sgml 4 Aug 2007 03:05:20 -0000 1.2
  +++ chapter.sgml 4 Aug 2007 05:41:42 -0000 1.3
  @@ -26,9 +26,7 @@
           die &unix;-Programmierer seit Jahrzehnten quälen und
           inzwischen verfügbare Werkzeuge, die Programmierern
           helfen, Sicherheitslücken in ihrem Quelltext zu
  - vermeiden
  - </para>
  -
  + vermeiden.</para>
       </sect1>

       <sect1 id="secure-philosophy">
  @@ -44,17 +42,15 @@
           möglich ist,sollte Quelltext, der bereits
           überprüft wurde, wiederverwendet werden, um
           häufige Fehler, die andere schon korrigiert haben,
  - zu vermeiden.
  - </para>
  + zu vermeiden.</para>

         <para>Eine der Stolperfallen der &unix;-Umgebung ist, dass es
  - sehr einfach ist Annahmen über die Gesundheit der Umgebung
  - zu machen. Anwendungen sollten Nutzereingaben (in allen
  - Formen) niemals trauen, ebenso, wie System-Ressourcen,
  + sehr einfach ist Annahmen über die Gesundheit der
  + Umgebung zu machen. Anwendungen sollten Nutzereingaben (in
  + allen Formen) niemals trauen, ebenso, wie System-Ressourcen,
           Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
           Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher
  - sind logische Operationen selten atomar.
  - </para>
  + sind logische Operationen selten atomar.</para>
       </sect1>

       <sect1 id="secure-bufferov">
  @@ -81,9 +77,8 @@

           direkt durch Puffer-Überläufe in Software
           verursacht. Die bei weitem häufigste Form eines
  - Puffer-Überlauf-Angriffs basiert darauf den Stack zu
  - korrumpieren.
  - </para>
  + Puffer-Überlauf-Angriffs basiert darauf den Stack
  + zu korrumpieren.</para>

         <indexterm><primary>Stack</primary></indexterm>
         <indexterm><primary>Arguments</primary></indexterm>
  @@ -108,12 +103,13 @@
           <indexterm><primary>Stack-Frame</primary></indexterm>
           <indexterm><primary>Stack-Pointer</primary></indexterm>

  - aktuelle Position der Spitze des Stacks enthält. Da sich
  - dieser Wert andauernd ändert, wenn neue Werte auf dem
  - Stack abgelegt werden, bieten viele Implementierungen einen
  - "Frame-Pointer", der nahe am Anfang des Stack-Frames liegt
  - und es so leichter macht lokale Variablen relativ dazu zu
  - adressieren. <xref linkend="COD"> Die Rücksprungadresse
  + aktuelle Position der Spitze des Stacks enthält.
  + Da sich dieser Wert andauernd ändert, wenn neue Werte
  + auf dem Stack abgelegt werden, bieten viele Implementierungen
  + einen "Frame-Pointer", der nahe am Anfang des Stack-Frames
  + liegt und es so leichter macht lokale Variablen relativ dazu
  + zu adressieren. <xref linkend="COD">
  + Die Rücksprungadresse

           <indexterm><primary>Frame-Pointer</primary></indexterm>
           <indexterm>
  @@ -129,71 +125,83 @@
           indem er eine lokale Variable in einer Funktion
           überlaufen lässt, die Rücksprungadresse der
           Funktion überschreiben und dadurch beliebigen Code
  - ausführen kann.
  - </para>
  + ausführen kann.</para>

  - <para>Obwohl Stack-basierte Angriffe bei weitem die häufigsten
  - sind, ist es auch möglich den Stack mit einem
  - Heap-basierten (malloc/free) Angriff zu überschreiben.
  - </para>
  + <para>Obwohl Stack-basierte Angriffe bei weitem die
  + häufigsten sind, ist es auch möglich den Stack
  + mit einem Heap-basierten (malloc/free) Angriff zu
  + überschreiben.</para>

         <para>Die C-Programmiersprache führt keine automatischen
           Bereichsprüfungen bei Arrays oder Zeigern durch, wie
           viele andere Sprachen das tun. Außerdem enthält
           die C-Standardbibliothek eine Hand voll sehr
  - gefährlicher Funktionen.
  - </para>
  + gefährlicher Funktionen.</para>

         <informaltable frame="none" pgwide="1">
           <tgroup cols="2">
             <tbody>
  - <row><entry><function>strcpy</function>(char *dest, const char
  - *src)</entry>
  - <entry><simpara>Kann den Puffer dest überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>strcat</function>(char *dest, const char
  - *src)</entry>
  - <entry><simpara>Kann den Puffer dest überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>getwd</function>(char *buf)</entry>
  - <entry><simpara>Kann den Puffer buf überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>gets</function>(char *s)</entry>
  - <entry><simpara>Kann den Puffer s überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>[vf]scanf</function>(const char *format,
  - ...)</entry>
  - <entry><simpara>Kann sein Argument überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>realpath</function>(char *path, char
  - resolved_path[])</entry>
  - <entry><simpara>Kann den Puffer path überlaufen lassen</simpara></entry>
  - </row>
  -
  - <row><entry><function>[v]sprintf</function>(char *str, const char
  - *format, ...)</entry>
  - <entry><simpara>Kann den Puffer str überlaufen lassen</simpara></entry>
  - </row>
  + <row>
  + <entry><function>strcpy</function>(char *dest,
  + const char *src)</entry>
  + <entry><simpara>Kann den Puffer dest überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>strcat</function>(char *dest,
  + const char *src)</entry>
  + <entry><simpara>Kann den Puffer dest überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>getwd</function>(char *buf)</entry>
  + <entry><simpara>Kann den Puffer buf überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>gets</function>(char *s)</entry>
  + <entry><simpara>Kann den Puffer s überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>[vf]scanf</function>(const char
  + *format, ...)</entry>
  + <entry><simpara>Kann sein Argument überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>realpath</function>(char *path,
  + char resolved_path[])</entry>
  + <entry><simpara>Kann den Puffer path überlaufen
  + lassen</simpara></entry>
  + </row>
  +
  + <row>
  + <entry><function>[v]sprintf</function>(char *str,
  + const char *format, ...)</entry>
  + <entry><simpara>Kann den Puffer str überlaufen
  + lassen</simpara></entry>
  + </row>
             </tbody>
           </tgroup>
         </informaltable>

  - <sect2><title>Puffer-Überlauf Beispiel</title>
  + <sect2>
  + <title>Puffer-Überlauf Beispiel</title>

  - <para>Das folgende Quellcode-Beispiel enthält einen
  - Puffer-Überlauf, der darauf ausgelegt ist die
  - Rücksprungadresse zu überschreiben und die
  - Anweisung direkt nach dem Funktionsaufruf zu
  - überspringen. (Inspiriert durch
  - <xref linkend="Phrack">)
  - </para>
  + <para>Das folgende Quellcode-Beispiel enthält einen
  + Puffer-Überlauf, der darauf ausgelegt ist die
  + Rücksprungadresse zu überschreiben und die
  + Anweisung direkt nach dem Funktionsaufruf zu
  + überspringen. (Inspiriert durch

----------------------------------------------
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 - 07:42:55 CEST