* Partial Hardware Protection for Buffer Overrun Exploits @ 2003-04-16 16:54 Warren W. Gay VE3WWG 2003-04-16 17:28 ` Vinzent Hoefler ` (2 more replies) 0 siblings, 3 replies; 20+ messages in thread From: Warren W. Gay VE3WWG @ 2003-04-16 16:54 UTC (permalink / raw) I am curious if anyone has discussed this idea before: REVIEW: Buffer exploits work of course, by allowing the attacker to overwrite a buffer (array) with hacker code to be executed. Part of this exploit includes the necessity of overwriting the return address on the _stack_ frame, that the current function will use when it exits (opcode RET? My assembly knowledge is admitedly (for Intel) is very rusty). The RET instruction is how control is being given to planted "hacker code". Obviously, this is _not_ what we want happening on Internet exposed machines. SUGGESTED HARDWARE SOLUTION: For UNIX/Linux anyway (and I think for Win32 also), the code is in protected segments that are at least "read only" and on some platforms perhaps even marked "executable". In UNIX terms, this represents the "text" area of an executable. This means that _normally_, the return address should only refer to text region addresses.... (or alternatively, "read-only" regions of virtual memory). If it is possible for the CPU to distinguish between the "text" region and the "data" regions (including stack), 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). Then GCC could be enhanced to replace the dangerous RET instruction with the safer RETT (say) instruction, and one large class of exploits would be foiled in newly compiled code. This does not of course fix the denial of service problems with overruning buffers, but that is another matter. At least we eliminate the ability of the attacker to execute planted 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. I suspect that this would make the attack considerably more difficult, and perhaps in many cases, impossible or not worth pursuing. YOUR FEEBACK? Has this been discussed before? Is Intel listening? There has to be a better solution to the current crop of buffer exploits, that are being used daily. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 16:54 Partial Hardware Protection for Buffer Overrun Exploits Warren W. Gay VE3WWG @ 2003-04-16 17:28 ` Vinzent Hoefler 2003-04-17 16:33 ` Warren W. Gay VE3WWG 2003-04-17 21:29 ` Robert A Duff 2003-04-16 19:13 ` Brian Catlin 2003-04-17 21:22 ` Robert A Duff 2 siblings, 2 replies; 20+ messages in thread From: Vinzent Hoefler @ 2003-04-16 17:28 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> 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. >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. 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. Well, it would make the writing of self-modifying code a little bit harder. >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. >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. -- Parents strongly cautioned -- this posting is intended for mature audiences over 18. It may contain some material that many parents would not find suitable for children and may include intense violence, sexual situations, coarse language and suggestive dialogue. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 17:28 ` Vinzent Hoefler @ 2003-04-17 16:33 ` Warren W. Gay VE3WWG 2003-04-17 21:29 ` Robert A Duff 1 sibling, 0 replies; 20+ messages in thread From: Warren W. Gay VE3WWG @ 2003-04-17 16:33 UTC (permalink / raw) Vinzent Hoefler wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 17:28 ` Vinzent Hoefler 2003-04-17 16:33 ` Warren W. Gay VE3WWG @ 2003-04-17 21:29 ` Robert A Duff 1 sibling, 0 replies; 20+ messages in thread From: Robert A Duff @ 2003-04-17 21:29 UTC (permalink / raw) Vinzent Hoefler <ada.rocks@jlfencey.com> writes: > 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. Well, on any machine that has an "executable" protection bit on each page, you (the OS) can simply make sure all executable memory is read-only. No need for the x86 segmentation junk. But as you and others say, that disallows all kinds of useful stuff like trampolines and self-modifying code (JIT compilers and the like). > >There has to be a better solution to the current crop of > >buffer exploits, that are being used daily. > > Yes. What about using Ada? ;-) Amen. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 16:54 Partial Hardware Protection for Buffer Overrun Exploits Warren W. Gay VE3WWG 2003-04-16 17:28 ` Vinzent Hoefler @ 2003-04-16 19:13 ` Brian Catlin 2003-04-17 15:00 ` Bob French 2003-04-17 16:14 ` Warren W. Gay VE3WWG 2003-04-17 21:22 ` Robert A Duff 2 siblings, 2 replies; 20+ messages in thread From: Brian Catlin @ 2003-04-16 19:13 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message news:3E9D8AB6.4090009@cogeco.ca... > I am curious if anyone has discussed this idea before: > > REVIEW: > > Buffer exploits work of course, by allowing the attacker to > overwrite a buffer (array) with hacker code to be executed. > Part of this exploit includes the necessity of overwriting > the return address on the _stack_ frame, that the current > function will use when it exits (opcode RET? My assembly > knowledge is admitedly (for Intel) is very rusty). > > The RET instruction is how control is being given to planted > "hacker code". Obviously, this is _not_ what we want > happening on Internet exposed machines. > > SUGGESTED HARDWARE SOLUTION: [snip] An excellent idea. Unisys implemented this 30 years ago in their 'A series' machines; however, getting this to work on a more conventional processor architecture (the Unisys machines are stack-based, and no assembler is sold for them, just high-level languages) would be rather difficult, I suspect. The beauty of allocating space on the stack for strings, is when the routine returns, the storage is automatically returned. A software-only solution could be implemented purely in the compiler, by allocating the string storage on the heap (with guard pages around it), and then deallocating everything when the routine returns. This would impact performance, but would also make the system less vulnerable to this particular attack. It seems to me, that the real root of the problem is the C language, and its lack of a native string type (and the really crappy run-time library). While these sorts of attacks probably aren't limited to C programs, I'd be willing to bet that they are LOTS less prevalent in other languages. It also seems to me, that programming has been made too easy; there are lots of people out there writing software that should really be out cleaning toilets instead. -Brian ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 19:13 ` Brian Catlin @ 2003-04-17 15:00 ` Bob French 2003-04-17 16:14 ` Warren W. Gay VE3WWG 1 sibling, 0 replies; 20+ messages in thread From: Bob French @ 2003-04-17 15:00 UTC (permalink / raw) "Brian Catlin" <brianc@sannas.org> wrote in message news:b7ka8l$bs6$1@slb6.atl.mindspring.net... > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:3E9D8AB6.4090009@cogeco.ca... > > I am curious if anyone has discussed this idea before: > > > [snip] > > It seems to me, that the real root of the problem is the C language, and its > lack of a native string type (and the really crappy run-time library). While The problem isn't really the string type. In C parameters for a subroutine get pushed on the stack. Must have read/write access. The call instruction pushes the return address. Must have read/write access. In the beginning of the subroutine initialized local variables get pushed on the stack and uninitialized variables have space allocated by moving the stack pointer according to their size. Must have read/write access. Either string or array or struct missapplied can step on that return address stored right in the middle of read/write data. The stack has other return addresses to caller of the caller, etc. The data on the stack can also contain a pointer to code. A sort routine can be passed the address of the routines that compare a pair of items and swap a pair of items. It isn't just return addresses that can be problems. The call instruction in the write protected TEXT segment is safe. The real problem is that programmers fail to check necessary limits. That isn't to say that the checking is trivial. If a string space (array of chars) is allocated on the stack and passed to a subroutine there needs to be a limit passed, or a constant limit, and the limit must be less than or equal to the size of the array as allocated by all callers. > these sorts of attacks probably aren't limited to C programs, I'd be willing to > bet that they are LOTS less prevalent in other languages. Languages that allow the use of a pointer to memory have the issue. Intel x86 got the bounds checking instruction back in the days of 80186 but the subroutine may not know the size of the buffer it is working with. It seems that information hiding happens. > It also seems to me, > that programming has been made too easy; there are lots of people out there > writing software that should really be out cleaning toilets instead. > > -Brian > > Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 19:13 ` Brian Catlin 2003-04-17 15:00 ` Bob French @ 2003-04-17 16:14 ` Warren W. Gay VE3WWG 2003-04-17 23:22 ` Randy Brukardt 1 sibling, 1 reply; 20+ messages in thread From: Warren W. Gay VE3WWG @ 2003-04-17 16:14 UTC (permalink / raw) Brian Catlin wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message > news:3E9D8AB6.4090009@cogeco.ca... > >>I am curious if anyone has discussed this idea before: >> >>REVIEW: >> >>Buffer exploits work of course, by allowing the attacker to >>overwrite a buffer (array) with hacker code to be executed. >>Part of this exploit includes the necessity of overwriting >>the return address on the _stack_ frame, that the current >>function will use when it exits (opcode RET? My assembly >>knowledge is admitedly (for Intel) is very rusty). >> >>The RET instruction is how control is being given to planted >>"hacker code". Obviously, this is _not_ what we want >>happening on Internet exposed machines. >> >>SUGGESTED HARDWARE SOLUTION: > [snip] > > An excellent idea. Unisys implemented this 30 years ago in their 'A series' > machines; I can't say that I am familiar with this hardware, but I sense that you might misunderstand my suggested approach. I am _not_ suggesting in _this_ proposal that executed code must be in a read-only segment (text region), but that the new RETURN instruction only accept valid addresses in the read-only segments (ie. text region). I could be wrong, but I suspect that the hardware you speak of may insisted on a execute (or read-only) attribute, but this is very different. All buffer exploits that I know about, plant code in the stack frame (or perhaps even overrun the frame), and then pass control to that code by clobbering the return address that has been pushed on that stack frame. The return address should normally point to the code (text region), but in the exploit, it points to the stack frame (data region). Just insisting that the return instruction only accept a text region address, would largely eliminate the danger of running exploit code. > It seems to me, that the real root of the problem is the C language, and its > lack of a native string type (and the really crappy run-time library). While > these sorts of attacks probably aren't limited to C programs, I'd be willing to > bet that they are LOTS less prevalent in other languages. It also seems to me, > that programming has been made too easy; there are lots of people out there > writing software that should really be out cleaning toilets instead. > > -Brian While I agree that C (and other languages) do present a practical problem here, I don't see this as the "practical solution". Yes, it would be nice if UNIX/Linux/FreeBSD and Windows would all be rewritten in Ada95, and largely eliminate this problem. But do you really believe that this is going to happen any time soon? I can't even count on the name servers (bind) and dhcp servers and client programs to do this yet. If Intel provided an RETT (return to text) instruction, GCC could be enhanced to use it, and all of the existing Linux code base for example, could be strengthened a mere recompile. The only downside of this approach that I see, is that this might reduce the pressure for people to critically examine the issue (ie. move to Ada?) However, there is still the denial of service aspect, that this won't address anyway. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-17 16:14 ` Warren W. Gay VE3WWG @ 2003-04-17 23:22 ` Randy Brukardt 2003-04-21 16:42 ` Warren W. Gay VE3WWG 0 siblings, 1 reply; 20+ messages in thread From: Randy Brukardt @ 2003-04-17 23:22 UTC (permalink / raw) Warren W. Gay VE3WWG wrote in message <3E9ED2E7.80807@cogeco.ca>... >I can't say that I am familiar with this hardware, but I sense that >you might misunderstand my suggested approach. I am _not_ suggesting >in _this_ proposal that executed code must be in a read-only >segment (text region), but that the new RETURN instruction only >accept valid addresses in the read-only segments (ie. text region). That's equivalent to saying that the stack not be marked as executable code. And it shouldn't anyway, I think it is idiotic that any modern OS uses a model with no separation of code and data. Janus/Ada for the Pharlap DOS Extender always did this. The Intel processor only allows Read-Execute and Read-Write access to segments (but not both). The DOS Extender (and Windows and Linux do this too) get around this 'limitation' by providing mirrored segment values that point at the same memory. What our DOS Extender compiler did was to allocate the real data area using an OS call, then replaced all of the writable segment descriptors with the one from the allocation -- including the stack. (That was a bit tricky!). Then, it was impossible to write the code segment or execute the data segment without a trap. That caught plenty of bugs in the implementation of the compiler. This is such an obvious idea that it's getting implemented in BSD. I saw this article yesterday: http://news.com.com/2100-1002-996584.html My only question is why they didn't do this years ago. The Intel hardware has always supported it... Randy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-17 23:22 ` Randy Brukardt @ 2003-04-21 16:42 ` Warren W. Gay VE3WWG 2003-04-21 17:26 ` tmoran 0 siblings, 1 reply; 20+ messages in thread From: Warren W. Gay VE3WWG @ 2003-04-21 16:42 UTC (permalink / raw) Randy Brukardt wrote: > Warren W. Gay VE3WWG wrote in message <3E9ED2E7.80807@cogeco.ca>... > >>I can't say that I am familiar with this hardware, but I sense that >>you might misunderstand my suggested approach. I am _not_ suggesting >>in _this_ proposal that executed code must be in a read-only >>segment (text region), but that the new RETURN instruction only >>accept valid addresses in the read-only segments (ie. text region). > > That's equivalent to saying that the stack not be marked as executable > code. And it shouldn't anyway, I think it is idiotic that any modern OS > uses a model with no separation of code and data. For most of _my_ code, that is probably true. However, JVM types of processes may disagree. They need to be able to assemble code on the fly and then give them control. However, I think you could regulate this with some "per thread/process flag". > Janus/Ada for the Pharlap DOS Extender always did this. The Intel > processor only allows Read-Execute and Read-Write access to segments > (but not both). The DOS Extender (and Windows and Linux do this too) get > around this 'limitation' by providing mirrored segment values that point > at the same memory. What our DOS Extender compiler did was to allocate > the real data area using an OS call, then replaced all of the writable > segment descriptors with the one from the allocation -- including the > stack. (That was a bit tricky!). Then, it was impossible to write the > code segment or execute the data segment without a trap. That caught > plenty of bugs in the implementation of the compiler. I would have thought that Linux/FreeBSD/Windows would have been taking advantage of this already. Is it true that "text" is not read only there? What a waste if they make that RW(!) > This is such an obvious idea that it's getting implemented in BSD. I saw > this article yesterday: > > http://news.com.com/2100-1002-996584.html I don't think much of the "random placement" idea, though I supposed they are being forced to deal with a problem that should be fixed in hardware (IMHO). > My only question is why they didn't do this years ago. The Intel > hardware has always supported it... > > Randy. Yes, indeed. In fact, it might be useful to go one step further, and add an execute bit (I am under the impression Intel doesn't make this distinction). Then you could distinguish between RO constants and X code. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-21 16:42 ` Warren W. Gay VE3WWG @ 2003-04-21 17:26 ` tmoran 2003-04-22 1:40 ` Frank J. Lhota 0 siblings, 1 reply; 20+ messages in thread From: tmoran @ 2003-04-21 17:26 UTC (permalink / raw) Are there exploits using an overflow into a tagged type jump table? When Intel came out with Protected Mode Bill Gates declared it "brain dead" and they came up with the "solution" of doing a restart of the CPU to shake off the shackles of protection. Are there OSes in use that use the Intel protection mechanisms? ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-21 17:26 ` tmoran @ 2003-04-22 1:40 ` Frank J. Lhota 2003-04-22 21:15 ` Robert A Duff 0 siblings, 1 reply; 20+ messages in thread From: Frank J. Lhota @ 2003-04-22 1:40 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:qRVoa.554917$3D1.304762@sccrnsc01... > When Intel came out with Protected Mode Bill Gates declared it "brain > dead" and they came up with the "solution" of doing a restart of the CPU > to shake off the shackles of protection. The first Intel chips that supported protected mode were the rarely-used 80186 and the 80286 chips that powered the IBM PC/AT. These early chips supported a command for transitioning from real to protected mode, but no simple command for transitioning back to real mode. This is what earned these chips the "brain dead" assessment from Gates. The lack of a quick way to get back to real mode was a problem for MS, who wanted protected-mode extensions to DOS (such as Windows 3.x and OS/2 1.x) to be able to use the real mode I/O kernel of DOS. Their solution was the "mini-reboot" of the CPU, for which they paid a performance penalty. All of these problems went away with the next generation of Intel chips (the 80386 and beyond), which can quickly toggle between real and protected modes. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-22 1:40 ` Frank J. Lhota @ 2003-04-22 21:15 ` Robert A Duff 2003-04-22 21:19 ` Ed Falis 0 siblings, 1 reply; 20+ messages in thread From: Robert A Duff @ 2003-04-22 21:15 UTC (permalink / raw) "Frank J. Lhota" <NOSPAM.FrankLho@rcn.com> writes: > The first Intel chips that supported protected mode were the rarely-used > 80186 The 80186 did not support protected mode. It was practically identical in architecture to an 8086 or 8088. The 80186 had a small number of additional instructions -- e.g., pushall for pushing all registers, I think (for some definition of "all"). It was used in mainly in embedded systems, I believe. >... and the 80286 chips that powered the IBM PC/AT. These early chips > supported a command for transitioning from real to protected mode, but no > simple command for transitioning back to real mode. This is what earned > these chips the "brain dead" assessment from Gates. Well it *was* pretty brain dead, for this and other reasons. >...The lack of a quick way > to get back to real mode was a problem for MS, who wanted protected-mode > extensions to DOS (such as Windows 3.x and OS/2 1.x) to be able to use the > real mode I/O kernel of DOS. Their solution was the "mini-reboot" of the > CPU, for which they paid a performance penalty. > > All of these problems went away with the next generation of Intel chips (the > 80386 and beyond), which can quickly toggle between real and protected > modes. Right. In fact, the 80386 introduced "virtual 8086 mode", which allows multiple real-mode virtual 8086 machines running on the same machine. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-22 21:15 ` Robert A Duff @ 2003-04-22 21:19 ` Ed Falis 2003-04-24 2:00 ` Randy Brukardt 0 siblings, 1 reply; 20+ messages in thread From: Ed Falis @ 2003-04-22 21:19 UTC (permalink / raw) On 22 Apr 2003 17:15:09 -0400 Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > The 80186 did not support protected mode. It was practically > identical in architecture to an 8086 or 8088. The 80186 had a small > number of additional instructions -- e.g., pushall for pushing all > registers, I think (for some definition of "all"). It also had bank-switching of memory, but that doesn't quite qualify as "protected mode". > > It was used in mainly in embedded systems, I believe. > > >... and the 80286 chips that powered the IBM PC/AT. These early chips > > supported a command for transitioning from real to protected mode, > > but no simple command for transitioning back to real mode. This is > > what earned these chips the "brain dead" assessment from Gates. Yeah, but that brain-dead design actually allowed the first Ada compiler on a PC. ;-) - Ed ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-22 21:19 ` Ed Falis @ 2003-04-24 2:00 ` Randy Brukardt 2003-04-24 13:49 ` Ed Falis 0 siblings, 1 reply; 20+ messages in thread From: Randy Brukardt @ 2003-04-24 2:00 UTC (permalink / raw) Ed Falis wrote in message <20030422171827.6fb01e6d.falis@adelphia.net>... >Yeah, but that brain-dead design actually allowed the first Ada compiler >on a PC. ;-) Humm, Janus/Ada never needed (or used) the 80286 protected stuff. We still have versions of Janus/Ada 83 that run in 640K on MS-DOS; early partial versions ran in much less memory (the 256K that was common in the early days of the PC). The early Telesoft and Supersoft compilers also ran on basic 8086's. So what are you talking about? Randy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-24 2:00 ` Randy Brukardt @ 2003-04-24 13:49 ` Ed Falis 2003-04-24 18:42 ` Randy Brukardt 0 siblings, 1 reply; 20+ messages in thread From: Ed Falis @ 2003-04-24 13:49 UTC (permalink / raw) On Wed, 23 Apr 2003 21:00:46 -0500 "Randy Brukardt" <randy@rrsoftware.com> wrote: > The early Telesoft and Supersoft compilers also ran on basic 8086's. > So what are you talking about? The Alsys compiler, which I'm pretty sure preceded those. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-24 13:49 ` Ed Falis @ 2003-04-24 18:42 ` Randy Brukardt 2003-04-24 18:49 ` Ed Falis 0 siblings, 1 reply; 20+ messages in thread From: Randy Brukardt @ 2003-04-24 18:42 UTC (permalink / raw) Ed Falis wrote in message <20030424094805.1cb53bd1.falis@adelphia.net>... >On Wed, 23 Apr 2003 21:00:46 -0500 >"Randy Brukardt" <randy@rrsoftware.com> wrote: > >> The early Telesoft and Supersoft compilers also ran on basic 8086's. >> So what are you talking about? > >The Alsys compiler, which I'm pretty sure preceded those. Humm, the early Janus/Ada and Supersoft Ada ran on CP/M on Z-80's, certainly before the 80286 was even invented. And we had Janus/Ada on the PC in early 1982, and was well before the AT was introduced. (We had one of the original PC/XTs, complete with sticker about not unpacking before the introduction date [IBM had sent one to each dealer for display purposes before the introduction of the XT.] - it's serial number was something like 20000000003468.) One can argue about what exactly consistutes an Ada compiler, but I know Janus/Ada was out long before there even was an 80286, and we had competitors at that time. (And, if I still had that PC/XT, Janus/Ada 83 for MS-DOS would run on it and compile and run the entire ACVC 1.11 test suite on it. We did validate compilers on that machine under 1.9 and 1.10. So there certainly is no need for a 80286 to implement a usable Ada 83.) Randy. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-24 18:42 ` Randy Brukardt @ 2003-04-24 18:49 ` Ed Falis 0 siblings, 0 replies; 20+ messages in thread From: Ed Falis @ 2003-04-24 18:49 UTC (permalink / raw) On Thu, 24 Apr 2003 13:42:51 -0500 "Randy Brukardt" <randy@rrsoftware.com> wrote: > One can argue about what exactly consistutes an Ada compiler, but I > know Janus/Ada was out long before there even was an 80286, and we had > competitors at that time. I think validation was the definition, and it wasn't arguable. - Ed ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-16 16:54 Partial Hardware Protection for Buffer Overrun Exploits Warren W. Gay VE3WWG 2003-04-16 17:28 ` Vinzent Hoefler 2003-04-16 19:13 ` Brian Catlin @ 2003-04-17 21:22 ` Robert A Duff 2003-04-21 16:33 ` Warren W. Gay VE3WWG 2 siblings, 1 reply; 20+ messages in thread From: Robert A Duff @ 2003-04-17 21:22 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > REVIEW: > > Buffer exploits work of course, by allowing the attacker to > overwrite a buffer (array) with hacker code to be executed. > Part of this exploit includes the necessity of overwriting > the return address on the _stack_ frame, that the current > function will use when it exits (opcode RET? My assembly > knowledge is admitedly (for Intel) is very rusty). > > The RET instruction is how control is being given to planted > "hacker code". Obviously, this is _not_ what we want > happening on Internet exposed machines. Overwriting the return address is probably the easiest way to gain control, but there are lots of other writeable locations containing addresses that will be jumped to, so the RET/RETT instruction is not the only problem. I also think you underestimate the danger of jumping into existing read-only code. When it comes to security (as opposed to normal run-of-the-mill bugs), the chain is only as strong as its weakest link. So if you close 99% of the holes, you don't prevent anywhere near 99% of the problems. It's a RISC vs CISC thing. The RISC approach is to do bounds-checking in software, and this has been well understood for decades (since before RISC was invented). So it's pretty annoying to have a hardware-based solution, which slows down all returns (and all indirect jumps and calls, I would claim) just because the industry is unwilling or unable to use reasonable programming languages. Your question is really a hardware architecture issue, so you might want to post it to comp.arch. In fact, I think if you search the archives, you'll find similar ideas proposed there. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-17 21:22 ` Robert A Duff @ 2003-04-21 16:33 ` Warren W. Gay VE3WWG 2003-04-21 19:28 ` Robert A Duff 0 siblings, 1 reply; 20+ messages in thread From: Warren W. Gay VE3WWG @ 2003-04-21 16:33 UTC (permalink / raw) Robert A Duff wrote: > "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: >>REVIEW: >> >>Buffer exploits work of course, by allowing the attacker to >>overwrite a buffer (array) with hacker code to be executed. >>Part of this exploit includes the necessity of overwriting >>the return address on the _stack_ frame, that the current >>function will use when it exits (opcode RET? My assembly >>knowledge is admitedly (for Intel) is very rusty). >> >>The RET instruction is how control is being given to planted >>"hacker code". Obviously, this is _not_ what we want >>happening on Internet exposed machines. > > Overwriting the return address is probably the easiest way to gain > control, but there are lots of other writeable locations containing > addresses that will be jumped to, so the RET/RETT instruction is not the > only problem. I've already acknowledged this fact, in an earlier post. > I also think you underestimate the danger of jumping into existing > read-only code. Whether or not I am "underestimating" is not important. I have however, already pointed out the danger of exploiting some existing "code" in the "read-only" region. But what point are you making here? Based upon your response, it seems to be something like "we shouldn't make any hardware change", to which, I have to disagree. > When it comes to security (as opposed to normal run-of-the-mill bugs), > the chain is only as strong as its weakest link. This part I agree with (at least in the long run). > So if you close 99% of > the holes, you don't prevent anywhere near 99% of the problems. Looking at the larger picture, I disagree slightly. Yes, in the long run, this will be the result if the issues are not all addressed. In the short term however, you _do_ eliminate an entire class of problems. This can be useful, for several reasons: i) to buy time, in order to address the other 1% ii) to make writing exploits so difficult, that the script kiddies won't bother any more (ie. fewer exploits are in the wild) iii) Some programs may not actually have that 1% vulnerability, and so they might represent a class of programs that can be trusted (ideal if this includes servers on the net side). iv) get people and CPU engineers thinking along this line to come up with other innovative solutions. For example, there's no reason that a jump to register instruction cannot be limited to text only code. > It's a RISC vs CISC thing. The RISC approach is to do bounds-checking > in software, and this has been well understood for decades (since before > RISC was invented). So it's pretty annoying to have a hardware-based > solution, which slows down all returns (and all indirect jumps and > calls, I would claim) just because the industry is unwilling or unable > to use reasonable programming languages. I entirely disagree that this needs to "slow down" anything. If anything, a soft approach is slower(!). The CPU already must translate a virtual address (of any kind), and by the time the real address goes out to the cache and to memory, the information necessary for read-only (or not) is already known by the CPU. All it needs to do is test that flag (one entire bit, mind you ;-), and choose to accept the address or abort. > Your question is really a hardware architecture issue, so you might want > to post it to comp.arch. In fact, I think if you search the archives, > you'll find similar ideas proposed there. > > - Bob Even better! Let's have Intel/AMD/IBM implement it in hardware. If people start asking for it, then maybe we'll actually get workable solutions. -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Partial Hardware Protection for Buffer Overrun Exploits 2003-04-21 16:33 ` Warren W. Gay VE3WWG @ 2003-04-21 19:28 ` Robert A Duff 0 siblings, 0 replies; 20+ messages in thread From: Robert A Duff @ 2003-04-21 19:28 UTC (permalink / raw) "Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> writes: > I've already acknowledged this fact, in an earlier post. True. But you didn't acknowledge the consequence given the "weakest link in chain" issue. > > I also think you underestimate the danger of jumping into existing > > read-only code. > > Whether or not I am "underestimating" is not important. I have > however, already pointed out the danger of exploiting some > existing "code" in the "read-only" region. But what point > are you making here? I was trying to make the "weakest link in chain" point. > Based upon your response, it seems to be something like "we > shouldn't make any hardware change", to which, I have to > disagree. Well, "we" as in "you and me" aren't making any changes to the Intel hardware architecture, as far as I know. ;-) But, yes, I'm saying there's no point in making hardware changes that will fix only part of the problem. I admit that my opinion might be colored by a "purist" attitude: the "right" solution is array bounds checking done in software. > > When it comes to security (as opposed to normal run-of-the-mill bugs), > > the chain is only as strong as its weakest link. > > This part I agree with (at least in the long run). OK. But note that hardware changes are necessarily "long run". > > So if you close 99% of > > the holes, you don't prevent anywhere near 99% of the problems. > > Looking at the larger picture, I disagree slightly. Yes, in the > long run, this will be the result if the issues are not all > addressed. > > In the short term however, you _do_ eliminate an entire class > of problems. This can be useful, for several reasons: > > i) to buy time, in order to address the other 1% Shrug. > ii) to make writing exploits so difficult, that the script > kiddies won't bother any more (ie. fewer exploits are > in the wild) I don't know much about "script kiddies", but I was under the impression that they can bring sophisticated technology to bear, via scripts, even if they don't understand much. > iii) Some programs may not actually have that 1% vulnerability, > and so they might represent a class of programs that can > be trusted (ideal if this includes servers on the net side). Well, if you mean programs that don't need write access to executable memory, then I agree there's a reasonable class of such programs. If you mean programs that don't do indirect jumps/calls, then no. > iv) get people and CPU engineers thinking along this line > to come up with other innovative solutions. > > For example, there's no reason that a jump to register instruction > cannot be limited to text only code. > > > It's a RISC vs CISC thing. The RISC approach is to do bounds-checking > > in software, and this has been well understood for decades (since before > > RISC was invented). So it's pretty annoying to have a hardware-based > > solution, which slows down all returns (and all indirect jumps and > > calls, I would claim) just because the industry is unwilling or unable > > to use reasonable programming languages. > > I entirely disagree that this needs to "slow down" anything. If anything, > a soft approach is slower(!). The CPU already must translate a virtual > address (of any kind), and by the time the real address goes out to > the cache and to memory, the information necessary for read-only (or not) > is already known by the CPU. All it needs to do is test that flag > (one entire bit, mind you ;-), and choose to accept the address or > abort. Yeah, I guess you're right on this point. What you need is protection bits that express executable-but-not-writeable, and corresponding OS support. But I still say, the "chain links" thing is important. One must at least address all indirect jumps, not just return instructions. - Bob ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2003-04-24 18:49 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2003-04-16 16:54 Partial Hardware Protection for Buffer Overrun Exploits Warren W. Gay VE3WWG 2003-04-16 17:28 ` Vinzent Hoefler 2003-04-17 16:33 ` Warren W. Gay VE3WWG 2003-04-17 21:29 ` Robert A Duff 2003-04-16 19:13 ` Brian Catlin 2003-04-17 15:00 ` Bob French 2003-04-17 16:14 ` Warren W. Gay VE3WWG 2003-04-17 23:22 ` Randy Brukardt 2003-04-21 16:42 ` Warren W. Gay VE3WWG 2003-04-21 17:26 ` tmoran 2003-04-22 1:40 ` Frank J. Lhota 2003-04-22 21:15 ` Robert A Duff 2003-04-22 21:19 ` Ed Falis 2003-04-24 2:00 ` Randy Brukardt 2003-04-24 13:49 ` Ed Falis 2003-04-24 18:42 ` Randy Brukardt 2003-04-24 18:49 ` Ed Falis 2003-04-17 21:22 ` Robert A Duff 2003-04-21 16:33 ` Warren W. Gay VE3WWG 2003-04-21 19:28 ` Robert A Duff
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox