Re: compilation of ms crypto api program

From: Ernst Lippe (ernstl-at-planet-dot-nl_at_ignore.this)
Date: 06/22/03 

Date: Sun, 22 Jun 2003 17:23:52 +0200

On Sun, 22 Jun 2003 12:23:53 +0000, Henrick Hellström wrote:

> Ernst Lippe wrote:
>> With all Pascal compiler that I have seen, even the first that
>> was developed by Wirth, it was possible to circumvent this by
>> using variants. Because in the original Pascal definition the
>> length of an array was part of its type this trick was commonly
>> used in many programs. But of course this breaks array bounds
>> checking. In this respect Java is much safer because it is
>> simply impossible to circumvent the array bound checks.
>
> I presume you are talking about variant record parts, such as:
>
> type
> TMyArray16 = packed array [0..1] of 0..255;
> TMyArray32 = packed array [0..3] of 0..255;
> var
> MyRecord: packed record
> case Integer of
> 0: (Field1: TMyArray16);
> 1: (Field2: TMyArray32);
> end;
> MyArray16: TMyArray16;
>
> Given these declarations, the following statements are perfectly safe:
>
> MyRecord.Field2[0] := 0;
> MyRecord.Field2[1] := 1;
> MyRecord.Field2[2] := 2;
> MyRecord.Field2[3] := 3;
> MyArray16 := MyRecord.Field1;
>
> MyArray16 will be equal to (0,1) and no array bounds have been broken.
> The size of MyRecord will be equal to the size of the largest variant
> record part, and it is impossible to use it to access unallocated memory.

Actually, I was referring to the trick that uses pointers.
When I use new(), it is possible to allocate the size for
one variant and to access it via the other variant.
This defeats array bounds checking.

>> It always amazes me how obsessed some crypto people are with
>> performance. Perhaps it is a bit naive, but I would expect that they
>> should be far more interested in security. Buffer overflows are
>> probably the most common source of security problems in software. They
>> can be completely eliminated by using an appropriate language.
>
> No, buffer overruns are *not* the most common source of security
> problems in software.
So, what is your favorite most common class of security problems?

> It is a marginal problem generally, and occurs
> mostly in languages that e.g. allow dynamic allocation of stack memory.
You can have buffer overruns even when stack memory is statically
allocated, i.e. when the size of all structures on the stack are
known at compile time.

> In those cases buffer overruns do occur, they will for the most part
> cause the software to crash badly long before any attacker will stand a
> chance to exploit them.
How about denial of service attacks?

> There are lots of other security problems that
> are both much more common and run a much higher risk of being exploited
> before they are discovered.
Such as?

Even though we may disagree about the importance of buffer overruns, I
believe that we both agree that they are unnecessary.

Buffer overruns can be pretty difficult to detect.

>> Also, I believe that you are exaggerating the performance problems of
>> Java. First of all, interpreted languages in general have a constant
>> overhead compared with compiled languages. When your hardware becomes
>> faster, and it still does, this constant factor gets less
>> important. In many programs IO is the bottle-neck and that is not
>> dependent on your programming language. Second, modern JIT (Just in
>> Time) compilers can do very important optimizations, in many cases
>> there is no real difference for the end-user between Java programs and
>> those written in compiled languages.
>
> Sure, performance might be a marginal problem if you can afford buying
> faster hardware.
In most cases this is not a real problem.

> I would say memory management and garbage collection is
> a much greater problem for the pov of security. I don't like the idea
> not being able to tell if a statement will cause key material to be
> copied to memory locations outside of my control.

When an attacker can read the program's memory or its swap
file there is little that you can do anyhow.
Java guarantees that all newly allocated memory is cleared
so it should not be possible for a Java program to get copies
from key material that is lying around somewhere in the heap.

greetings,

Ernst Lippe

Relevant Pages

  • Re: compilation of ms crypto api program
    ... > With all Pascal compiler that I have seen, ... and it is impossible to use it to access unallocated memory. ... > probably the most common source of security problems in software. ... mostly in languages that e.g. allow dynamic allocation of stack memory. ...
    (sci.crypt)
  • Re: WWDC -- MacBook Pro?
    ... ....but once the program has loaded it into its program memory, ... boundaries, int16 are aligned on 2 byte boundaries, int32 are ... people are always able to come up with the compiler ... Case B, same glass, same ice code water.  ...
    (comp.sys.mac.system)
  • Re: Why C?
    ... > C programs can be as fast as a compiler can make them, ... > programs in other languages. ... > lurking bugs and inappropriate data types in any existing C code. ... With only a different declaration syntax it would be much ...
    (comp.os.linux.development.apps)
  • Re: Why do folks implement statically typed languages?
    ... The languages discussed are extremes. ... It allows the compiler to prove that your data-manipulations are ... an IDE for a dynamically-typed language can ... to IDEs in dynamically-typed languages. ...
    (comp.lang.scheme)
  • Re: Javas performance far better that optimized C++
    ... The compiler is extremely stupid. ... no memory leaks are guaranteed. ... However I have GC in my .NET programming. ... "C.9.1 Automatic Garbage Collection ...
    (comp.lang.cpp)