If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#21
|
|||
|
|||
Robert Redelmeier wrote:
In comp.sys.ibm.pc.hardware.chips Grumble wrote: I think you've just killed the performance of recursive functions. I don't think so. For a recursive function there are many calls, possibly flooding out the hw return stack. But every call has a return, and that address _is_ correct on both the hw and memory stacks. You don't call any other function in your recursive functions? :-) 88h IC Return stack hit 89h IC Return stack overflow It would be interesting to take, say, SPEC CPU2000, and count the number of overflows for each benchmark. I might try. Excellent! I do not suggest trapping out overflows. They're to occur on deep recursion which should not contain evil getch() calls. Just trap misses. As far as I can tell, and with the exception of recursive functions which call no other function, RAS overflow will cause a RET misprediction. |
#22
|
|||
|
|||
Benny Amorsen wrote:
"YK" == Yousuf Khan writes: That was Minix. Linux has always been for 386 and later machines only. I think the ELKS people will be saddened to hear that. So, it never surprises me to find Linux being ported to do something or another at some point in time. I guess the question these days to ask is whether there is something Linux hasn't been ported to? Commodore 64? Apple II? Yousuf Khan |
#23
|
|||
|
|||
Robert Redelmeier wrote:
True in a literal sense. But `c` compilers have this habit of allocating local variable space on the stack. So when `char input[80];` is coded in a routine, ESP gets decreased by 80 and that array is sitting just below the return address! I don't think it's _required_ by any standard that local vars are allocated on the stack, but it sure makes memory managment easy. AFAIK, only global vars and large malloc()s are put on the heap. Still the only place where code can be executed from is the CS segment. You cannot write anything into the CS segment once you're running, so even if they screw up the stack somehow, then worst that's going to happen is that the program will stop working and have to be shut down by the OS. Which is basically what NX on the page tables does these days. Segments would've fully protected everything. Yousuf Khan |
#24
|
|||
|
|||
In comp.arch Yousuf Khan wrote:
Robert Redelmeier wrote: In comp.sys.ibm.pc.hardware.chips Yousuf Khan wrote: How's an attacker to do that, when the the code, the stack and the heap don't even share the same memory addresses? Easy. Overwrite the stack with crafted input to an unrestricted input call (getch() is a frequent culprit). This is the basic buffer overflow. In the location for the return address (where EBP is usually pointing), put in a return address that points to a suitably dangerous part of the existing code. Like an `exec` syscall. Above this return address, put in data to make that syscall nefarious. Nope, won't work. Segmentation would protect it completely. There is no way for data written to the heap to touch the data in the stack. Stack segment But procedure local variables (including arrays) don't live in the heap, they live on the stack. and data segment are separate. It's like as if the stack had its own container, the code has its own, and the data heap its own. What happens in one container won't even reach the other containers. Doesn't matter. All you need for an exploit is to be able to make *one* system call. And for that, you don't need to write to the code segment at all. The stack is enough. Face it, segments were the perfect security mechanism, and systems developers completely ignored it! Yousuf Khan -- Sander +++ Out of cheese error +++ |
#25
|
|||
|
|||
Sander Vesik wrote:
and data segment are separate. It's like as if the stack had its own container, the code has its own, and the data heap its own. What happens in one container won't even reach the other containers. Doesn't matter. All you need for an exploit is to be able to make *one* system call. And for that, you don't need to write to the code segment at all. The stack is enough. The only place you can run code is from the code segment. If you insert code into the stack segment, none of it will be executable. At best it might end up causing the return address to go to the wrong part of the code segment and therefore run the program from the wrong point, but more likely the program will just end up locking up and be shutdown by the OS. Yousuf Khan |
#26
|
|||
|
|||
On Thu, 27 May 2004, Yousuf Khan wrote: The only place you can run code is from the code segment. If you insert code into the stack segment, none of it will be executable. At best it might end up causing the return address to go to the wrong part of the code segment and therefore run the program from the wrong point, but more likely the program will just end up locking up and be shutdown by the OS. Changing branch address and stack values that get loaded to arument registers (or just plain stack values on a stack machine) are enough. An object dump of a binary with stack overflow reveals the address of a "system call" instruction, which is enough to know what return adress is needed. i.e. you don't need new code to execute you just need to get to existing insn's in the binary with the appropriate state, and that appropriate state can be set up with stack only overwriting. Period. Peter |
#27
|
|||
|
|||
Yousuf Khan wrote:
Sander Vesik wrote: and data segment are separate. It's like as if the stack had its own container, the code has its own, and the data heap its own. What happens in one container won't even reach the other containers. Doesn't matter. All you need for an exploit is to be able to make *one* system call. And for that, you don't need to write to the code segment at all. The stack is enough. The only place you can run code is from the code segment. If you insert code into the stack segment, none of it will be executable. At best it might end up causing the return address to go to the wrong part of the code segment and therefore run the program from the wrong point, but more likely the program will just end up locking up and be shutdown by the OS. Yousuf Khan Yousuf, Check out the following link: http://packetstormsecurity.nl/groups/horizon/stack.txt which explains how you can do overflow attack when stack is not executable. Although this is illustrated in Solaris/SPARC, it equally applies to any x86. Seongbae |
#28
|
|||
|
|||
Segments would've fully protected everything.
Your assurance is endearing. But re-read the thread for a counter example where the only code executed (in this process anyway) already exists (it just forks off a /bin/sh shell). Segments protect just as "fully" as separate address spaces do. It's better than nothing, but unless you're extremely careful, it's not sufficient for real security. Better make sure buffer overflows *can't* happen, so you can actually reason about properties of your code. Stefan |
#29
|
|||
|
|||
In comp.sys.ibm.pc.hardware.chips Grumble wrote:
You don't call any other function in your recursive functions? :-) Hey, I avoid recursion. But if you called another fn, it too would return. As far as I can tell, and with the exception of recursive functions which call no other function, RAS overflow will cause a RET misprediction. It should case a RET misprediction even then unless it duplicates TOS when it pops. For use as a security mechanism, it'd be better if TOS was tagged empty or missing. Then no MCE. -- Robert |
#30
|
|||
|
|||
In comp.sys.ibm.pc.hardware.chips Yousuf Khan wrote:
Still the only place where code can be executed from is the CS segment. You cannot write anything into the CS segment once you're running, so even if they screw up the stack somehow, then worst that's going to happen is that the program will stop working and have to be shut down by the OS. Which is basically what NX on the page tables does these days. I can see I haven't made myself clear: An exploit doesn't need to execute it's own code! Merely jumping to a suitable place in existing, blessed code (an exec() call) with nefarious data [stack] is sufficient to be exploitable. -- Robert |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
HELP: P4C800-E Deluxe, Intel RAID and Windows detection problems | Michail Pappas | Asus Motherboards | 2 | November 20th 04 03:18 AM |
Intel developers helping out with Linux AMD64 | Yousuf Khan | Intel | 0 | December 17th 03 08:41 PM |
Intel Updates Plans Again: Adds Pentium 4 EE at 3.40GHz and Pentium 4 at 3.40GHz | lyon_wonder | General | 2 | November 10th 03 11:17 PM |
Intel | Commander | Intel | 0 | October 30th 03 07:05 PM |
Intel wants to slow down platform changes | Rob Stow | Intel | 0 | July 1st 03 05:29 PM |