Make your software run: learn basic knowledge about Buffer Overflow

Source: Internet
Author: User
Tags root access

 

This week's column includes some materials originally written by Tom o'connor (Surety. Com's Software Engineer.

For decades, buffer overflow has caused many serious security problems. The most famous example is: in 1988, the Internet worm program infected tens of thousands of machines on the Internet with buffer overflow in fingerd, causing a headache for server administrators in various regions; see references later in this column. However, the buffer overflow problem is not an old history. According to statistics, only last year's buffer overflow accounted for more than 50% of all major security errors proposed by CERT/CC. (CERT/Coordination Center is a department of the Software Engineering Association in Pittsburgh; see references .) And the data shows that this problem is expanding, not shrinking. See "buffer overflow: making a comeback ".

Obviously, you do not think the buffer overflow error will be outdated. So why are there still fatal errors such as buffer overflow? This is because the method of causing a disaster is always surprisingly simple. Some adopt wrong language designs (usually C and C ++), and combine with the poor programming methods of programmers, this will happen. Although modern "secure" languages such as Java that do not have some incredible exceptional programming methods avoid buffer overflow, however, buffer overflow also occurs in non-C and C ++ languages. Under all circumstances, reasonable reasons often prove that the use of languages such as C and C ++ is correct, so it is very important to understand their defects.

The root cause of the buffer overflow problem is that C (and its descendant C ++) is inherently insecure. There is no boundary to check the array and pointer references, that is, the developer must check the boundary (and this line is often ignored), otherwise the risk of problems may occur. Many non-secure string operations exist in the Standard C library, including:

Strcpy ()

Strcat ()

Sprintf ()

Gets ()

 

For these reasons, C and C ++ programmers who are writing demanding security code must educate themselves on buffer overflow issues. The best precaution is a good education on these issues. This is why the following four columns will discuss Buffer Overflow. This topic provides an overview of buffer overflow. The next column will involve defense programming skills (using C) and explain why some system calls are prone to problems and how to solve them. The last two columns of this series will check the engine's work and explain how the buffer overflow attacks are damaged in a specific architecture.

What is buffer overflow?

Buffer overflow begins with some situations required by each program: the space for storing bits. Most computer programs create multiple addresses in the memory for information storage. The C programming language allows programmers to create memory in two different parts of the memory (stack and heap) at runtime. In general, the data allocated to the heap is those obtained at malloc () or new creation. The data allocated to the stack generally includes non-static local variables and all passing parameters by value. Most other information is stored in Global static storage. (From now on, we will discuss their substantive details in two columns .) When an adjacent block of the same data type is allocated, this memory area is called a buffer area.

When writing a buffer, C programmers must note that the data stored in the buffer cannot exceed the amount it can hold. The buffer zone can only hold a certain number of places, just like a cup can only hold a certain amount of water. If there is too much water in the cup, the excess water will overflow to other places. Similarly, if you try to put more data into the buffer than it can load, the extra data will overflow elsewhere and you don't want it to be elsewhere!

When the write speed of a program exceeds the boundary of the buffer, this is the so-called "buffer overflow ". When a buffer overflow occurs, the next adjacent memory block is overwritten. Because C language is inherently insecure, it allows programs to overflow the buffer at Will (or, more accurately, by accident. There is no runtime check to prevent writing from exceeding the buffer end. Therefore, the programmer must execute this check in his own code; otherwise, the programmer may encounter problems when continuing.

When reading or writing data beyond the end of the buffer, it may lead to many different (and usually unexpected) behaviors: 1) program execution is strange, 2) the program fails completely, or 3) the program can continue, and there is no obvious difference in execution. The side effects of buffer overflow depend on:

The number of data written exceeds the buffer boundary.

What data is overwritten when the buffer zone is full and overflows (if any)

Whether the program tries to read the data overwritten during Overflow

Which data will replace the overwritten memory?

The uncertain behavior of programs with buffer overflow makes debugging on them very tricky. The worst case is that the program may be experiencing a buffer overflow, but there are no signs of side effects at all. Therefore, the buffer overflow problem is often not found during the standard test. An important aspect of understanding of buffer overflow is that in the event of overflow, any data that happens to be allocated near the buffer will be potentially modified.

 

