[20482] in bugtraq

home help back first fref pref prev next nref lref last post

Re: x86 vulnerability

daemon@ATHENA.MIT.EDU (Matt Chapman)
Fri Apr 27 04:12:07 2001

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <20010427102948.A875@cse.unsw.edu.au>
Date:         Fri, 27 Apr 2001 10:29:48 +1000
Reply-To: Matt Chapman <matthewc@CSE.UNSW.EDU.AU>
From: Matt Chapman <matthewc@CSE.UNSW.EDU.AU>
X-To:         Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <tgd79zok0y.fsf@mercury.rus.uni-stuttgart.de>; from
              Florian.Weimer@RUS.UNI-STUTTGART.DE on Thu, Apr 26,
              2001 at 03:41:49PM +0200

On Thu, Apr 26, 2001 at 03:41:49PM +0200, Florian Weimer wrote:
>
> Has anybody looked at the LDT modification syscall in the Linux
> kernel?  The most severe problems with it were fixed back in 1997 or
> so, but the code seems to have changed substantially since then.

As far as I can see Linux modify_ldt syscall only allows you to
create code/data segments, not system descriptors (e.g. call gates).
It is true that some of the values are OR'd in to the destination
descriptor without masking.  However, system segments need bit
12 of entry_2 set to 0, and there is a fixed or with 0x7000 which
thwarts this possibility (lucky the Intel designers didn't choose
the inverse logic!), and also enforces privilege level 3.

I doubt there's anything nasty one can do with regular segment
descriptors at DPL 3, since the user already has ones spanning
the entire address space.

	Matt

home help back first fref pref prev next nref lref last post