Ok,

let have a little talk about programming your very own exploit. Im sure right now your freaking out, screaming why the f**k would you wanna do that. Ill tell you why, cause you can thats why.

When you have a program or a function with the gets() , its consider dangerous . So lets say you have this code.

#include<stdio.h>

main()
{

char name;
char crap;

crap = "darkseed is the man ";

crap = (char*)malloc(10);
name = (char*)malloc(128);

printf("mem addy for name %d " , name);
printf("mem addy for crap %d", crap); /* this is so we know where the address is */

printf("what is your name : ");
gets(name);
system(crap);

}

compile and run

now where it asks you for a name enter 16 charatercs plus a command
for instance /bin/sh

that gives you a command prompt with the users access

but if you noticed, when you compiled it tells you that gets() is a very mean and dangerous little function

but if you did that same program , but instead of gets() lets use scanf()
same thing it works , you can do the same thing because neither one of them check for outofbounds data. The only secure one that i know of is , fgets() cause you can define how much date the user enters , out of bounds check.

Now, my question to you guys is, why the hell doesnt the gnu gcc compiler tell me that scanf is also a dangerous function. cuase that creates a very false sense of security. Cause on a daily basis, i see many programs and deamons that have a scanf function. That are very exploitable. Why doesnt it tell me that its dangerous and that it should be replaced with fgets()

Any takers

I just wanted post another thing.

Just like most things in open source, it just does what you tell it to do. The software isn't going to hold your hand and tell you what you can and can't do. I guess it falls under the same logic as why you could delete your entire /etc directory and Linux won't have some dumb-ass dog or annoying paper-clip pop-up and say "Hey idiot, if you do that you'll break stuff!!"

Certain functions can be safe to use in certain implimentations, while horribly insecure in others. It's up to you as the programmer to have the sense to know what is safe and what's not.

That was very well put . But it seems the more books I read and the more i learn about programming, I just seems all whacked. I mean I have these books that tell me to use the scanf and gets functions like there candy or something. They dont teach you or even remotely tell you that if you use them in your software that you and maybe even 100000's of computer can be affected. I wish the writersr would have more sense towards security. I mean seriously , how hard would it be to write a book on safe , secure and effective code. I think its cause there lazy. Im gonna start writing a book on secure programming.

scanf() can be controlled, you can specify the number of chars to be accepted, if a user trys to enter more than specified, they remain in stdin buffer until you next call scanf().

When using scanf(), read in a set number of chars with %20s for example, and immedialty after the scanf(), call fflush() to flush the unread data out of the buffer.

Jason

It does seem like most introductory programming is taught without consideration of security concerns. I know from my experience we used gets() and scanf() all the time without the slightest mention of why that might be a really bad idea or even a mention of the concept of input validation. I think the model is just get the basic concepts through and then save more "esoteric" things like security for advanced courses and security focused books. I've seen a couple of books around on secure programming that looked interesting, but I haven't gotten a chance to check any of them out yet. If I see one at Amazon.com by darkseed2g3, I might check it out

I've seen some things that work against this, I belive libsafe.so.2 is one. You put it in LD_PRELOAD or the /etc/ld.so.preload file and it will actually re-work some of your code during linking if you make a meany by mistake (or on purpose even). I was playing with some shellcode examples, and I noticed on my machine, even though I followed everything 100% to the example, when I looked at the GDB disasm dump of the code, it included a few extra instructions to check stack param's. I guess there's a way to step around this, but any extra protection is better than none at all right?
Now you know your calling (original poster of topic)- to design codes, libraries, patches, and other security features to help turn this trend around. Many programs include potentially dangerous code, and at this time exploits involving buffer overflow, formate string, and stack-smashing are very popular. Back when I was into Windows/DOS Intel x86 Assem. programming, a function that pushed or popped too much data off the stack and left you to return god-knows-where was considered a bug, not a feature, but hey, I guess times are a-chang'in...

-jayjwa

I guess there's a way to step around this,
Compiling static.

but any extra protection is better than none at all right?
Yes. Just mind single point of failure situations.