Why is buffer overflow a security issue?

You may think: "What's the big deal? A little water overflow will not cause harm to anyone ." Let's draw a little deeper by analogy. Imagine that water overflows on a workstation with many exposed wires. Sparks are scattered everywhere Based on the splash location of water drops. Similarly, when a buffer overflow occurs, additional data can destroy other useful data that may be accessed by the program in the future. Sometimes, changes to other data may cause security issues.

The simplest case is to allocate a Boolean sign directly to the memory behind the buffer zone. This flag determines whether the user running the program can access the private files. If a malicious user overwrites the buffer, the value of the flag is changed to indicate that the attacker is illegally accessing a private file.

Another way to cause security problems due to buffer overflow is to destroy the stack. The purpose of stack destruction is to cause a specific programming failure: the data buffer allocated to the stack when the program is running is not carefully used, that is, local variables and function independent variables. The effect of effectively destroying the stack is more serious than that of modifying the Boolean Access Control flag mentioned in the previous example. Creative attackers can exploit the weakness of buffer overflow by destroying the stack and then run any code. This idea is quite straightforward: insert some attack code somewhere (for example, the code that calls shell) and overwrite the stack by passing control to the attack code. (We will discuss stack destruction in detail in the third and fourth columns of buffer overflow .)

Generally, attackers exploit the buffer overflow to obtain the interactive session (shell) on the machine ). If the exploited program runs with a higher priority (such as root user or administrator), the attacker will obtain the priority in the interactive session. The most striking buffer overflow is the destruction of the stack, which can cause consequences in the superuser, root, and shell. Many scripts can be found on the network (see references) to destroy stacks on a specific architecture.

 

Buffer overflow: making a comeback

According to the analysis in a paper published by David Wagner, Jeffrey Foster, Eric Brewer, and Alexander Aiken at this year's "network and Distributed System Security" Conference (NDSS2000, up to 50% of the currently widely used weak links are buffer overflow. Moreover, the analysis shows that this proportion is increasing over time. This data is quite frustrating because the buffer overflow problem has been noticed in the security field in recent years. For some reason, developers have not actively promoted the elimination of buffer overflow, a major security trap for software.

 

Number of vulnerabilities that CERT/CC has suggested in the past 11 years

 

 

The table shows the number of weak points that can be directly classified as buffer overflow. As the data shows, this problem has not improved. In fact, buffer overflow is becoming more and more common.

 

Comparison Between Stack Overflow and Stack Overflow

The exploitation of heap overflow is usually more difficult than Stack Overflow (although some successful Heap Overflow attacks exist ). For this reason, some Programmers never allocate a buffer statically. Instead, use malloc () or create everything, and believe that this will prevent overflow. They are usually right, because not many people have the expertise needed to exploit heap overflow. However, Dynamic Buffer Allocation is essentially not more secure than other methods. Do not forget the buffer overflow problem by dynamically allocating everything. Dynamic Allocation cannot solve all problems at all.

This gives us a deeper understanding of the causes of serious security risks caused by buffer overflow. Many interesting UNIX applications require special permissions to complete their jobs. They may need to write to a location with certain privileges (such as a mail queue directory) or open a network socket with special privileges. Such a program is usually suid (set uid) root, that is, even if regular old users run the program, the system will expand the special permissions to the application as requested. From the perspective of security, granting privileges (even temporary) at any time has the potential to expand privileges. Therefore, when the privilege is extended, successful buffer overflow attacks reach the extreme. Many well-used UNIX applications, including lpr, xterm, and eject, are abused, and the use of buffer overflow in the suid area of the Code gives up the root permission.

The common destructive technique is to find the buffer overflow in the suid root program, and then use the buffer overflow to steal the interactive shell. If the program runs with the root permission and runs the script, the attacker will get the root shell. Using root shell, attackers can perform any operation, including viewing dedicated data, deleting files, setting monitoring sites, and installing backdoors (using the root Toolbox) edit logs to hide traces, disguise as others, and accidentally destroy materials. Terrible.

