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,bc1361a952ec75ca X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-08-01 18:14:07 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!easynet-tele!easynet.net!newsfeed.easynews.net!newsfeed2.easynews.net!easynews.net!news.cid.net!news.enyo.de!news1.enyo.de!not-for-mail From: Florian Weimer Newsgroups: comp.lang.ada Subject: Re: How Ada could have prevented the Red Code distributed denial of service attack. Date: Thu, 02 Aug 2001 03:29:43 +0200 Organization: Enyo's not your organization Message-ID: <87r8uvuu48.fsf@deneb.enyo.de> References: <8766c7h2zm.fsf@deneb.enyo.de> <5m0a7.21097$Kd7.13099003@news1.rdc1.sfba.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Xref: archiver1.google.com comp.lang.ada:11013 Date: 2001-08-02T03:29:43+02:00 List-Id: tmoran@acm.org writes: >> > Of course they also depend on not using hardware designed with >> > security in mind. >> >> Could you elaborate on that, please? > In the '60s and '70s there was quite a lot of work on "descriptors" or > "capabilities" based architectures. The Burroughs machines (often used by > banks, interestingly) used those techniques. Ah, I see. Here's an interesting resource: http://www.ajwm.net/amayer/papers/B5000.html | For additional security, code and data were distinguished in memory by | the use of a "flag bit", and the hardware would not execute data or | alter code without first having explicitly changed the flag (something | reserved for privileged processes). This protects at least against some buffer overflow exploits, > The 386 was designed with a lot of support for OS security(1), Actually, it was the 286. The 386 introduced another VM layer which supports paging, IIRC. > most of which is unused today. The 386 doesn't implement fine-grained per-object security, that's why this scheme not very useful in this context. Nowadays, there a tons of exploits which overwrite function pointers on the heap, for example to defeat Solar Designer's hack for non-executable stack pages. All in all, the security features provided by the 386 are quite poor. It doesn't even support the full range of mmap() flags: you cannot control read and execution access separately. For this, you would need selectors (a 286 feature), and for several technical reasons, it is not feasible to use them. > "Protected mode" today means "wide addressing" much more than it means > protection. At the very least, one would expect protection against > modifying running code (by running past a data buffer). That's not how buffer overflows work. ;-)