In this unit, we will consider low-level software security, which is a concern for systems written in a C and C++ programming languages. We will begin by considering the infamous buffer overflow attack, which low-level software is vulnerable to in particular. What is a buffer overflow? A buffer overflow is a bug that affects low-level code, typically written in C and C++, with significant security implications. Normally, a program with this bug bug will simply crash, but an attacker can alter the situation, and cause the program to do much worse. Allowing the attacker to steal private information, to corrupt important data, and even to run code of his choice. It is worth studying buffer overflows for several reasons. First, they are still relevant today. C and C++ are used to write a lot of software. And that software often has buffer overflow vulnerabilities. Second, during their long history attackers and defenders have played a game of cat and mouse. As defenders address one weakness, attackers find a way to work around it. We will find it instructive to understand the technical details of that long history. To see how the attack works and how to defend against it. Lessons we learn here will be relevant to other software weaknesses. So, let's dig in a little bit further to the relevance and history of buffer overflows. First, this chart shows that C and C++ are still very relevant today. The chart comes from a recent study done by IEEE Spectrum magazine. To come up with their ranking, they looked at new and active open source projects hosted on sites like GitHub. And also looked at Google keyword searches among other data. Considered all together, the evidence supports C and C++ is two of the top three languages used today. Therefore, any vulnerabilities particular to these languages, as buffer overflows are, are quite relevant to a good understanding of cyber security. What software is written in C and C++? Some examples include operating system kernels. High performance servers, such as web servers and database servers. And embedded systems, which appear in cars, airplanes, industrial control systems, and, even the Mars rover. These systems are all of critical importance. They are the platform for computing, and they drive our economy, and ourselves, from here to there. A successful attack on these systems has tremendous consequences. The first buffer overflow attack occurred in 1988 and was carried out by a student named Robert Morris. This attack was part of a self-propagating computer worm that replicated itself across the internet. Once it compromised one system, it would gain a foothold there and try to launch an attack against other systems. The attack worked in part by sending a special string to a server called Finger D, that was vulnerable to a buffer overflow. This string contained code that would help carry out the attack. In the end, the attack infected a significant portion around 10% of the nascent Internet. Causing a tremendous amount of damage due to denial of service. Morris was eventually caught and had to pay a fine, serve three years probation and carry out 400 hours of community service. Since the Morris worm many other worms have been developed some of which have exploited buffer overflows. One example is CodeRed which came out in 2001. It's exploited the vulnerability in Microsoft IIS web server and spread rapidly across the more larger internet. In fact, the worm was one of the elements that prompted Bill Gates, then Chairman of Microsoft to write his now famous memo. Exhorting the company to take security far more seriously and to develop a platform for trustworthy computing systems. Unfortunately for Microsoft, another big attack occurred in 2003. With the SQL Slammer worm infecting a huge number of machines running Microsoft's SQL server. The infections took place in a matter of minutes. Changing the culture and practices at a huge organization like Microsoft takes time. Microsoft has made significant strides since that time. And many of the practices and ideas that we will consider in this course are ones that they developed. Or that they have taken to heart. Now buffer overflows are pernicious. As evidence consider that in early 2014 a buffer overflow vulnerability was discovered in the code of the X11 server. Which was an early leader for standardized support for graphic desktop displays. And it forms the formation of remote desktop technology today. That bug that was discovered in 2014 had been latent in the source code for more than 20 years. And indeed, despite the increased knowledge of how dangerous buffer overflows are. And the attention paid toward defending them. The number of reported vulnerabilities continues to rise. So, here's what we'll do. For the rest of this unit, we'll learn how buffer overflows work and then learn various ways to defend against them. For a complete understanding, we'll need to look at how a compiler produces executable code from C source programs. And how the operating system and architecture work together to run these programs. We'll see that knowing these details an attacker can exploit bugs and how the program utilizes memory in order to attack that program. In general, security often requires a whole systems view. And out study here will be an example of that. Before proceeding I'd like to make a note about terminology. I use the term buffer overflow to mean any access of a buffer outside of its allotted bounds. This access could be an over-read or it could be an over-write. It could occur during iteration across each element of the buffer, for example, running of the end. Or by a direct access, through a direct index of the buffer. The out of bounds access could be two addresses in memory that either proceed or follow the buffer. All of these things I'll consider broadly as a buffer overflow. Now others sometimes use different terms to refer to specific instances of buffer overflow that I have listed above. They might reserve the term buffer overflow to refer only to actions that write beyond the bounds of a buffer. And they might use terms like buffer underflow, buffer over-read, or out-of bounds access to be more specific. Throughout this course, when I use the phrase buffer overflow, I use it typically in the most general sense. And more specific uses can be determined from context.
