Date: Mon, 10 Feb 1997 00:13:52 +0200 (EET) From: Alexander Snarskii <snar@lucky.net> To: rholland@freon.republic.k12.mo.us (Richard Holland) Cc: freebsd-security@freebsd.org Subject: Re: buffer overruns Message-ID: <199702092213.AAA11849@burka.carrier.kiev.ua>
next in thread | raw e-mail | index | archive | help
In article <Pine.LNX.3.91.970209124900.2336B-100000@freon.republic.k12.mo.us> you wrote:
RH> With all of this locale stuff going on, it made me realize that I
RH>actually don't know what a buffer overrun is. However I am learning C at
RH>the moment and have a basic idea down:
RH>I know what in C, a variable takes up a certain amount of memory, like
RH>type char is usually 1 byte, so stating char var; in your code sets aside
RH>1 byte of memory aside. So if you then said var = 'blah' You would step
C is not a Pascal :)
You have two types of operations: 'operators', which are always
works with fixed-length data ( in your primer 'var' can be
char* , but with that assignment you'll never got stack violation,
just because that instruction translates into
movl <address of blah>,$<offset of var of %bp>%bp )
and functions, which can really damage stack frames ( also
in your primer:
int function() {
char var;
[...]
strcpy(&var,"blah");
[...]
return 0;
}
will really do so. )
RH>into other memory addresses right? So the set locale bug is this only
RH>put differently. It allocates X amount of bytes for the buffer, and
RH>people put to much junk into it, causing it to step into other memory
RH>addresses.
Noone operator can damage stack. Functions can. But, they're
not 'allocate' some amounts of the memory, they just writes some
data to the some location. More than, due to the processor
architecture, most variables, which are used in the programs
are in the stack segment, so, you will not necessary to broke
the 'nearest' stack frame, as in primer, you can broke _any_ of the
stack frames in your program.... And, the worst thing -
when you writes some data somewhere, you can not check
( on the C-level of programming ), does this byte/word/dword
now overwrites some stack frame or not...
But, you can check this in the assembler level, and, more than,
the patches to libc to most 'insecure' functions ( such as
strcpy and sprintf, f.e. ) are published in the -hackers
list today. ( You can find it with www.freebsd.org/search.html
by subject "Increasing overall security" )
--
Alexander Snarskii
the source code is included.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702092213.AAA11849>