読者です 読者をやめる 読者になる 読者になる

主に、強化学習

情報系の大学2年生が確率に関連したことを多めに書いてるブログ

Pretty Fuzzing : )

In the first

This world, there are a lot of the vulnerability in the software,web application, iOS ,Android.And we must NOT ignore these, so that we use fuzz test to find vulnerability. I tell you the component about fuzzing ,and let's read this.

The article about fuzzing above is very details to how to advance next stage : )

Main Subject

2.4.1.3 Integer Errors
This class of bugs is commonly referred to as an integer overflow, but this label isn’t completely descriptive. Numerical wrapping, field truncation, or signedness problems might be more descriptive terms. Review the following snippet of code:

The code above is shows the execution of the code. Why does the program crash when provided the string “65536”? Note that the input is cast as a signed integer by atoi(argv[1]). It is then recast as an unsigned short by the “s = i;” code. An int or dword on most systems is 32 bits. The original string input was translated to 0x00010000. Since a short is only 16 bits, that was truncated to 0x0000. Thus, s was less than 10, but i=65536, which is enough to clobber the 10-byte buffer in the memcpy(buf, argv[2], i).
Other similar errors such as a malloc(s=0) could have happened to create a null buffer and a consequent null pointer crash when it was next used in a memory oper- ation. Also, if a number is read in as signed or unsigned, but then used as the oppo- site in a later comparison, similar issues can occur.

Off-by-One

An off-by-one error typically indicates that one too many bytes have been written to a particular buffer. On some systems (particularly little endian architectures, like Intel’s x86 architecture), this can lead to an exploitable condition if the buffer is directly next to the frame pointer (ebp) or some other function pointer.15 A typical bad slice of code might look like:

int off_by_one(char *s) {
char buf[32];
memset(buf, 0, sizeof(buf)); strncat(buf, s, sizeof(buf));
}

The strncat copies one too many bytes, because it copies the stated size, sizeof(buf), plus one extra byte, a NULL or 0x00. Again, if this buffer is right next to the frame pointer ebp, it would become something like 0x08041200. The least significant byte (LSB) became null. An x86 stack wind/unwind is as follows:
1. pushes
a. Puts function argument sonthe stack
2. call
a. Pushes then extexecutable instruction address (return address) to stack
3. entr
a. Pushesebptostack
b. Sets ebp = esp
c. Makes room for local variables on the stack by subtracting that amount
from the stack pointer
4. leave
a. Setsesp=ebp
b. Pops dword from esp → ebp
5. ret
a. Popsdwordfromesp→eip