Computer Hardware Forum

In comp.sys.ibm.pc.hardware.chips Grumble <a@b.c> 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

>

Report this post to a moderator

[  Post Follow-up to this message ]

>> You don't call any other function in your recursive functions? :-)
> Hey, I avoid recursion.

Too bad.  Usually makes for clean and simple code, whose security is
simpler to verify.


Stefan

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.sys.ibm.pc.hardware.chips Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> And how does the kernel "decide what to do"?

Whatever it's been programmed to do, likely on a per-process basis.
Likely it'd start APatchy with something like
# /usr/sbin/nooverflow httpd &

> It's so simple to prevent buffer overflows, there's really no reason to go

Simple?  Writing good code is simple?  Wading through millions
of lines of cruft is simple?

> to the trouble of some special hardware mechanism to catch some "odd"
> behavior which may sometimes catch some forms of buffer-overflow-exploits.

I don't think there are that many forms of buffer overflows.
All result from an open ended IO call like gets().
Do you know any other kinds?

> Can be pretty frequent with some languages/compilers, although admittedly

Which ones?  mispairing call/ret is a fast way to overflow the stack.

-- Robert

Report this post to a moderator

[  Post Follow-up to this message ]

>> And how does the kernel "decide what to do"?

> Whatever it's been programmed to do, likely on a per-process basis.
> Likely it'd start APatchy with something like
> # /usr/sbin/nooverflow httpd &

Say a mismatch (it's not just overflows) happens in a program that uses
exceptions (and where mismatches are hence not necessarily a sign of
a buffer-overflow-exploit): how is the kernel to determine if a given
mismatch is harmless?
 
> Simple?

Trivial: use a language where it's automatically enforced.
I.e. basically any language other than C.  Or use a C compiler that goes
through the extra trouble of trying to prevent overflow exploits
(i.e. by allocating stack variables on a separate stack, or by using fat
pointers, or ..).
 
> I don't think there are that many forms of buffer overflows.

Maybe not, but they can happen in many different kinds of code and there can
be many forms of exploits.  So it can be between very difficult and
impossible for a low-level system to determine if a given behavior is part
of the normal execution or is the sign of an exploit.


Stefan

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.sys.ibm.pc.hardware.chips Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Say a mismatch (it's not just overflows) happens in a program that uses
> exceptions (and where mismatches are hence not necessarily a sign of
> a buffer-overflow-exploit): how is the kernel to determine if a given
> mismatch is harmless?

Well if the pgm has designed-in mismatches, the kernel can't
determine it, and the the pgm would have to be run with that
protection disabled.  But how many languages (other than asm)
even _allow_ mismatched call/ret?

> Maybe not, but they can happen in many different kinds of code and there c
an
> be many forms of exploits.  So it can be between very difficult and
> impossible for a low-level system to determine if a given behavior is part
> of the normal execution or is the sign of an exploit.

Well, actually there is another way.  The OS could monitor
events like return adress mismatches and take defensive
actions when an increase is noted.

-- Robert

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.arch Yousuf Khan <bbbl67@ezrs.com> wrote:
> Sander Vesik <sander@haldjas.folklore.ee> wrote: 
>
> The only place you can run code is from the code segment. If you insert code[/vbco
l]

only superficialy true. as you have control of the stack, you can cause any
number of function calls to happen with the parameters of your choice. This
is essentialy the same as running code.

> into the stack segment, none of it will be executable. At best it might en
d
> 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.

Only if you don't know the addresses of functions and system calls.

>
>     Yousuf Khan
>
>

--
Sander

+++ Out of cheese error +++

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.arch Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> In comp.sys.ibm.pc.hardware.chips Stefan Monnier <monnier@iro.umontreal.ca
> wrote: 
>
> Whatever it's been programmed to do, likely on a per-process basis.
> Likely it'd start APatchy with something like
> # /usr/sbin/nooverflow httpd &
> 
>
> Simple?  Writing good code is simple?  Wading through millions
> of lines of cruft is simple?
> 
>
> I don't think there are that many forms of buffer overflows.
> All result from an open ended IO call like gets().
> Do you know any other kinds?

Yes. Accepting user provided content length and not checking it against
your buffer size.

> 
>
> Which ones?  mispairing call/ret is a fast way to overflow the stack.
>
> -- Robert
>

--
Sander

+++ Out of cheese error +++

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.arch Robert Redelmeier <redelm@ev1.net.invalid> wrote:
> In comp.sys.ibm.pc.hardware.chips Stefan Monnier <monnier@iro.umontreal.ca
> wrote: 
>
> Well if the pgm has designed-in mismatches, the kernel can't
> determine it, and the the pgm would have to be run with that
> protection disabled.  But how many languages (other than asm)
> even _allow_ mismatched call/ret?

Consider a user mode threads package that uses get/setcontext()
or setjmp / longjmp and so on.

>
> -- Robert
>

--
Sander

+++ Out of cheese error +++

Report this post to a moderator

[  Post Follow-up to this message ]

In comp.sys.ibm.pc.hardware.chips Sander Vesik <sander@haldjas.folklore.ee> wrote:
> Consider a user mode threads package that uses
> get/setcontext()  or setjmp / longjmp and so on.

Well, I'm not entirely sure how these constructs are
implemented by the compilers, but I would expect a
simple `jmp` instruction.  This does NOT disturb the
hw call/ret stack, nor pose any buffer-overflow danger.

-- Robert

Report this post to a moderator

[  Post Follow-up to this message ]

>> Say a mismatch (it's not just overflows) happens in a program that uses 

> Well if the pgm has designed-in mismatches, the kernel can't
> determine it, and the the pgm would have to be run with that
> protection disabled.  But how many languages (other than asm)
> even _allow_ mismatched call/ret?

Any language with exceptions: C++, Java, C (with setjmp/longjmp), ..
 

> Well, actually there is another way.  The OS could monitor
> events like return adress mismatches and take defensive
> actions when an increase is noted.

A buffer-overflow exploit might only need one mismatch.


Stefan

Report this post to a moderator

[  Post Follow-up to this message ]