So now, I want to talk to you about the integrity threat or modification threat. The threat that somebody might be corrupting an asset, a piece of software, a system, whatever, for malicious purposes. And the obvious example here is malware. That's where code that has some presumed correctness or validity, has that corrupted by a malicious actor putting malware into your system. Integrity threat. And how in the world would you do something like this? Well,again, it's the permissiveness of the CPU memory model that's been in computing since we've had computers. This idea that I can take code and I can manipulate it, and make it do other things by just shifting and changing. We don't have rigidity in computing, we have the ability to make modifications to solve or think about that. There's absolutely fundamental to this whole thing. If you drove up in a car into my driveway and you say, "Here's my new truck, there it is, what do you think?" How easy is it or would it be for me to make fundamental modifications to that truck? Probably not easy, right? It's hardware. Those components are all connected up. Maybe if am a genius mechanic, I can make some changes but it's certainly not a flexible easy environment for making changes. Software is different. If I show you a piece of code and I say, "Hey, what do you think?" And you look at it you want to make some minor changes to it, we're well set up for that. And one of the problems that occurs frequently in programming is the handling of buffers. Now, here's something for those of you who are programmers who we'll be very familiar with this idea. We use scratch, space and memory, a lot of our programs to keep track of things. So for example, if I'm pushing to a stack and I want to add things then what I might do is I might push the first value to a little scratchpad in memory that I push the second value to that scratchpad in memory and then my program might pop the first one, pop the second, add them and then push the answer on to this buffer, onto this stack, onto this Scratchpad in memory. So we're constantly using memory to do things. One of the things that was invented with computers, is if I look at a full list of memory in a computer, then what we typically do is, we reserve some portion of that for the programs you run, and we reserve some portion of it, for the data that your program uses. That make sense? Memory keeps track of programs and data, all in the same place. I guess it's in different places in memory, but it's as seems sort of linear progression through memory. It's a basic weakness that we've had in computing since the beginning. Here's the way programmers might cause an integrity threat through something we would call a buffer overflow. The way that works is, up here in your program, I'm reserving somewhere a little piece of scratchpad to do something, and I reserve a little piece of memory where I'm going to put some array of you know, 10 characters or something. But what I do really is the program then, instead of just putting a variable that's within those bounds, I put some gigantic thing into it, some gigantic piece of data that not only fills up the buffer scratch space that you put in there, but overruns and starts causing all kinds of problems in memory. And what's going to happen to your program, it's going to go, it's going to explode or crash. And again the way computers work is that when your computer crashes, the program counter goes to something called an exception handler. That's why computer works. Program runs and it goes for whatever reason and the computer goes, "Ah, what do I do?" Well, the designer says, "Well, what do we do whenever something crashes? Let's put the program counter here and run this code to recover." You got that? Program crashes, program counter, recover. Okay? Now, what if and this is going to sound crazy but this way it works. What if instead of overwriting the buffer a little bit, I really overwrite the buffer. I mean, overwrite it all the way down to the point where I find the recovery procedure and then where the recovery procedure is, I put a piece of code that I want to execute. You got that? So, here is the idea, I overwrite the buffer and I overwrite it with we will call it no app. Put a bunch of things in there that really don't execute but just start filling up memory with no apps. I get two or even go past where the recovery procedure is and then I put code at the appended part of that no app bridge, that runs what I would like to do, maybe copying me a shell. So now, here's what happens or in a program. I overflow buffer, the buffer overflows with a no app bridge that fills-up memory and then has something I want to run. The whole computer goes crashes. Because, I'm like guys on line everything goes haywire. The program counter goes down to the recovery memory address, but I've overwritten that with no apps, it's going to ride the no app bridge, find my piece of code executed and I probably now own your machine, because I put code there on the machine. Isn't that clever? Look, there are a lot of resources on the internet, and we'll make sure as part of the support environment here for this lecture, that you have some things that we recommend that you take a look at, including a great paper called, smashing the stack for fun and profit. You can take a look at and you can dig in and try to understand buffer overflow in a little deeper level. But, I think you probably get the idea here that integrity threats generally involve problems in memory, the fact that data and programs are all sort of inners burst, and I can have things over right and I know where control will go when things crashes and on and on. I can take advantage of these things to cause integrity problems in computer system. So, to ponder that, think about that a little bit and we'll see in the next one.