At the same time, many people think that if their program does not run suid root, they don't have to worry about security issues in their code, because it won't give the program a higher access level. This idea is partly correct, but it is still a dangerous claim. One thing, you never know who will execute your program and set the suid bit in binary. When people cannot get something to work correctly, they will become desperate. We have seen that this type of situation will cause the entire directory of the program to be set to suide root without any need. Again, this is terrible.

Some software users have no privilege at all. This means that any successful buffer overflow attack will give them more privileges than they used. Generally, such attacks involve networks. For example, buffer overflow in network server programs that can be exploited by external users may cause attackers to log on to the machine. The generated session has the privilege to run processes that compromise network services. Such attacks can occur at any time. Generally, these services run with root permissions (and usually use privileged low ports ). Even if such a service is not run with the root permission, once an attacker obtains an interactive shell on the machine, generally, it is only a matter of time for an attacker to gain full control over a machine, for example, root access on a UNIX operating system or administrator access on a Windows NT operating system. This control is generally obtained by using an interactive shell to run another script to expand the privileges.

 

Scope of real-world problems

Unfortunately, buffer overflow is too common in C Programs. As described above, even well-used and carefully checked programs are prone to buffer overflow.

For example, Sendmail, an email service program, is one of the most widely used programs on the Internet. It is well known for its security problems. Many people use this software, and many have carefully checked it, but are still discovering serious security problems (including buffer overflow ). Extensive manual security reviews were conducted in September 1996 after several new available buffer overflows were found and corrected in Sendmail. However, in less than four months, another usable Buffer Overflow missing during manual review was discovered.

