comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: An interesting quote on Java and C++
Date: 1997/09/12
Date: 1997-09-12T00:00:00+00:00	[thread overview]
Message-ID: <EGEqsx.G5G@world.std.com> (raw)
In-Reply-To: 3417ECEF.41C6@collins.rockwell.com


In article <3417ECEF.41C6@collins.rockwell.com>,
Roy Grimm  <ragrimm@collins.rockwell.com> wrote:
>Stephen Leake wrote:
>> 
>> Range constraints provide significant security benefits, at least in
>> systems without separate address spaces. If you can write "past" the
>> end of an array, you can write to arbitrary memory, including system
>> memory.  I believe there are several Windows/DOS viruses that use this
>> trick, but I'm not really sure.
>
>A particularly famous example of missing range checking causing a major
>security hole was that virus that took down hundreds of computers on the
>internet several years ago.

This is completely wrong.  You're talking about array-index checks, not
range checking (e.g. on integer values).  I was talking about the
latter, and I claim that range-checking is purely for catching bugs, and
has nothing to do with security (except in the sense that security
software without bugs is better than security software with bugs).

Java *does* do array-bounds checking, and that's for security reasons.
It does *not* do range checking on integers, and that does no damage to
security, but *does* cause bugs.  Ada has range checking, will helps get
rid of bugs, but it allows things like Unchecked_Conversion and pragma
Suppress, which totally destroy security.

Furthermore, the only way an array-index out of bounds can cause a
security flaw is when the program in question has a bug, and has some
privelege that most programs don't have.  E.g. setuid programs running
under unix.  (Or any program running under Windows 95!)

Yes, if a setuid program has a bug, it can cause a security flaw.  So
yes, bug-prevention in such programs can enhance security, indirectly.

>The guy who built the virus used three known security holes to get his
>virus around.  The one I can remember the best had to do with sending
>specially formatted "finger" request packets.  The finger daemon on Unix
>systems has a buffer to hold the incoming finger request data.  On some
>particular flavor of Unix, if one decided to send a specially formatted
>finger request packet (around 530 bytes if memory serves), they would
>overrun the end of the buffer.

Right, we're talking about array bounds checking, which Java and Ada
both have.  And we're talking about setuid programs, which can do real
damage when buggy.

>Now, overrunning the end of a buffer in many programs is not too
>critical, if you consider a crash not too critical.  However, on
>particular versions of unix, the finger daemon put executable code right
>after that buffer.  When you overrun the end of that buffer, you
>overwrite its code.  When the program gets to that code that you have
>overwritten, it will do whatever you put there.  Since the finger daemon
>runs with the system administrator's user ID on those systems, the code
>you put in has global access to everything.  That's a major security
>hole in anyone's book.

Yes, if you can overwrite arbitrary addresses in a priveleged program,
then you've got a security hole.  But that's got nothing to do with
bounds-checking on integers.

>I believe the person who wrote the virus put in code which transferred
>the main virus program from another site and then ran it, respawning the
>finger daemon in the process so people wouldn't notice as easily.
>
>Had there been range checking of the incoming request data along the
>line, the hole would not be there.  

No, array-bounds checking is what was missing.

- Bob




  reply	other threads:[~1997-09-12  0:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-09-03  0:00 An interesting quote on Java and C++ Nasser
1997-09-03  0:00 ` Samuel Mize
     [not found] ` <01bcb881$915526a0$d7000064@sim01.amst.co.at>
1997-09-03  0:00   ` Robert Munck
1997-09-05  0:00     ` Joachim Schroeer
1997-09-06  0:00     ` Robert Dewar
1997-09-24  0:00     ` Shmuel (Seymour J.) Metz
1997-09-08  0:00   ` Robert A Duff
1997-09-09  0:00     ` Robert Munck
1997-09-10  0:00       ` Robert A Duff
1997-09-10  0:00         ` Stephen Leake
1997-09-11  0:00           ` Roy Grimm
1997-09-12  0:00             ` Robert A Duff [this message]
1997-09-10  0:00         ` Robert Munck
1997-09-11  0:00           ` Robert Dewar
1997-09-12  0:00             ` Robert A Duff
1997-09-18  0:00               ` Shmuel (Seymour J.) Metz
1997-09-19  0:00                 ` Robert A Duff
1997-09-20  0:00                   ` Robert Dewar
1997-09-20  0:00                 ` Robert Dewar
1997-10-03  0:00                   ` Robert I. Eachus
1997-09-20  0:00                 ` Robert Dewar
1997-09-22  0:00                   ` Robert A Duff
1997-09-12  0:00             ` Jon S Anthony
1997-09-12  0:00         ` Jon S Anthony
1997-09-11  0:00       ` Robert Dewar
1997-09-12  0:00         ` Jon S Anthony
1997-09-12  0:00           ` Robert A Duff
  -- strict thread matches above, loose matches on Subject: below --
1997-09-25  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-09-25  0:00 ` Shmuel (Seymour J.) Metz
1997-09-26  0:00   ` Tucker Taft
1997-10-07  0:00   ` Robert I. Eachus
1997-11-19  0:00     ` Shmuel (Seymour J.) Metz
1997-10-08  0:00 Marin David Condic, 561.796.8997, M/S 731-96
1997-10-09  0:00 ` Shmuel (Seymour J.) Metz
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox