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

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



Thats really funny openBSD have currently a bug in it's system call :
they didn't verify the boundary of the adresse (like i have explain it).
A local user could gain access root by executing what ever kernel code
he want.

That's exactly our discution. 

http://marc.theaimsgroup.com/?l=openbsd-announce&m=102910116106798&w=2

nicO

-----Message d'origine-----
De: nico <nicolas.boulay@ifrance.com>
A: f-cpu@seul.org
Date: 11/08/02
Objet: Re: Rep:Re: Rep:Re: Rep:Re: [f-cpu] TLB resume

Michael Riepe a écrit :
> 
> On Fri, Aug 09, 2002 at 08:26:50AM +0000, Nicolas Boulay wrote:
> [...]
> > >>> Kernel does not have it's own ASI. It is in the memory space in
> > every process.
> 
> That depends on the OS.
> 
> > Note that it may be possible to use a single set of access bits - if
> > they are valid for both user and supervisor mode (I'll have to think
> > that over).
> >
> > >>> there is always the same conceptual probleme : the kernel decide
the
> > right to put in the tlb. It's one of it's role. Usually kernel is
always
> > trusted.
> 
> And exactly that is the problem.
> 
> > But `supervisor mode is allowed to access everything' is a
> > BIG mistake.
> >
> > >>> Maybe. x86 is a big shit in this topic, but i have never heard
about
> > tricks to compromise the kernel that way. Kernel hacker meet at lsm
does
> > not speak about that (grsecurity patch maintainer (who mainly try to
> > simulate a true none executing bit in x86), VM designer of the
hurd).
> > Maybe you discover a new concept of cracking. But i think it's
really
> > easy to verify the pointer given by the user process.
> 
> Depends on the OS, again.
> 

The real and only danger is to given a kernel page to a kernel function.
I don't understand the problem of using software verification of it. If

the kernel is bad written it's is problem !

> > >>>Because the kernel is trusted, i can't imagine that you could
> > compromise it's security by a call to it's own API. Because kernel
could
> > change the right in the tlb it could access what ever he want. If
you
> > want to make things like chmod (that could unallowed to access a
file
> > but a run of chmod could change that), how could the kernel be run
> > without virtual adress. I think that should be done during task
switch
> > (christophe ?).
> 
> *Because* the kernel ist trusted, it is one of the main targets for
> attacks. If you manage to hack the kernel, you can do everything
> (compare root kits and `trojan' kernel modules).

What you speak about is the use of kernel modules of linux used to
hijack os call to hide a back door or something like. It's possible
because this module run in kernel space : that not the case in
microkernel os. And this module could only be loaded if you gain the
root access. So before puting a kernel code, you must have root access.

> Therefore, the kernel
> needs *more* protection than a (user) process with root privileges,
> not less.

Because the kernel (or the tiny part of the microkernel that have all
the right : VM and scheduling) must have all the right. It's a conceptal
point. How could you restricit the right of a kernel that have all the
right : it's like setting rwx specific right for root in a unix file
system. For me, it does not make a sense.

All the danger you speak about could only be done at the design of the
OS. It's a story of right management. F-cpu could provide means for
that. But rwx bit for superuser mode...

Kernel will avoid to read or write in specific pages and trap in kernel
and make a kernel_core_dump ? I really need the opinion of Christophe.

Maybe a rwx specific right for defining a new ring for librairy could be
used ?

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/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/


______________________________________________________________________________
Pour mieux recevoir vos emails, utilisez un PC plus performant !
Découvrez la nouvelle gamme DELL en exclusivité sur i (france)
http://www.ifrance.com/_reloc/signhdell

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