|
|||||||||
|
|||||||||
| |||||||||
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
 |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
Dev Shed Forums Sponsor:
|
|
|
|
#1
April 14th, 2003, 11:25 PM
|
||||
|
||||
|
why can't i kill my stack!!??!!??
shouldnt this get a segmentation fault:
Code:
#include<syslog.h>
char buffer[4028];
void main()
{
int i;
for (i=0; i<=4030; i++)
buffer[i]='A';
syslog(LOG_ERR, buffer);
}
running RH8 compiling it with gcc
|
|
#2
April 14th, 2003, 11:32 PM
|
||||
|
||||
|
when i change it to an integer array, and set the loop to run until i=15, then i get a segmentation fault. but when i = 14 it runs perfectly fine...im confused? why wouldnt it fault at i = 10,11,12,13, or 14, but instead at 15? and why only with a int array instead of a char one?
Code:
// C++ version /////////////
#include<syslog.h>
#include<iostream>
using namespace std;
int main()
{
int buffer2[10];
int i = 0;
for(i; i <= 15; i++)
{
buffer2[i] = 2;
cout << buffer2[i] << " ";
}
cout << endl;
// syslog(LOG_ERR,buffer);
return 0;
}
Last edited by infamous41md : April 15th, 2003 at 01:06 AM.
|
|
#3
April 15th, 2003, 02:46 AM
|
|||
|
|||
|
some compilers add extra elements to prevent buffer over runs
and the buffer may be byte aligned to 15 bytes and a terminator (for a total of 16 bytes).
__________________
The essence of Christianity is told us in the Garden of Eden history. The fruit that was forbidden was on the Tree of Knowledge. The subtext is, All the suffering you have is because you wanted to find out what was going on. You could be in the Garden of Eden if you had just kept your f***ing mouth shut and hadn't asked any questions. Frank Zappa
|
|
#4
April 15th, 2003, 09:53 AM
|
||||
|
||||
|
hmm, how smart of them! perhaps if i turn off optimization that will help. the funny thing is that any time this has accidentally happened to me in MSVC++ and i overstep by even one element, it would crash. and now im trying to make it crash and it wont let me
 back to WinBlows for a bit i guess
|
|
#5
April 15th, 2003, 11:52 AM
|
|||
|
|||
|
Hey, infamous41md, are you testing what buffer overflows are "good" for? LOL
__________________
-- Manuel Hirsch - Linux, FreeBSD, programming, administration articles, tutorials and more.
|
|
#6
April 15th, 2003, 04:45 PM
|
||||
|
||||
|
MHirsch<< well, i know what they're "good" for, ehehh
, but currently i'm too newbish to do anything like that b/c i'd be afraid of funkin up some poor guys system and not even know it. right now im just trying to get a hang on exactly how the stack responds and where the eip points to. i m sure there are plenty scripts-in-a-can but that's not really any fun. edit: bah this is freaking hard  Last edited by infamous41md : April 15th, 2003 at 09:03 PM.
|
|
#7
April 16th, 2003, 01:41 AM
|
|||
|
|||
|
I think noone here would to this to "some poor guys system". But it is really an interesting area to test on your own programs & for learning purposes. Also, sometimes you are challenged to prove that a certain system is not secure
...I heard they canīt disable code execution on the stack globally in linux eg. because some programs do rely on that. Still wondering which they are and why they do that...
|
|
#8
April 16th, 2003, 12:15 PM
|
||||
|
||||
|
yea this is very interesting, but damn is it complicated. im still trying to understand what is going on in the code in my above posts. its very strange. when i use integer arrays, i can cause an overflow at [15], but when i use char arrays, i have to go all the way up to [139]! so, this has got me thinking... an integer is 4 bytes, and a character is 1 byte, correct? so in the integer array, [15] is 6 indices past the last "good" one, so that's 24 bytes. in the char array, it is 130 indices past the last good one, 130 bytes? but obviously that is a huge discrepancy (130 to 24), so i cant seem to understand why it behaves that way.
ps. to make it even more complicated... sometimes [139] doesnt cause a fault! and i have to change it to [140]!! wtf??!!
|
|
#9
April 16th, 2003, 12:28 PM
|
|||
|
|||
|
Could be because of this:
Segmentation faults donīt say that you accessed a part of the array that does not exist. It says that you accessed a part of your memory that does not. So: if the array[139] coincidently points to a valid memory address, it will not cause a segfault. For example if other variables are in memory after the array (or code - here we are back on the buffer overflow subject and its security problems)
|
|
#10
April 16th, 2003, 09:59 PM
|
||||
|
||||
|
Quote:
You would probably like http://pageexec.virtualave.net and http://grsecurity.net As far as applications, I think gcc looks for an executable stack (or at least needs trampolines). Also I know that when compiling a kernel with grsecurity, it advises that the executable stack protection will not function correctly if running X. Cool stuff to play with, but counter-productive to infamous' learning  [edit]: hey infamous check out http://www.enderunix.org/docs/eng/bof-eng.txt and http://www.enderunix.org/docs/en/sc-en.txt
__________________
Two things have come out of Berkeley, Unix and LSD. It is uncertain which caused the other.
|
|
#11
April 17th, 2003, 03:02 PM
|
||||
|
||||
|
GNU: wow, great link! that will help a lot in my quest to learn... for some strange reason my teacher doesnt like it when i bring up this idea in class
so i must seek alternative sources!
|
|
| Viewing: Dev Shed Forums > Programming Languages > C Programming > why can't i kill my stack!!??!!?? |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
 |
|
|
Del.icio.us
Digg
Google
Spurl
Blink
Furl
Simpy
Y! MyWeb
Linear Mode
