From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-Thread: 109fba,582dff0b3f065a52 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,582dff0b3f065a52 X-Google-Attributes: gid1014db,public X-Google-ArrivalTime: 2001-08-07 22:00:23 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!netnews.com!newshub2.rdc1.sfba.home.com!news.home.com!news1.rdc1.bc.home.com.POSTED!not-for-mail From: kaz@ashi.footprints.net (Kaz Kylheku) Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++ Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. References: <3b690498.1111845720@news.worldonline.nl> <9kbu15$9bj@augusta.math.psu.edu> <3b6a453c.1193942215@news.worldonline.nl> <9keejl$fhj@augusta.math.psu.edu> <3c30da40.0108060848.796d9bd9@posting.google.com> <3B6F3216.F410BBFF@home.com> <3B6F3FAE.B9B9FFCF@globetrotter.qc.ca> <3B6F5BF6.1E22543B@home.com> <3B706538.5AB33833@globetrotter.qc.ca> <3B70BDA5.575D8E6A@home.com> Organization: Psycho-Neurotic Institute for the Very, Very Nervous Reply-To: kaz@ashi.footprints.net User-Agent: slrn/0.9.6.3 (Linux) Message-ID: Date: Wed, 08 Aug 2001 05:00:22 GMT NNTP-Posting-Host: 24.68.85.82 X-Complaints-To: abuse@home.net X-Trace: news1.rdc1.bc.home.com 997246822 24.68.85.82 (Tue, 07 Aug 2001 22:00:22 PDT) NNTP-Posting-Date: Tue, 07 Aug 2001 22:00:22 PDT Xref: archiver1.google.com comp.lang.ada:11578 comp.lang.c:72831 comp.lang.c++:80847 Date: 2001-08-08T05:00:22+00:00 List-Id: In article <3B70BDA5.575D8E6A@home.com>, Warren W. Gay VE3WWG wrote: >Chris Wolfe wrote: >> You stated: "C/C++ _cannot_ provide [runtime checks like boundary >> checks]" >> This is false. The compiler I am using is a proprietary one, but.. > >He he, but the one you are _using_ - does it provide array bounds >checking? Does it throw an exception when your integer or unsigned >type overflows? I expect not. Note that unsigned types cannot overflow in C++, by definition. >> with a search on Google for C AND "array bounds checking" I found >> a list of public ones (including a patch for GCC). > >That's just peachy. But a sampling of the population of C++ >users using these, ahem, extensions, are likely to be a small portion >of all C++ users. The bounds checking GCC patches work well, but only support the C front end (last time I checked). The checking is also not perfect. It's done on object granularity, not sub-object granularity. Say an array is embedded in a struct and is not the first member, An overrun of that array can clobber other members; bounds checking GCC will not detect that. It knows that an object of a certain size is being manipulated, namely the entire struct. Anything that is dynamically allocated via a single malloc() call is also just a single object: essentially a character array that wide. I think that this is about the best you can do without doing a lot more work. And it's certainly better than no checking at all! Even protecting primary objects traps nasty classes of errors whereby a problem in one module causes strange failures in another. Bounds checking GCC works with the help of a run-time library, which keeps track of all live objects in a splay tree data structure. A pointer can be used as a key to locate a node within the tree, which provides the attributes of the object that the pointer points to. So the pointer representation is not changed in any way, preserving binary compatibility with existing code (except that two pointer bit patterns are reserved for representing special values). To my recollection, the run-time library is not thread safe. Also, programs that use longjmp() causes problems, because it won't be noted that certain automatic objects no longer exist. (The tracking of automatic objects is keyed to the same mechanism that is used for C++ constructors and destructors in the GCC back end, and longjmp() doesn't play nicely with that). On the plus side, Bounds Checking GCC does nice things with pointer arithmetic. A bad pointer doesn't have to be dereferenced to be diagnosed, merely calculated, so that for instance p = malloc(10) + 11 can be flagged as an error.