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.