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: 115e50,63e8a95e8331225 X-Google-Attributes: gid115e50,public X-Google-Thread: 103376,63e8a95e8331225 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-04-17 09:40:08 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!cyclone.bc.net!news-in.mts.net!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail Message-ID: <3E9ED74B.8070500@cogeco.ca> From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.os.assembly Subject: Re: Partial Hardware Protection for Buffer Overrun Exploits References: <3E9D8AB6.4090009@cogeco.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 17 Apr 2003 12:33:15 -0400 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1050597195 198.96.223.163 (Thu, 17 Apr 2003 12:33:15 EDT) NNTP-Posting-Date: Thu, 17 Apr 2003 12:33:15 EDT Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:36238 Date: 2003-04-17T12:33:15-04:00 List-Id: Vinzent Hoefler wrote: > "Warren W. Gay VE3WWG" wrote: > >>If it is possible for the CPU to distinguish between the >>"text" region and the "data" regions (including stack), > > It does in some way. But in the flat model it does not distinguish the > addresses. So if you say CS:[03FC7687] and SS:[03FC7687] it refers to > the same memory, although the access rights are different depending on > how you access it. That is the danger. Actually, the flat memory model does not have to be a show stopper here. The _CPU_ must translate every VM address into a physical real address. In this process, the CPU is quite capable of identifying that the address is at least (read-only), and perhaps that it is text (or could be enhanced to do so). IIRC, Intel doesn't have an "execute" flag for segments, but if they were to add that, I think the situation can be further improved. >>then >>a new instruction (say RETT - Return to Text), could cause >>a fault to occur, if the return address is not to a text >>virtual memory address (for exploits this address points >>to a "data" region, and usually part of the current stack >>frame). > > There is already an easier solution (at least for x86-CPU's): Don't > use a purely flat model, with this I mean, you shouldn't use the same > address space for both data/stack and code. This could already be > accomplished with the standard protection/paging features of the x86. I don't follow this. Even if you divide data and stack, how does this help? The return instruction is what needs to be restricted in what is acceptable to it. Since you can't change the current RET instruction without breaking code, I propose they add a RETT instruction that does insist on restrictions. Even the simple restriction that the return address is read-only, would help. > Unfortunately there are some features in current real world compilers > (like for instance, the so-called trampolines) that require an > "executable" stack segment. Simply get rid of these features and the > solution is easy. By adding a RETT instruction, we are _not_ taking away the priviledge of running code in data/stack regions. As you've pointed out, there may be good reasons to execute code in the data region (like JIT compilers). I just want to restrict the normal case of the RET for a function, so that it cannot give control to arbitrary hostile code. >>As far as I see, the only way to exploit buffers would >>then require the attacker to find usable sections of text >>to do his bidding. > > Because you cannot write to the code segment without triggering a GPF > it would be simply impossible. Still, you could launch a DoS-attack > this way. In a large enough process, an attacker might be able to find a sufficient number of bytes of code that does just what he wants. If he can find a text sequence that does a jump to register for example, all he then has to do is to arrange the clobbering of the stack frame such that that register has the required address he wants. This is why I hesitate to say that this approach would be foolproof. I still believe however, it is one step in the right direction. >>There has to be a better solution to the current crop of >>buffer exploits, that are being used daily. > > Yes. What about using Ada? ;-) > > Vinzent. This is the area where I think many people are missing the point. Yes, indeed, programming and programming tools can help, and programmers need to do a better job. I agree with this entirely, and I fully support the use of Ada in this respect. But the _practical_ reality is that we will be using C based operating system, applications, drivers and desktops for a long time to come. These will be always susceptible to exploits. Why? - human limitations (or human nature) - failure to accept better tools - failure to properly apply better tools - failure in programming discipline - the drive to get the product out first and probably many more reasons. While I disagree with using a 8 inch spike in the living room wall to hold up a picture (my father was like this), doesn't it make sense to address the problem once and for all, if the options are presented? I like to fix the problem once, and be done with it. While the proposal is not the final answer here, it is a _big_ step forward I think. One that we won't have to backtrack on. We will later have to address the other exploits (like the jump to register one), but at least that entire "class" of exploits is forever gone. We can all talk about how it "should be". But I want to see a real solution. A real improvement. I don't want to wait 10 years for it either. We need to be looking at other creative ways to deal with this problem. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg