Re: Six Step IE Remote Compromise Cache Attack

[Goetz Babin-Ebell <babin-ebell () trustcenter de>]

Hello Alun,

Alun Jones wrote:
> > -----Original Message-----
> > From: Goetz Babin-Ebell [mailto:babin-ebell () trustcenter de] 
> > Sent: Monday, November 10, 2003 11:25 AM
> >
> > But wrongly rejecting good input has no security implications.
> > But wrongly accepting bad input has.
>
> Coding to satisfy only security implications, in a vacuum separated from the
> rest of the world, all the security bugs in the world can be fixed simply by
> removing all the features.

That is not what I have said:
You define a field of accepted inputs (your white list)
All inputs, that do not match the white list,
is rejected with an error.

Now you have to study the errors with the supplied input.
If there is some input that should be accepted,
you have to adapt your white list.
(After testing that this inpuut doesn't barf your program...)

> Wrongly rejecting good input has a very strong implication - your program
> fails to do what it is tasked with.

Only for those inputs you are not sure
that it really does what it should do.
And that is good.
An error message is always better than an wrong result.

> You can call that a security
> implication, in that security's task is not just to prevent access by the
> unwashed, but also to allow, provide and facilitate access to those that are
> approved.

Your program has a function.
If gets some inputs, does some operations and generates some outputs.

There are 3 differend kinds of inputs:
1. inputs you are sure it will generate correct output
2. inputs you are sure it will generate unwanted output
3. inputs you don't know what output it will will generate

You want only to generate error messages for inputs of kind 2.
I want to generate error messages for inputs of the kinds 2 & 3.

Lets have an example:
A program that gets a number and calculates the next number.

For some inputs it will generate correct outputs.
For other inputs you are either not sure or you know that
it will generate some wrong output.

The used data type is unsigned char.

The 1st version of the input test function is:

BOOL CheckInput(const char*in)
{
   if (!in)
      return FALSE;
   if (in[0] >= '0' && in[0] <= '9' && !in[1])
      return TRUE;
   return FALSE;
}

This is OK until the first customer tries
the number 10 and gets an error message.

Reading (and testing) the code, we find:
there is no problem with 2 digit numbers.

So the 2nd version of the input test function is:

BOOL CheckInput(const char*in)
{
   if (!in)
      return FALSE;
   if (in[0] >= '0' && in[0] <= '9' && !in[1])
      return TRUE;
   if (in[0] >= '0' && in[0] <= '9' &&
       in[1] >= '0' && in[1] <= '9' && !in[2])
      return TRUE;
   return FALSE;
}

This is OK until the first customer tries
the number 100 and gets an error message.

Reading (and testing) the code, we find:
there is a problem with numbers bigger than 255.

So the 3rd version of the input test function is:

BOOL CheckInput(const char*in)
{
   if (!in)
      return FALSE;
   if (in[0] >= '0' && in[0] <= '9' && !in[1])
      return TRUE;
   if (in[0] >= '0' && in[0] <= '9' &&
       in[1] >= '0' && in[1] <= '9' && !in[2])
      return TRUE;
   if (in[0] >= '0' && in[0] <= '9' &&
       in[1] >= '0' && in[1] <= '9' &&
       in[2] >= '0' && in[2] <= '1' && !in[3])
      return TRUE;
   if (in[0] >= '0' && in[0] <= '9' &&
       in[1] >= '0' && in[1] <= '9' &&
       in[2] == '2' && in[1] >= '0' && && in[1] <= '4'
       && !in[3])
      return TRUE;
   if (in[0] >= '0' && in[0] <= '9' &&
       in[1] >= '0' && in[1] <= '9' &&
       in[2] == '2' && in[1] == '5' && in[0] >= '0' && in[0] <= '5'
       && !in[3])
      return TRUE;
   return FALSE;
}

Now we have found the real limits of the program.
But the importand fact is:
For all input the program ever accepted,
it calculated the correct output.


> If all we are doing is trying to prevent unauthorised access, then all we
> have to do is turn off, unplug, and shred, our computers.  There - security
> made easy.

I did never say we should dump our computers.
I did say our programs should only accept
input we are sure they process correctly.


Bye

Goetz

--
Goetz Babin-Ebell, TC TrustCenter AG, http://www.trustcenter.de
Sonninstr. 24-28, 20097 Hamburg, Germany
Tel.: +49-(0)40 80 80 26 -0,  Fax: +49-(0)40 80 80 26 -126

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature