© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-08-04 03:05:20 UTC
FreeBSD ports repository
Modified files:
books/developers-handbook/secure chapter.sgml
Log:
Ubersetzung vom Kapitel 3 von Nornagest
Revision Changes Path
1.2 +522 -400 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.1
retrieving revision 1.2
diff -u -I$FreeBSDde.*$ -r1.1 -r1.2
--- chapter.sgml 1 Aug 2007 19:18:33 -0000 1.1
+++ chapter.sgml 4 Aug 2007 03:05:20 -0000 1.2
@@ -6,165 +6,192 @@
basiert auf: 1.27
-->
- <chapter id="secure">
- <chapterinfo>
- <authorgroup>
- <author>
- <firstname>Murray</firstname>
- <surname>Stokely</surname>
- <contrib>Contributed by </contrib>
- </author>
- </authorgroup>
- </chapterinfo>
+ <chapter id="secure">
+ <chapterinfo>
+ <authorgroup>
+ <author>
+ <firstname>Murray</firstname>
+ <surname>Stokely</surname>
+ <contrib>Contributed by </contrib>
+ </author>
+ </authorgroup>
+ </chapterinfo>
- <title>Secure Programming</title>
+ <title>Sicheres Programmieren</title>
- <sect1 id="secure-synopsis"><title>Synopsis</title>
-
- <para>This chapter describes some of the security issues that
- have plagued &unix; programmers for decades and some of the new
- tools available to help programmers avoid writing exploitable
- code.</para>
- </sect1>
-
- <sect1 id="secure-philosophy"><title>Secure Design
- Methodology</title>
-
- <para>Writing secure applications takes a very scrutinous and
- pessimistic outlook on life. Applications should be run with
- the principle of <quote>least privilege</quote> so that no
- process is ever running with more than the bare minimum access
- that it needs to accomplish its function. Previously tested
- code should be reused whenever possible to avoid common
- mistakes that others may have already fixed.</para>
-
- <para>One of the pitfalls of the &unix; environment is how easy it
- is to make assumptions about the sanity of the environment.
- Applications should never trust user input (in all its forms),
- system resources, inter-process communication, or the timing of
- events. &unix; processes do not execute synchronously so logical
- operations are rarely atomic.</para>
- </sect1>
-
- <sect1 id="secure-bufferov"><title>Buffer Overflows</title>
-
- <para>Buffer Overflows have been around since the very
- beginnings of the Von-Neuman <xref linkend="COD"> architecture.
-
- <indexterm><primary>buffer overflow</primary></indexterm>
- <indexterm><primary>Von-Neuman</primary></indexterm>
-
- They first gained widespread notoriety in 1988 with the Morris
- Internet worm. Unfortunately, the same basic attack remains
+ <sect1 id="secure-synopsis">
+ <title>Synopsis</title>
- <indexterm><primary>Morris Internet worm</primary></indexterm>
-
- effective today. Of the 17 CERT security advisories of 1999, 10
+ <para>Dieses Kapitel beschreibt einige Sicherheitsprobleme,
+ die &unix;-Programmierer seit Jahrzehnten quälen und
+ inzwischen verfügbare Werkzeuge, die Programmierern
+ helfen, Sicherheitslücken in ihrem Quelltext zu
+ vermeiden
+ </para>
+
+ </sect1>
- <indexterm>
- <primary>CERT</primary><secondary>security advisories</secondary>
- </indexterm>
+ <sect1 id="secure-philosophy">
+ <title>Methoden des sicheren Entwurfs</title>
- of them were directly caused by buffer-overflow software bugs.
- By far the most common type of buffer overflow attack is based
- on corrupting the stack.</para>
-
- <indexterm><primary>stack</primary></indexterm>
- <indexterm><primary>arguments</primary></indexterm>
-
- <para>Most modern computer systems use a stack to pass arguments
- to procedures and to store local variables. A stack is a last
- in first out (LIFO) buffer in the high memory area of a process
- image. When a program invokes a function a new "stack frame" is
+ <para>Sichere Anwendungen zu schreiben erfordert eine sehr
+ skeptische und pessimistische Einstellung zum Leben.
+ Anwendungen sollten nach dem Prinzip der
+ <quote>geringsten Privilegien</quote> ausgeführt
+ werden, sodass kein Prozess mit mehr als dem absoluten
+ Minimum an Zugriffsrechten arbeitet, die er zum
+ erfüllen seiner Aufgabe benötigt. Wo es
+ möglich ist,sollte Quelltext, der bereits
+ überprüft wurde, wiederverwendet werden, um
+ häufige Fehler, die andere schon korrigiert haben,
+ 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,
+ Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
+ Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher
+ sind logische Operationen selten atomar.
+ </para>
+ </sect1>
+
+ <sect1 id="secure-bufferov">
+ <title>Puffer-Übrläufe</title>
+
+ <para>Puffer-Überläufe gibt es schön seit den
+ Anfängen der Von-Neuman-Architektur <xref linkend="COD">.
+
+ <indexterm><primary>Puffer-Überlauf</primary></indexterm>
+ <indexterm><primary>Von-Neuman</primary></indexterm>
+
+ Sie fanden zum ersten Mal verbreitete Beachtung, durch den
+ Internetwurm Morris im Jahr 1988. Unglücklicherweise
+
+ <indexterm><primary>Morris Internetwurm</primary></indexterm>
+
+ funktioniert der gleiche grundlegende Angriff noch heute. Von
+ den 17 CERT Sicherheitshinweisen im Jahr 1999, wurden zehn
+
+ <indexterm>
+ <primary>CERT</primary>
+ <secondary>Sicheitshinweise</secondary>
+ </indexterm>
+
+ 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>
+
+ <indexterm><primary>Stack</primary></indexterm>
+ <indexterm><primary>Arguments</primary></indexterm>
+
+ <para>Die meisten modernen Computer-Systeme verwenden einen
+ Stack, um Argumente an Prozeduren zu übergeben und
+ 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>process image</primary>
- <secondary>stack pointer</secondary>
- </indexterm>
-
- created. This stack frame consists of the arguments passed to
- the function as well as a dynamic amount of local variable
- space. The "stack pointer" is a register that holds the current
-
- <indexterm><primary>stack frame</primary></indexterm>
- <indexterm><primary>stack pointer</primary></indexterm>
-
- location of the top of the stack. Since this value is
- constantly changing as new values are pushed onto the top of the
- stack, many implementations also provide a "frame pointer" that
- is located near the beginning of a stack frame so that local
- variables can more easily be addressed relative to this
- value. <xref linkend="COD"> The return address for function
+ <indexterm><primary>LIFO</primary></indexterm>
+ <indexterm>
+ <primary>Prozessabbild</primary>
+ <secondary>Stack-Pointer</secondary>
+ </indexterm>
- <indexterm><primary>frame pointer</primary></indexterm>
- <indexterm>
- <primary>process image</primary>
- <secondary>frame pointer</secondary>
- </indexterm>
- <indexterm><primary>return address</primary></indexterm>
- <indexterm><primary>stack-overflow</primary></indexterm>
+ aufruft, wird eine neuer "Stack-Frame" erzeugt. Dieser
+ besteht aus den Argumenten, die der Funktion übergeben
+ wurden und einer dynamischen Speichermenge für lokale
----------------------------------------------
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 - 05:06:42 CEST