[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Rep:Re: [f-cpu] TLB resume



Well there can be supervisor pages which are only data and should not be
used for execution, so we need to set sx (supervisor,execute bits) to 0. For
example the stack, so no application can try to pull code in a stack and
execute it.

There are many things where using supervisor right bits can be useful.

----- Original Message -----
From: "Nicolas Boulay" <nicolas.boulay@ifrance.com>
To: <f-cpu@seul.org>
Sent: Wednesday, August 07, 2002 9:31 AM
Subject: Rep:Re: [f-cpu] TLB resume


-----Message d'origine-----
De: Michael Riepe <michael@stud.uni-hannover.de>
A: f-cpu@seul.org
Date: 07/08/02
Objet: Re: [f-cpu] TLB resume

On Wed, Aug 07, 2002 at 12:54:32AM +0200, nico wrote:
[...]
> > If supervisor mode is allowed to always access everything, you have
a
> > big security hole.
>
> Could you explain why ?

Because when a user process calls the OS kernel, the system call is
executed with supervisor access rights. That is, you can take an address
that you're not allowed to access and pass it to the kernel, and the
kernel *is* allowed to access it. You'll have to add rather expensive
memory bounds checks to almost every system call in order to prevent
that.
Sacrificing three bits per TLB entry is cheaper (and more secure).
---
>>> ??? In an adress space, the process could see what ever he want.
Kernel are just mapped in the same adress in each AS to avoid trashing
of the caches. (Christophe speak about a "global" that come from the x86
world. It say that virual adresse is OK for every AS. It avoid tlb
miss.)

In the AS, there is only data relevant to the user, to the librairy and
to the kernel. Kernel page have none of the RWE bit set. To change the
ring (pass from the user mode to the superuser one), you need something
as trap, a specific call using vector adress. The adress are well known
and defined as OS call.

The exploit of buffer overflow could try to change the content of a
librairy, to run "excve sh" (no need to have an executing stack, only
the good parameter in the stack and the return adress of a function
replace by those of a librairy function) or write you're code inside the
librairy code. This could be defait by changing the memory location of
the librairy (random adress at load), it became very hard to find good
adresses.

An other trick could be to use an other ring for librairie. So you enter
the librairy as you enter in the kernel, with a kind of trap. This could
only be used for dangerous function. Then you could protect the librairy
space by adding RWE bit for a "librairy ring" or "librairy user", user
bit will be 0 for such pages.

The last exploit use the mmap fonction. You mmap a file with RWE right
and then execute it (by replace a return adress by the adress of the
buffer mmaped). Ring doesn't change anything on this, the only way to
avoid it, is to disable the possibility to run a function call using a
buffer overflow (as for excve).

Our API are very less smart for crackers than those from x86. Most of
the time the return adresse are on the register set. Because we need for
none leaf function to save the return adress, i have proposed to use a
specific return adress stack that could'nt be erased by buffer overflow.

I don't understand why we need 3 superuser bits for that. The process
does not know about other AS and kernel page could not be accessed. So ?

nicO

--
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


____________________________________________________________________________
__
Nouveau sur i (france), ne vous faites pas piquer votre nom!
Réservez dès à présent votre nom de domaine pour 1 Euro* HT/mois (*à partir
de)
http://www.ifrance.com/_reloc/signdom

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/

*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/