1) What is the different between putc and fputc
2) Unless you are using a buffer, Is it true that fprintf is better than fputs ?

3) C also has a bunnch of other get and read type as well
and it can get confusing at time. I am trying to stick to one
standard.

=======================================
#include <stdio.h>
#include <stdlib.h>

/*******************************************/

start_processes()
{
FILE *file_pointer, *fopen();
char ETH1[13];

file_pointer = fopen ("/etc/yellowbox/network-config", "r");
fscanf(file_pointer, "%*[^=] %*c %s", ETH1); /* --> ETH1 = 192.168.20.1 */

/******************************************/

file_pointer = fopen ("/root/file_putc", "w");
putc ('5', file_pointer); /* putc write only one character to a file */

file_pointer = fopen ("/root/file_fputc", "w");
fputc ('3', file_pointer); /* fputc write only one character to a file */

/*****************************************/

puts ("puts write many characters to the monitor.");
puts ("putchar write only one character to the monitor.");

putchar ('p');
printf ("\n");

/*****************************************/

file_pointer = fopen ("/root/file_fputs", "w");
fputs ("fputs write many characters to a file", file_pointer);

file_pointer = fopen ("/root/file_fprintf", "w");
fprintf (file_pointer, "fprintf write many characters to a file");

fclose(file_pointer);
}

/*****************************************/

main()
{
start_processes();
}

int fgetc(FILE* stream)
fgetc() returns the next character of stream as an unsigned char (converted to an int), or EOF if end of file or error occurs.

int getc(FILE* stream)
getc() is equivalent to fgetc() except that if it is a macro, it may evaluate stream more than once.

The same case is about fputc() and putc(), BUT pay attention to gets() and fgets(), and puts() and fputs():
char* gets (char* s)
char* fgets (char* s, int n, FILE* stream) /* reads at most the next n-1 characters into the array s, stopping if a newline is encountered; the newline is included in the array, which is terminated by '\0'. fgets() returns s, or NULL if end of file or error occurs */

char* puts (const char* s)
char* fputs (const char* s, FILE* stream) /* writes the string s (which need not contain '\n') on stream; it returns non-negative, or EOF for an error */

Thank you Mohsen for your good answer

But beware of buffer overruns (a major source of bugs affecting security).

gets should NEVER be used, since it does not limit the amount of data it reads, allowing the user to corrupt the memory held by your program, by writing past the end of the array that receives the data. When the program runs at an elevated privilege level (daemons and setuid progs), a hacker may trick it in providing a shell at this elevated privilege level. Use fgets on stdin instead.

Similar remarks for (f)scanf.

Last note: if you dont check user input thuroughly, even sprintf (print to a character array, with printf style formatting) can cause a buffer overflow. Use snprintf instead (and autoconf to check if your target platform has it; remember tomorrow your may be required to run on platforms you have never heard about)

Hi DIYLinux. Thanks for the good advise.

Show me how the user can "corrupt the memory held by the program, by writing past the end of the array that receives the data. When the program runs at an elevated privilege level (daemons and setuid progs), a hacker may trick it in providing a shell at this elevated privilege level. Use fgets on stdin instead. "

How can a user do this. When the C program running is in binary code, he can only do this if he use a global assembler, and that he understand assembly language to alter the program.

Please show me how a user could bypass security step by step so that I can understand what you are saying.

you have to understand a little assembly and know what the stack is but here goes:

when a function is called the return address(the piece of code to go back to when the function is finished) is put on top of a pile called the stack. any local variables such as char x[50] are then put on top of the return address so anything written after the last element of the char array will overwrite the return address. at best this will cause the program to crash by jumping to an invalid memory location. but imagine the person typed in code to spawn a shell into the char array(not very hard to do) then they overwrote the return address to jump to the start of the code, then they have a shell with the privaleges of the hacked program. all that is required to do this is a bit of knowledge and a dissassembler such as objdump.

Hi kev82. Thank you for explaining. I divided what you said into two section. I understand the first section very well and I know what a stack is. On a second section, how does a hacker "typed in code to spawn a shell into the char array" ?


1) when a function is called the return address(the piece of code to go back to when the function is finished) is put on top of a pile called the stack. any local variables such as char x[50] are then put on top of the return address so anything written after the last element of the char array will overwrite the return address. at best this will cause the program to crash by jumping to an invalid memory location.

2) but imagine the person typed in code to spawn a shell into the char array(not very hard to do) then they overwrote the return address to jump to the start of the code, then they have a shell with the privaleges of the hacked program. all that is required to do this is a bit of knowledge and a dissassembler such as objdump.

lets say the instruction you want it to execute is mov eax,0x10 the machine code to do this on x86 is B81000 in hex, now either you can use fancy keyboard techniques to input those 3 characters or you could create a file with the machine code in it and pipe it into the program. or if its a network program then just connect to it on the appropriate socket and send the exact data you want.

Sorry for the delay, but here is some background info on buffer overflows: http://destroy.net/machines/security/P49-14-Aleph-One

Enjoy, but dont abuse