System Security Introduction to Integer Errors-Integer error in Software Vulnerabilities

System and software security has always been a difficult problem in the security field and has a high learning threshold. Lab mavericks @ reallybobo offer us integer errors in easy-to-understand languages and how to cause Vulnerabilities
Introduction
Integer errors indicate that the developer does not correctly use the Integer variable. In some cases, the value of the variable affects the normal execution of the program and unexpected changes in the control flow, causes some bad results, including program errors, crashes, and even exploitation, resulting in attacks. In the software vulnerability field, buffer overflow caused by Integer overflow is quite common. So many people will always think that the software security problems caused by integer errors are probably the same, including the previous ones. However, recent research has found that integer errors are more complex than I think, and the software vulnerabilities are not only buffe overflow. I will discuss them one by one.
What is an integer error?
Take the C language as an example. Common integer variables include int, unsigned int, short, unsigned short; long, unsigned long. Each type of variable occupies a specific length in the memory, corresponding to a certain value range. Take the VC compiling environment on the common win32 platform as an example. If the unsigned int type variable is 4 bytes, the value range is. Obviously, this may bring about a situation where when the value assigned to the variable exceeds this range, it will be out of bounds (out of bounds ), this out-of-bounds value will generate a new value around (wraparound), which is also known as Integer overflow ). The following simple code is used as an example to demonstrate integer overflow: (the demo environment is Windows 7 + VS2010)
(Example1.cpp)
 

#include "stdafx.h"int _tmain(int argc, _TCHAR* argv[]){    unsigned int number;    number = 0xffffffff;    printf("varible is %u bits \n",8*sizeof(number));    printf("varible'value is %u \n",number);    number=number+10;    printf("Addition: number + 10 \n");    printf("after addition , varible'value is %u \n",number);    return 0;}

Shows the running result:
 

We can see that the initial value of the variable is 0xff ff, and an overflow occurs after 10. The new value is the last 32 bits after the addition and 0x1 00 00 00 09, that is, the value 9 obtained after 32 bits can be considered as mod1. If this overflow is a programmer's plan, there may be no security risks. It is worth mentioning that programmers use this method in large quantities to use new values after overflow, in addition, they often encounter Unplanned things, so the overflow in the plan is not safe [1 ]. So, if this overflow is completely planned? Therefore, this must be a program bug and may have security risks. Especially when an integer variable is involved in memory allocation, it is very likely to cause cache overflow. See the following sample code:
(Example2.cpp)

# Include "stdafx. h "int _ tmain (int argc, _ TCHAR * argv []) {short len; char buffer [20]; len = 0x7fff; len ++; // integer overflow if (len> = 20) // check the length {printf ("Input is too long \ n"); return-1 ;} printf ("length = % hu \ n", len); memcpy (buffer, argv [1], len); // memory copy, buffer [len] = '\ 0'; printf ("% s \ n", buffer); return 0 ;}

It indicates that the length variable of the memory copy is len, and its type is short, which occupies two bytes in the memory. The value range is [-0x8000, 0x7fff]. Therefore, in the above 13th lines of code, the value of the integer variable is out of the border, overflow occurs, and becomes a negative number of 0x8000, bypassing the subsequent length check, resulting in a cache overflow during memory copy. Run the program as follows:
 
