From owner-freebsd-security Sun Feb 9 14:15:50 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA12929 for security-outgoing; Sun, 9 Feb 1997 14:15:50 -0800 (PST) Received: from burka.carrier.kiev.ua (snar@burka.carrier.kiev.ua [193.193.193.100]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA12857 for ; Sun, 9 Feb 1997 14:15:21 -0800 (PST) Received: (from snar@localhost) by burka.carrier.kiev.ua (8.8.4/8.who.cares.1) id AAA11849; Mon, 10 Feb 1997 00:13:52 +0200 (EET) Date: Mon, 10 Feb 1997 00:13:52 +0200 (EET) From: Alexander Snarskii Message-Id: <199702092213.AAA11849@burka.carrier.kiev.ua> To: rholland@freon.republic.k12.mo.us (Richard Holland) Cc: freebsd-security@freebsd.org Subject: Re: buffer overruns X-Newsreader: TIN [UNIX 1.3 unoff BETA release 960917] MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Sender: owner-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article 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
,$%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.