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,da46977c58c329df X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-02-06 14:03:58 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!xmission!news-out.spamkiller.net!propagator-maxim!news-in.spamkiller.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread1.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3C61A848.60004@earthlink.net> From: "Ian S. Nelson" Reply-To: nelsonis@earthlink.net.NOSPAM User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Ada's Slide To Oblivion ... References: <4519e058.0201310714.650888e1@posting.google.com> <3C598CAA.7040801@home.com> <3C59FCD3.928144FB@adaworks.com> <7v8za79id0.fsf@vlinux.voxelvision.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 06 Feb 2002 22:03:57 GMT NNTP-Posting-Host: 66.1.228.145 X-Complaints-To: abuse@earthlink.net X-Trace: newsread1.prod.itd.earthlink.net 1013033037 66.1.228.145 (Wed, 06 Feb 2002 14:03:57 PST) NNTP-Posting-Date: Wed, 06 Feb 2002 14:03:57 PST Organization: EarthLink Inc. -- http://www.EarthLink.net X-Received-Date: Wed, 06 Feb 2002 14:03:57 PST (newsmaster1.prod.itd.earthlink.net) Xref: archiver1.google.com comp.lang.ada:19685 Date: 2002-02-06T22:03:57+00:00 List-Id: Nick Roberts wrote: > "Ole-Hjalmar Kristensen" wrote in message > news:7v8za79id0.fsf@vlinux.voxelvision.no... > > >>>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 > >>Where do you get this wild idea from? There is nothing in the language >>definition which demands this. At least on UN*X, the executable part >>is normally put in a read-only segment. But this is not an attribute >>of the language, but of the hardware, OS, and the linker/loader. >> > > Perhaps I did not express myself clearly enough. If you were to re-read what > I said, carefully, I think you will see that what I wrote does not deny that > the executable part is put into read-only memory; on the contrary, I > actually imply it. > > Allow me to try to clarify. The C language requires (in practice if not > strictly in theory) that all pointers fit into one machine word. On 32-bit > architectures, this almost invariably forces the use of a 'flat' address > space (just an offset, with no segment number or equivalent). Which means > that, for many architectures, the operating system cannot use segmentation > (or other memory divisions) to detect a call or jump into read-write memory. > If it were able to do this, it could prevent the execution of code which has > been (maliciously caused to be) written into memory (by the program itself, > due to a bug being exploited). Are we talking about processors with an MMU? When you create a pagetable on most modern processors (I'm think pentiums, alpha, sparc, powerpc all with an MMU) you can supply permissions to the pages. Readable, writable, execuatable. So when I load an app I can take the pages the the code sits in and make them readable and executable. Then I can make the heap writable but not executable, I can make the stack read-write but not executable. This is done in the kernel and they are page attributes, not address attributes. Then when the mmu does the address translation it can detect page faults if you try to do an instruction fetch from a non-executable page or try to write to a read-only page which are trapped by the OS. You don't need segments to do this, and it's already done on several OSes one several chips with C and C++ code. The application cannot take an address and determine the permissions for a given address but it shouldn't need to. The OS will get the trap from the processor on a page-fault, it may or may not be able to determine the type of page-fault by some flags and then it can kill the process, or send a signal to it or whatever. Now that I think about it, I shouldn't have snapped back so quick. There probably are architectures without hardware support for memory protection and what have you where you still might want to try to do it with things like segments. I couldn't imagine them performing well though, but that's never stopped people. I don't see that as C's fault though. Ian > On many architectures, then, C prevents the OS from using available memory > protection mechanisms to prevent buffer overrun exploitation, whereas most > other programming languages do not. In this way, C is a security liability. > C++ generally has the same fault. > > > "Ian S. Nelson" wrote in message > news:3C6144E7.4010801@earthlink.net... > > >>This is flat out wrong. >> > > I refer the honourable member to my previous answer. > > > -- > Nick Roberts > > > >