Just an idea. As far as syslog is concerned, maybe there isn't any extra space being allocated. Take a look at syslog.h and see how many variables are being declared. Theres a crap load of them. You may just be overwriting those variables before you end up hitting the stack. Wish I could find the source for the syslog function.
-----Original Message----- From: Ted Kat. [mailto:[EMAIL PROTECTED] Sent: Saturday, February 21, 2004 1:57 PM To: [EMAIL PROTECTED] Subject: RE: [sclug-generallist] buffer overflows --- "Dennis K. Paulsen" <[EMAIL PROTECTED]> wrote: > Hello, > > In the C language, the result of a buffer overflow is supposed to be > an undefined behavior. On occasion, the program might crash. Other > times, it might simply not produce the results you expected it to. > And a lot of times, in simple programs, nothing will happen (at least > noticable).... > > One of the reasons for the undefined behavior might be the memory > "map" of a typical program. As far as a compiled C program, there > are generally four distinct regions of memory that get utilized. The > first region holds the executable code (code segment). The second > one is where global variables are stored. The other two are the > stack and the heap..... > > Per the latest example below, there are three global variables... > The memory is likely being contiguouslly allocated between the three, > so when you overflow one buffer its just spilling over to the memory > allocated for the other two variables.... > > Actually, that may explain the output being seen. If you were to > move the "printf("string::%s::\n", s);" underneath the first strncpy, > you'd likely see the first 12 or so characters from Some_String[] > inside of s[]; which makes more sense, but in its current > incarnation, the second strncpy looks like its filling up string[] > and then naturally overflowing into s[]. That's why s[] no longer > contains the first several characters of Some_String.... In this > case, since the memory is "there" and not being critically used for > something, no segfault occurs. > > I hope that makes sense.... > > > Regards, > Dennis K. Paulsen Makes complete sence. By going thru those example programs with gdb I was able to see exactly what was going on with the global variables. Like checking out the stack and the data segment. So I know whats going on with the buffer overflow. I guess I have two questions still. Why was the extra space alocated could this space be linux standard or gnu standard? And what in syslog() created the segfault in `95. Does anyone remember? Back in `95 I was just an AOL script kiddy :) ===== Ted Katseres ---------------- ------------------------ -------------------------------- __________________________________ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
