Definitions of the different error types
Programming errors:
Programming errors are errors made by the programmers of a particular
piece of software. The most common exploitable programming errors are
buffer overflows. Think of a buffer overflow as an empty cup:
The user of the program is going to put coffee in the cup, but the
programmer does not know in advance how much coffee the user will put
in there.
So the programmer must check and test this before actually putting the
coffee in the cup to prevent the coffee from overflowing the cup.
Sometimes it"s not that easy to check for input size or due to time
pressure a programmer does not have the time to do write extensive
error checking functions and so possible buffer overflows and other
programming errors are created.
Another example of a programming error is a program that crashes since
the user did something unexpected like load a wrong type of file into
the program.
Of course not all programming errors require user input to do something
unexpected like crash the program. A program could depend on a
particular file which is always in a specific location.
If that file is moved and the programmer doesn"t expect that, he might
not check if the file actually is located there before trying to open
it. This can result in unexpected behavior if that program tries to
work with that file after opening it.
These types of errors occur quite often, and most of the times the
manufacturer distributes patches and updates to resolve the errors
reported by customers or discovered by themselves.
Configuration errors:
Think of a configuration error as if you were a network administrator
and you need to implement a firewall to protect your network from the
internet.
It used to be a common practice to allow every traffic in and out except for the specifically denied types of traffic.
A simple example is a firewall which is blocking only port 80 since it
will allow anyone from the internet to connect to the configuration
page of the firewall and reconfigure it. The rest of the ports are all
open.
This of course is a configuration error since anyone could bypass that firewall by using another port number.
Luckily most manufacturers are aware of this error so they implemented
exactly the opposite: Everything is blocked unless specifically
allowed. So now a network administrator does not have to worry about
new problems found which can access his network through an unused port
since that port is closed already anyway.
(I used only ports here as example, but this can apply to different
types of traffic on the same port as well.)
Another configuration error example is the usage of unmanaged hub"s in
a network instead of managed switches.
The difference is that a hub is sending all incoming traffic to all
ports since it does not know behind which port the receiver is located,
a switch knows this. So, running a sniffer in a network where hub"s are
used instead of switches allows an attacker to view much more traffic
with possible username / password combinations then when using switches
on a network.
Even though this is a configuration error now, it didn"t used to be in the past when switches didn"t yet exist.
Since these errors almost always occur because the customer has too
little knowledge of the product or simply not enough time to completely
configure the product correctly, the customer himself is responsible
for resolving the error. The manufacturers often provide detailed
manuals and help files for their products which you should have read
before configuring and implementing the device or software.
Design errors:
A design error can be seen as an error that occurred during the design
period of the particular software. Even when the programmers spent
enough time writing routines to verify all user input before taking the
software in production, and even when the software has been configured
correctly by the end user, these errors can still cause a great risk
for the security of a network.
Let"s say a company decided to write a piece of software which would
allow remote access to a network. Since they have to support the
software as well, they decided to put in a little backdoor so that can
login remotely by using the companies name as password.
What if someone outside that company would discover that backdoor? He
could login to any network that is using that particular piece of
software for remote access. The consequences would be disastrous!
Although these backdoors were created quite often in the past, nowadays
a company selling such software can"t take the risk anymore, since he
would be held responsible for misusage of that backdoor by attackers.
Another example of a design error is the WEP encryption used for
securing wireless networks. I"m not going to explain in dept how this
is a design error since that is beyond the scope of this paper, but
basically it comes down to this:
A 3 byte initialization vector is added to the pre-shared encryption
key to encrypt every packet uniquely. Let"s say the pre-shared key is
"abcde". The initialization vector for packet one could be "123" so the
total encryption key for that packet would be "123abcde". For the next
packet the initialization vector could be "234" and so creating the
encryption key "234abcde".
The design error lies partially in the fact that there are only 3 byte
different IV"s (Initialization Vector) making a total of 255^3 or 16.5
million different keys and partially in the encryption algorithm used.
One could extract several characters of the pre-shared key quite easily
by reversing part of the algorithm. Because of this design error you
only need around 100,000 packets with unique IV"s for 64-bit and around
800,000 unique IV"s for 128-bit to crack the WEP-key and be able to
participate and read the complete wireless network. On a busy wireless
network this can be done in a few hours.
As you can see, design errors are a bit more complicated to resolve.
You simply cannot expect the manufacturer to write a quick patch to
solve the problem, and you cannot refer to the manual of the product to
resolve the issue yourself. In the case of the WEP encryption a team of
people created a new standard called WPA as an alternative to WEP
encryption. This meant that the products using WEP for encryption
should either be upgraded by replacing them, or through firmware
updates which allows them to work with the new encryption standard.
For a more detailed explanation of the design errors discovered in WEP, take a look at the excellent paper from airscanner.com here.
Programming errors:
Programming errors are errors made by the programmers of a particular
piece of software. The most common exploitable programming errors are
buffer overflows. Think of a buffer overflow as an empty cup:
The user of the program is going to put coffee in the cup, but the
programmer does not know in advance how much coffee the user will put
in there.
So the programmer must check and test this before actually putting the
coffee in the cup to prevent the coffee from overflowing the cup.
Sometimes it"s not that easy to check for input size or due to time
pressure a programmer does not have the time to do write extensive
error checking functions and so possible buffer overflows and other
programming errors are created.
Another example of a programming error is a program that crashes since
the user did something unexpected like load a wrong type of file into
the program.
Of course not all programming errors require user input to do something
unexpected like crash the program. A program could depend on a
particular file which is always in a specific location.
If that file is moved and the programmer doesn"t expect that, he might
not check if the file actually is located there before trying to open
it. This can result in unexpected behavior if that program tries to
work with that file after opening it.
These types of errors occur quite often, and most of the times the
manufacturer distributes patches and updates to resolve the errors
reported by customers or discovered by themselves.
Configuration errors:
Think of a configuration error as if you were a network administrator
and you need to implement a firewall to protect your network from the
internet.
It used to be a common practice to allow every traffic in and out except for the specifically denied types of traffic.
A simple example is a firewall which is blocking only port 80 since it
will allow anyone from the internet to connect to the configuration
page of the firewall and reconfigure it. The rest of the ports are all
open.
This of course is a configuration error since anyone could bypass that firewall by using another port number.
Luckily most manufacturers are aware of this error so they implemented
exactly the opposite: Everything is blocked unless specifically
allowed. So now a network administrator does not have to worry about
new problems found which can access his network through an unused port
since that port is closed already anyway.
(I used only ports here as example, but this can apply to different
types of traffic on the same port as well.)
Another configuration error example is the usage of unmanaged hub"s in
a network instead of managed switches.
The difference is that a hub is sending all incoming traffic to all
ports since it does not know behind which port the receiver is located,
a switch knows this. So, running a sniffer in a network where hub"s are
used instead of switches allows an attacker to view much more traffic
with possible username / password combinations then when using switches
on a network.
Even though this is a configuration error now, it didn"t used to be in the past when switches didn"t yet exist.
Since these errors almost always occur because the customer has too
little knowledge of the product or simply not enough time to completely
configure the product correctly, the customer himself is responsible
for resolving the error. The manufacturers often provide detailed
manuals and help files for their products which you should have read
before configuring and implementing the device or software.
Design errors:
A design error can be seen as an error that occurred during the design
period of the particular software. Even when the programmers spent
enough time writing routines to verify all user input before taking the
software in production, and even when the software has been configured
correctly by the end user, these errors can still cause a great risk
for the security of a network.
Let"s say a company decided to write a piece of software which would
allow remote access to a network. Since they have to support the
software as well, they decided to put in a little backdoor so that can
login remotely by using the companies name as password.
What if someone outside that company would discover that backdoor? He
could login to any network that is using that particular piece of
software for remote access. The consequences would be disastrous!
Although these backdoors were created quite often in the past, nowadays
a company selling such software can"t take the risk anymore, since he
would be held responsible for misusage of that backdoor by attackers.
Another example of a design error is the WEP encryption used for
securing wireless networks. I"m not going to explain in dept how this
is a design error since that is beyond the scope of this paper, but
basically it comes down to this:
A 3 byte initialization vector is added to the pre-shared encryption
key to encrypt every packet uniquely. Let"s say the pre-shared key is
"abcde". The initialization vector for packet one could be "123" so the
total encryption key for that packet would be "123abcde". For the next
packet the initialization vector could be "234" and so creating the
encryption key "234abcde".
The design error lies partially in the fact that there are only 3 byte
different IV"s (Initialization Vector) making a total of 255^3 or 16.5
million different keys and partially in the encryption algorithm used.
One could extract several characters of the pre-shared key quite easily
by reversing part of the algorithm. Because of this design error you
only need around 100,000 packets with unique IV"s for 64-bit and around
800,000 unique IV"s for 128-bit to crack the WEP-key and be able to
participate and read the complete wireless network. On a busy wireless
network this can be done in a few hours.
As you can see, design errors are a bit more complicated to resolve.
You simply cannot expect the manufacturer to write a quick patch to
solve the problem, and you cannot refer to the manual of the product to
resolve the issue yourself. In the case of the WEP encryption a team of
people created a new standard called WPA as an alternative to WEP
encryption. This meant that the products using WEP for encryption
should either be upgraded by replacing them, or through firmware
updates which allows them to work with the new encryption standard.
For a more detailed explanation of the design errors discovered in WEP, take a look at the excellent paper from airscanner.com here.