In addition to integer overflow caused by out-of-bounds integer values, improper type conversion of integer variables is another major cause of integer errors, because type conversion can basically be counted as the most complex part of the C language syntax rules, many types of conversion are often unexpected to programmers. Here are two examples [2:
(Example3.cpp)

Struct dcon_platform_data {... u8 (* read_status) (void); // };/*-> read_status () implementation */static u8 dcon_read_status_xo_1_5 (u8 * status) {if (! Dcon_was_irq () return-1 ;...} static struct dcon_platform_data * pdata = ...; irqreturn_t dcon_interrupt (...) {int status = pdata-> read_status (); if (status =-1) // {{{}}{{{{{{{{{{{{{}}}?return IRQ_NONE ;...}

This code is a driver in linux-kernel. Check whether the returned value of the read status function read_status () is-1 In line 3. If yes, proceed to the next step. It should be noted that the declaration of this function (in the code of line 4th) defines its return value as u8, that is, a byte's unsigned type, the value range is [0-255]. The Int-type variable status cannot be equal to-1 after receiving the return value of this function. This processing function is essentially a virtual setting. If this is an error processing function, errors cannot be processed and unexpected tasks occur to the programmer.
The following example is even more serious. It also comes from a network protocol program in the Linux kernel. The Code is as follows:
(Example4.cpp)

#define IFNAMSIZ 16static int ax25_setsockopt(...,char __user *optval, int optlen){char devname[IFNAMSIZ];/* consider optlen = 0xffffffff *//* optlen is treated as unsigned:  */if (optlen < sizeof(int))//第一次比较是无符号型return -EINVAL;/* optlen is treated as signed:  */if (optlen > IFNAMSIZ)//第二次比较是有符号型optlen = IFNAMSIZ;copy_from_user(devname, optval, optlen);//拷贝函数...}

This is an error that occurs when the kernel detects the Data Length optlen when receiving user data. We can see that the input parameter optlen has been compared twice: in the first comparison, the sizeof (int) on the right of the comparison statement is unsigned, so the variable is treated as an unsigned integer. In the second comparison, because the right side of the comparison statement is signed, therefore, the variable is treated as a signed integer. Therefore, if the optlen value is 0 xffffffff and the signed type is-1, the two length checks can be bypassed at the same time to reach the subsequent copy function, A length of 0xffffffff will undoubtedly cause cache overflow.
Exploit integer Error
After an integer error occurs, if a security vulnerability is caused, it is often because the integer variable is involved in memory operations. Therefore, cache overflow in this type of vulnerability is indeed the majority, however, starting from the principle, the essential impact of plastic errors is to change the control flow of the program and be separated from the programmer's idea. In this case, other types of security vulnerabilities may occur. The following example [3] illustrates this vulnerability in a widely used multi-media library. The Code is as follows:
(Example5.cpp)

93 static int fourxm_read_header(AVFormatContext *s,94 AVFormatParameters *ap)95 {96 ByteIOContext *pb = s->pb;..101 unsigned char *header;..103 int current_track = -1;//局部变量类型为int..106 fourxm->track_count = 0;107 fourxm->tracks = NULL;..120 /* allocate space for the header and load the whole thing */121 header = av_malloc(header_size);122 if (!header)123 return AVERROR(ENOMEM);124 if (get_buffer(pb, header, header_size) != header_size)125 return AVERROR(EIO);..160 } else if (fourcc_tag == strk_TAG) {161 /* check that there is enough data */162 if (size != strk_SIZE) {163 av_free(header);164 return AVERROR_INVALIDDATA;165 }166 current_track = AV_RL32(&header[i + 8]);//读入一个unsigned int167 if (current_track + 1 > fourxm->track_count) {//判断整形变量是否大于-1168 fourxm->track_count = current_track + 1;169 if((unsigned)fourxm->track_count >= UINT_MAX / sizeof(AudioTrack))170 return -1;171 fourxm->tracks = av_realloc(fourxm->tracks,//内存分配172 fourxm->track_count * sizeof(AudioTrack));173 if (!fourxm->tracks) {174 av_free(header);175 return AVERROR(ENOMEM);176 }177 }178 fourxm->tracks[current_track].adpcm = AV_RL32(&header[i + 12]);//NULL pointer dereference179 fourxm->tracks[current_track].channels = AV_RL32(&header[i + 36]);180 fourxm->tracks[current_track].sample_rate = AV_RL32(&header[i + 40]);181 fourxm->tracks[current_track].bits = AV_RL32(&header[i + 44]);

First, in the Code of row 103, we can see that the type of the local variable current_track is int. In row 3, the variable receives an unsigned int external input, and then checks whether the value is greater than-1 in Row 3. Then, we can construct a number smaller than or equal to-1 to current_track to bypass this check, and the memory allocation in the last 171 rows will not happen, this will cause NULL pointer dereference ). We can see that in the value assignment statement of Row 3, the left-side fourxm-> tracks is a null pointer, and the value of its index cunr1__track is obtained from external input, external Input is on the right. Similar situations exist in the following 179,180,181 rows. Therefore, attackers can construct an input to obtain a wirte four capability in a large range of address spaces, which can hijack the EIP and point it to the shellcode constructed by the input, for more information, see [3 ].
Summary
To sum up, we can see that the system security problems caused by integer errors are more difficult to prevent than the traditional stack cache overflow, while integer overflow is only part of it. Its complexity comes from the fact that C syntax rules often convert variable types beyond the expectation of programmers. The security impact caused by integer Errors often includes a silent failure, to crash, to exploit, and so on. In recent years, the academic research on Integer Overflow has also produced some good results [1] [2] [4 ], fortunately, the first authors of the two articles are all Chinese students studying in the United States.
References:
[1] Understanding Integer Overflow in C/C ++. Will Dietz, Peng Li, y John Regehr, y and Vikram Adve.
[2] http://pdos.csail.mit.edu /~ Xi/kint-osdi12-draft.pdf
[3] A Bug Hunter's Diary. http://www.trapkit.de/books/bhd/
[4] IntScope: Automatically Detecting Integer Overflow Vulnerability in X86 Binary Using Symbolic Execution. Tielei Wang, TaoWei, Zhiqiang Lin, Wei Zou