© 1995-2008 by The FreeBSD Project. All rights reserved.URL: http://www.FreeBSD.de
as 2007-08-30 02:22:30 UTC
FreeBSD ports repository
Modified files:
books/developers-handbook/secure chapter.sgml
Log:
Kapitel 3 gegengelesen und korrigiert.
Gesendet von: Dennis Knorr
Revision Changes Path
1.7 +86 -84 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.6
retrieving revision 1.7
diff -u -I$FreeBSDde.*$ -r1.6 -r1.7
--- chapter.sgml 6 Aug 2007 12:47:10 -0000 1.6
+++ chapter.sgml 30 Aug 2007 02:22:29 -0000 1.7
@@ -43,10 +43,10 @@
vermeiden.</para>
<para>Eine der Stolperfallen der &unix;-Umgebung ist, dass es
- sehr einfach ist Annahmen über die Gesundheit der Umgebung
+ sehr einfach ist Annahmen über die Konsistenz der Umgebung
zu machen. Anwendungen sollten Nutzereingaben (in allen Formen)
- niemals trauen, genausowenig wie System-Ressourcen,
- Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
+ niemals trauen, genausowenig wie den System-Ressourcen,
+ der Inter-Prozess-Kommunikation oder dem zeitlichen Ablauf von
Ereignissen. &unix;-Prozesse arbeiten nicht synchron. Daher sind
logische Operationen selten atomar.</para>
</sect1>
@@ -59,23 +59,23 @@
<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
+
+ Sie erlangten zum ersten Mal durch den Internetwurm Morris im
+ Jahre 1988 öffentliche Bekanntheit. 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
+ den 17 CERT-Sicherheitsmeldungen wurden 1999 zehn
<indexterm>
<primary>CERT</primary>
<secondary>Sicheitshinweise</secondary>
</indexterm>
- direkt durch Puffer-Überläufe in Software
+ direkt durch Puffer-Überläufe in der Software
verursacht. Die bei weitem häufigste Form eines
- Puffer-Überlauf-Angriffs basiert darauf den Stack
+ Puffer-Überlauf-Angriffs basiert darauf, den Stack
zu korrumpieren.</para>
<indexterm><primary>Stack</primary></indexterm>
@@ -83,9 +83,9 @@
<para>Die meisten modernen Computer-Systeme verwenden einen
Stack, um Argumente an Prozeduren zu übergeben und
- lokale Variable zu speichern. Ein Stack ist ein
+ lokale Variablen zu speichern. Ein Stack ist ein
last-in-first-out-Puffer (LIFO) im hohen Speicherbereich
- eines Prozessabbilds. Wenn ein Programm eine Funktion
+ eines Prozesses. Wenn ein Programm eine Funktion
<indexterm><primary>LIFO</primary></indexterm>
<indexterm>
@@ -93,20 +93,20 @@
<secondary>Stack-Pointer</secondary>
</indexterm>
- aufruft wird ein neuer "Stack-Frame" erzeugt. Dieser besteht aus
- den Argumenten, die der Funktion übergeben wurden, und
- einer dynamischen Speichermenge für lokale Variablen. Der
- "Stack-Pointer" ist ein Register, das die
+ aufruft wird ein neuer "Stackframe" erzeugt. Dieser besteht aus
+ den Argumenten, die der Funktion übergeben wurden und
+ einem variabel grossem Bereich für lokale Variablen. Der
+ "Stack-Pointer" ist ein Register, dass die
<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
+ aktuelle Adresse der Stack-Spitze enthält.
+ Da sich dieser Wert oft ä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">
+ liegt und es so leichter macht lokale Variablen relativ zum
+ aktuellen Stackframe zu adressieren. <xref linkend="COD">
Die Rücksprungadresse
<indexterm><primary>Frame-Pointer</primary></indexterm>
@@ -117,13 +117,13 @@
<indexterm><primary>Rücksprungadresse</primary></indexterm>
<indexterm><primary>Stack-Überlauf</primary></indexterm>
- für Funktionsaufrufe wird ebenfalls auf dem Stack
+ der Funktionen werden ebenfalls auf dem Stack
gespeichert und das ist der Grund für
- Stack-Überlauf-Exploits, da ein böswilliger Nutzer,
- 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>
+ Stack-Überlauf-Exploits. Denn ein böswilliger Nutzer
+ kann die Rücksprungadresse der Funktion überschreiben
+ indem er eine lokale Variable in der Funktion
+ überlaufen lässt, wodurch es ihm möglich ist
+ beliebigen Code auszuführen.</para>
<para>Obwohl Stack-basierte Angriffe bei weitem die
Häufigsten sind, ist es auch möglich den Stack mit
@@ -131,9 +131,9 @@
überschreiben.</para>
<para>Die C-Programmiersprache führt keine automatischen
- Bereichsprüfungen bei Arrays oder Zeigern durch, wie
+ Bereichsüprüfungen bei Feldern oder Zeigern durch, wie
viele andere Sprachen das tun. Außerdem enthält
- die C-Standardbibliothek eine handvoll sehr
+ die C-Standardbibliothek eine Handvoll sehr
gefährlicher Funktionen.</para>
<informaltable frame="none" pgwide="1">
@@ -234,10 +234,10 @@
<sect2>
<title>Puffer-Überläufe vermeiden</title>
- <para>Die offensichtlichste Lösung, um
- Stack-Überläufe zu vermeiden, ist bei Operationen
- auf Zeichenkette immer Funktionen und Speicher mit einer
- begrenzten Länge zu verwenden.
+ <para>Die direkteste Lösung, um
+ Stack-Überläufe zu vermeiden, ist immer
+ grössenbegrenzten Speicher und String-Copy-Funktionen
+ zu verwenden.
<function>strncpy</function> und <function>strncat</function>
sind Teil der C-Standardbibliothek.
@@ -250,11 +250,11 @@
<secondary>strncat</secondary>
</indexterm>
- Diese Funktionen akzeptieren einen Parameter length. Dieser
+ Diese Funktionen akzeptieren einen Längen-Parameter. Dieser
Wert sollte nicht größer sein als die Länge
des Zielpuffers. Die Funktionen kopieren dann bis zu
`length' Bytes von der Quelle zum Ziel. Allerdings gibt es
- auch einige Probleme. Keine der Funktionen garantiert, dass
+ einige Probleme. Keine der Funktionen garantiert, dass
die Zeichenkette NUL-terminiert ist, wenn die
Größe
@@ -262,14 +262,14 @@
des Eingabepuffers so groß ist wie das Ziel.
Außerdem wird der Parameter length zwischen strncpy
- und strncat inkonsistent benutzt, weshalb Programmierer
+ und strncat inkonsistent definiert, weshalb Programmierer
leicht bezüglich der korrekten Verwendung durcheinander
kommen können. Weiterhin gibt es einen spürbaren
Leistungsverlust im Vergleich zu
<function>strcpy</function>, wenn eine kurze Zeichenkette in
- einen großen Puffer kopiert wird, da
- <function>strncpy</function> bis zur angegebenen Länge
- mit NUL auffüllt.
+ einen großen Puffer kopiert wird. Denn
+ <function>strncpy</function> fült den Puffer bis zur
+ angegebenen Länge mit NUL auf.
</para>
<para>In OpenBSD wurde eine weitere Möglichkeit zum
@@ -282,7 +282,7 @@
immer NUL-terminiert wird, wenn das Argument length ungleich
null ist. Für weitere Informationen über diese
Funktionen lesen Sie bitte <xref linkend="OpenBSD">. Die
- OpenBSD-Anweisungen <function>strlcpy</function> und
+ OpenBSD-Funktionen <function>strlcpy</function> und
<function>strlcat</function> sind seit Version 3.3 auch in
FreeBSD verfügbar.</para>
@@ -297,7 +297,7 @@
</indexterm>
<sect3>
- <title>Compiler-basierte Laufzeitprüfung
+ <title>Compiler-basierte Laufzeitüberprüfung
von Grenzen</title>
<indexterm>
@@ -307,11 +307,11 @@
<para>Unglücklicherweise gibt es immer noch sehr viel
Quelltext, der allgemein verwendet wird und blind Speicher
- umherkopiert, ohne eine der begrenzenden Funktionen zu
- verwenden, die wir gerade besprochen haben.
+ umherkopiert, ohne eine der gerade besprochenen Funktionen,
+ die Begrenzungen unterstützen, zu verwenden.
Glücklicherweise gibt es eine weitere Lösung.
----------------------------------------------
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 Thu 30 Aug 2007 - 04:23:52 CEST