As I mentioned earlier, the difference is important
in the sense that a robust program deals with
whether or not it'll crash, whether or not it
can be corrupted to do something it shouldn't do, and so forth, but it doesn't necessarily deal with
the violation of security. A secure program is both robust and handles any
violations of security. So a little bit more
formally on the next slide, robust programming is
a style of programming that prevents abnormal termination
or unexpected actions. In other words, if
the program does what you want it to do, it's robust. If however an error occurs, it has to be able to handle
that error gracefully. For example, if it
can't open a file, it shouldn't just immediately terminate without any message. It should say something
to the effect of cannot open file XYZ and then exit. If it asks for a number between one and 10 and you type in 53, the program should give
you an error message saying input must be between one and 10 or
something like that, and then either ask you for
more input which would be the preferable way to do
it or it should terminate. Now, programmers never like
to admit they make errors within their own
programs. Some of us do. But programs are rarely
maintained by one person, they're often
maintained by a team, and unless communication
between the team throughout the lifetime of
the program is excellent, there will be
internal inconsistencies. For example, in one part
of the program, you may expect a variable
to have a value of somewhat an integer
between one and 10, and you get that integer
by calling a function. Well, another team may be
maintaining the function and they realize they need
to add an extra case. So now, the varied function
can return one through 11, but if the first part of
the program is not updated, when that 11 comes
in, what happens? What the program should
do is catch that, and that's not
something the user can help because it's
generated internally. So at that point,
the program should state to the user internal error
and give a little bit of information so
the user knows what to tell the customer service, or complaint department,
or quality assurance, or whoever about what
the problem was. Then, if possible that
your program should recover, and if not, it should
terminate gracefully. The opposite of
robust programming is non-robust or
fragile programming. That's basically, for example, if the program requests
a number between one and 10, and someone types in
53, it says, "Oh, that's bigger than 10
so we'll just go with 10" or "Oh, that's a bad input, I better crash" or
things like that, or if you're asks
the user to type in, the user can type in
up to 100 characters and the user types
in 200 characters, and the program does
something unexpected or crashes or whatever,
that's non-robust. You'll see a very
strong example of this a little bit later in
this particular course. Now, secure programming,
security is a strange word. It has no intrinsic meaning. Security is defined by the
security policy of your site, and so a secure program
is when that conforms to the security policy. Implicitly, this means
it's also robust. In addition to being robust, your program also
has to ensure that the behavior satisfies
the security policy, and in most cases, that requires some knowledge
of the environment. In this course and in
the other courses, what we will do is talk about security in
a general sense. So for example, pretty
much all security policies say you cannot acquire extra privileges
without authorization. So what we'll do is
we'll talk about how people could
do that acquiring extra privileges
from your program when you don't intend
them to do so, and then you'll have
to decide how to apply this knowledge to the particular environmental programs
you're working in. Here is a perfect
example of what I'm talking about, buffer overflow. If you recall, a buffer is simply an area of memory in which
you're writing some data, usually text or binary data, and it goes into an array
or a list or whatever you're programming
construct in your programming languages. Now
though, it's limited in length. For example, it may allow
up to 100 characters. What happens if someone
types in 200 characters? Well, it depends. If the program has
no extra privileges, so in other words, when this
buffer overflow occurs, the program is still
running as the user, as me for example, then it will either crash or it will allow me to do things
the program doesn't intend. That's an issue of robustness. But since it's not
escalating privileges, and I'm not running and I'm
not doing anything as root, then it's not a security issue. But if I run it as root, it may or may not be security issue depending on
how your policy is framed. If, however, as an ordinary user, that program reads in the input and then does
things with the input, and the program adds privileges
to me, so in other words, I get extra privileges
when I'm running the program for the lifetime
of the program, well then the buffer overflow can trick the program
into changing variable values or writing
to files it shouldn't doing, or spawning programs it
shouldn't like a subshell. At that point, I can do things that I normally
would not be able to do. I can do them with
the privileges of the program. That's an example of a non secure programming
because the program directly affects
the security of the system and it's violating
a security policy. Okay, next question, who cares? Programming is that programs
have always been bad. So who cares? Well, in the past, the people who cared were
those were affected by programs and computers
weren't that widespread. Nowadays, they're ubiquitous. They're even in our bodies
as medical controlling, medical devices like pacemakers. If you have a bug or a security
problem with a pacemaker, the person who has it is going
to have a lot of trouble. For example, if I
am able to tell the pacemaker," Instead
of 72 beats a minute, go to 300 beats a minute, or go to zero beats a minute", that person is going to be
either very sick or die. I'm not a doctor so I'm not sure what the effect would be. For zero beats per minute, I'm pretty sure it's death. Three hundred beats a
minute, I don't know. This in fact has happened
with medical equipment. Not the pacemaker example, although that wants to be
demonstrated in the lab. But there are a number of cases where there were
problems with software or software and hardware
interaction that have caused fatalities
among medical equipment. I'm thinking primarily
here if there are 25 but there have
been many others. As another example, do you ever buy anything over the web? If you do, you're using a communications mechanism that secures the communication
between you and the website. Nowadays, this is typically TLS. A protocol known as TLS. Up until very recently
like a year ago, it used a protocol called SSL. Furthermore, many commercial sites used
freeware known as OpenSSL, which implemented
both TLS and SSL. It turned out that
there was a bug in the way the OpenSSL
was programmed, which we'll talk about a little bit later, called Heartbleed. That enabled you to
grab from the server, data that could easily include other people's cookies or
passwords and accounts. Basically, this was
a massive buffer underflow. What would happen is,
the client would send a message to the server
saying,"Are you awake?" The server would load that into a buffer and send back
the contents of the buffer, and by crafting a very
particular type of message, instead of returning for example, the ten characters that
it would normally return, all 65,000 characters in the
buffer would be returned, including things
that had passwords, account names, cookies,
and things like that. So, that's an example of
a very current type of attack. By the way, an amusing note
about Heartbleed, the term comes from Heartbeat, which is the name
for the protocol that says, "Are you awake?" Or rather, "Are you still there?" This was advertised or described in many news reports as
death of the internet. Of course, we've heard that
before, never happens. But it was a very serious bug. Third example, electronic
voting systems. When you vote, the votes are counted or stored on
carts and counted. What happens if there's a security vulnerability on those? I'm able to exploit that vulnerability to
reprogram the machine, the machine you vote on, so that every time
you vote for say, "George Washington, it records it is vote for John Adams." Now, there are
environmental issues here. Those machines for example are not connected to the Internet, but if I load a fix onto them, I could possibly load the wrong fix onto
them, and so forth. It is known that these
systems have severe problems, ranging from buffer overflows
to everything else. In the California
Top-to-Bottom Review, all of the machines certified
for use in the state of California were compromised
in one way or another. Same thing happened in Ohio
with the EVEREST study. Given that voting is
the basis for our democracy, for any democracy and
any republic for that matter, because the United
States is in fact a republican out of democracy, this means that we really depend on the accurate recording
and counting of votes. So, security issues
in software and in hardware for elections
are paramount. Therein lies the problem, we don't build systems that
meet security requirements. In fact, a lot of
times we don't even think what the security
requirements are. We don't write software
that is robust. Now, I should qualify that
in their special cases. For example, the Space
Shuttle software that NASA used was highly robust. In fact, it was
very high assurance code. Similarly, aviation code goes
through a lot of scrutiny, and is written in
particular ways to try to ensure reliability, and availability, and
the lack of problems. Software that's used in
satellites is exactly the same because you can't very well go up and reprogram the thing, you have to reprogram
it from the ground. If the satellite is
halfway to Mars, you want to be sure that
the software is in good, enough shapes, I'll
allow you to do that, reprogram your retargeting. Now, there are
many different models for developing software. We won't go into them,
other than to say, "For example, Agile is the one that's currently
the most popular. It's a form of rapid prototyping. Waterfall model is a more
traditional one. It's slower. From the security point of view, Waterfall model is probably
the one that will give you the most assurance
because you're doing a lot of reviews on the way. With Agile, the focus is getting
it out the door quickly, and getting it the way
the customer wants. Programs that are developed
using Agile programming can be very secure,but typically, the security checking is
done after the fact or at the very end whereas with the waterfall model and
other many other models, you can build security
and as you go along. But regardless of
which model you use, of developments you use, underlying all this is
the quality of code, the quality of the programming. When programmers program,
they make assumptions. They make assumptions
about input, output, environment, services they're
going to use, and so forth. Herein lies the problem. It's not enough that your own programs be secure and robust. You're going to be
calling on services or taking inputs that
you may not trust. So, you have to take into account that these may not
act the way you think and handle special cases. This points to a truism. It's very hard if the
infrastructure is not secured, if the the libraries,
the compiler, the linker loader, and so forth, the network services you rely on aren't secure or
aren't for robus, then it's very hard to build
a program that's robust, or a service that's
robust on top of them. For the moment, we're
going to assume that the infrastructure
is secure. We'll talk a little bit
about that later on.