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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,da46977c58c329df X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-05 19:01:07 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!uni-erlangen.de!fu-berlin.de!uni-berlin.de!ppp-3-147.5800-9.telinco.NET!not-for-mail From: "Nick Roberts" Newsgroups: comp.lang.ada Subject: Re: Ada's Slide To Oblivion ... Date: Wed, 6 Feb 2002 02:37:51 -0000 Message-ID: References: <4519e058.0201310714.650888e1@posting.google.com> <3C598CAA.7040801@home.com> <3C59FCD3.928144FB@adaworks.com> NNTP-Posting-Host: ppp-3-147.5800-9.telinco.net (212.1.138.147) X-Trace: fu-berlin.de 1012964466 42667990 212.1.138.147 (16 [25716]) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Xref: archiver1.google.com comp.lang.ada:19650 Date: 2002-02-06T02:37:51+00:00 List-Id: "Dale Pontius" wrote in message news:a3eikr$tfo$1@news.btv.ibm.com... > By today's common programming practices, we have a situation > where the simplest/easiest way of programming string input gives > buffer overflows, and there for security holes. In C, that is. > Don't know about C++, but at least in Ada, the simplest/easiest > way of programming string input at worst would give a DOS > problem as the program crashed, and it wouldn't be much harder > to catch the exception and stop that. To my mind, it seems more appropriate that DoS (Denial of Service) attack prevention should be undertaken primarily by the IP router module, not by TCP (or UDP) service applications. The TCP module, and its service applications, could help by reporting suspicious activity to the IP router (which should provide an interface to facilitate this). Both C and C++ are fundamentally insecure languages, because they require a 'flat' address space, with no differentiation between the executable (read-only) and variable (read-write) parts. This completely subverts the security mechanisms (e.g. segments with access controls) most modern processor architectures support and could otherwise fully deploy. Buffer overrun exploits are but one manifestation of this problem. I never cease to be amazed at the number of people -- many who should know better (or be more honest) -- who expound flat address spaces as universally advantageous. (I emphasise that I understand there are some cases where they are indeed advantageous.) Some processor architectures, specifically for the benefit of C code, support a style of addressing that permits the use of a machine word to contain a full address into a segmented space, but with only 32 bits to play (on 32-bit architectures), this doesn't work very well. Of course 64-bit architectures solve this problem; but then the problems of porting 32-bit C and C++ code to 64-bit are many, and make hilarious reading for those of a strong mental constitution. -- Nick Roberts