More recently, David Wagner, a graduate student at the University of California at Berkeley, found some new buffer overflow in Sendmail this year (see references ). However, the overflow he found does not seem to be usable. In other words, it seems that no buffer zone is vulnerable to arbitrary overflow by the input of a savvy attacker (usually as a requirement. Nevertheless, at least one overflow found by the Wagner was not manually reviewed since 1996.

In addition, because well-trained security experts say this error "seems to be unavailable", it does not mean that it is not available. In 1998, researchers from Reliable Software Technologies (not authors) used a fault injection tool named FIST to discover three buffer overflow conditions in wu-ftpd (Washington University ftp daemon) version 2.4. (When we discuss dynamic analysis, we will visit the FIST series again later .) This is very interesting in itself, because wu-ftpd has recently conducted a lot of checks after four CERT suggestions on wu-ftpd made between 1993 and 1995. Experts from Reliable Software Technologies have detected potentially vulnerable code and fail to master methods to exploit any situation. They declared that they could successfully manipulate user input to reach the vulnerable buffer zone, resulting in minimal security damage. Then, one year later, a new CERT proposal about wu-ftpd appeared. One of the three Buffer Overflow Detected by them proves that this is completely a weakness!

These anecdotes explain how difficult it is to perform manual analysis! From the root point of view, the code is often complex. Analyzing large programs (such as Sendmail, there are about 50,000 lines of code) is not a simple task. The problem often leaves the careless developer side, but the problem also slides by the expert side.

 

Comparison between Windows and UNIX: is obscure security good?

Currently, all examples of buffer overflow are for UNIX systems. However, we do not want to omit Microsoft Windows! The possibility of a large number of buffer overflow also exists on Windows machines. Recently, a company named eEye found that Microsoft's "Internet Information Service System (IIS)" has an available Buffer Overflow. This vulnerability completely opens up about 90% of Web servers running Windows NT for "possession" by any script personnel ". (Script personnel are future hackers who have sufficient knowledge to run pre-encoding scripts on vulnerable machines, but do not have enough knowledge to create such scripts .) For more information, see "run your software" in the first column .)

Some people think that it is more difficult to find Buffer Overflow in Windows programs than in UNIX programs. This is true, because Windows programs often do not carry source code delivery, while UNIX programs do with source code delivery. When the source code of the program is available, it is very easy to find potential Buffer Overflow (or further, most security flaws ). When the source code of the program is available, attackers can find all suspicious function calls and then try to determine which vulnerabilities are. By viewing this program, attackers can easily figure out how to use the actual input to cause buffer overflow. When there is no source code, more skills are required to do these tasks (it may require some luck ).

Without releasing source code, security issues are often called "obscure Security ". However, relying on this security is not a good idea, because if there is a problem with the code design first, skilled attackers can still destroy it. A better solution is to write reliable code to let others know what you are doing, so that they can help you identify the vulnerability to ensure its security.

Many Windows developers still rely on obscure security models whether or not they know this. Generally, they do not know this because they have never really considered security when developing their applications. In this case, they blindly rely on flawed methods.

Security experts generally think that Windows code has more buffer overflow problems than UNIX code. This reasoning can be classified as a phenomenon that many people pay attention to. This phenomenon means that open source software can often perform better checks and therefore be safer. Of course, there are some warnings. First, let people view your source code and there is no guarantee that errors will be found. Secondly, for Windows, there are also a lot of open source software, while for UNIX machines, there are at least a lot of software with closed source code. For these reasons, this phenomenon is not related to the architecture.

 

Conclusion

This topic describes buffer overflow, which may always be the worst software security issue. There are no suggestions on how to avoid these problems in your own program. Besides, we only mention the actual details about how Stack Overflow occurs. Fortunately, these issues will be discussed in the next column.

 

References

 

 

  • M. Eichin and J. Rochlis, "With microscope and tweezers: an analysis of the Internet virus of Nov. 1988," 1989 IEEE Symposium on Security and Privacy, Oakland, CA
     
  • CERT/Coordination Center is a department of the Software Engineering Association in Pittsburgh.
     
  • D. wagner, J. foster, E. brewer and. aiken, "A First Step Towards automatic Detection of Buffer Overrun Vulnerabilities," 2000 ISOC Network and Distributed Systems Security Symposium (NDSS2000), San Diego, CA
     
  • DeveloperWorksIn the first "run your software" column, Gary and John introduced their security theory and explained why they focused on software security issues for developers.
     
  • DeveloperWorks"Make your software run: Make sure the software is secure", where Gary and John demonstrate the five steps they designed for security.

 

Author Profile

Gary McGraw is vice president of corporate technology at Reliable Software Technologies, based in Dulles, Virginia ). He is engaged in consulting services and research and helps determine the direction of technical research and development. McGraw started from a research scientist at Reliable Software Technologies and focused on Software engineering and computer security. He has a dual-Doctorate Degree in cognitive and computer science from Indiana University and a bachelor's degree in philosophy from the University of Virginia. He has written more than 40 articles for technical publications that have passed peer testing and served as a major e-trade supplier, including Visa and Federal Reserve consultants, he also served as chief researcher under the sponsorship of the Air Force Research Laboratory, DARPA, the National Science Foundation, and NIST's advanced technology project.

 

McGraw is a well-known authority in mobile code Security. In partnership with Princeton's Professor Ed Felten, McGraw wrote "Java Security: Hostile Applets, Holes, & Antidotes" (Wiley, 1996) and "Securing Java: Getting down to business with mobile code" (Wiley, 1999 ). McGraw and Dr. Jeffrey Voas, one of the founders of RST, wrote "Software Fault Injection: Inoculating Programs Against Errors" (Wiley, 1998 ). McGraw regularly writes for some popular commercial publications, and its articles are often cited in national publications.

John viable is a senior associate researcher, one of the founders of the Software Security Group, and serves as a senior consultant for Reliable Software Technologies. He is the principal investigator for developing standard programming language security extensions sponsored by DARPA. John has written more than 30 technical articles on software security and testing. He is responsible for finding some well-known security weaknesses in major network and e-trade products, including recent vulnerabilities in Netscape security. He is also an important member of the open source software community, I have written Mailman, GNU Mailing List Manager, and recently released ITS4 (a tool for finding weak security links in C and C ++ code ). Visung has a master's degree in computer science from the University of Virginia.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.