John Summerfield scribbled:
> On Sat, 9 Nov 2002 01:09, you wrote:
> > On Thu, 2002-11-07 at 19:11, John Summerfield wrote:
> > > On IA32, if it's not in the code segment, you can't execute it.
> > >
> > > The code segment _can_ be ro, so presumably a return to arbitrary code
> > > can be prevented.
> >
> > I dont need to modify any of the code segment to exploit your machine.
> > In fact several exploits work on the basis they overrun a stack section
> > with a complete return sequence including variables to cause an
> > execlp("/bin/sh", ...) to occur. No code changes needed
>
> Is this a reason to not close down those avenues that are easy? Seems to me
> that if you fix some, you have fewer left to fix.
>
> As the philospher said, a journey of a thousand leagues starts with a single
> step.
The issue is the segmentation; In the IA32 architecture the
segment registers still exist and the LDT (local descriptor
table, describing the segments available to a particular
process) along with GDT (global descriptor table) provide
information about how memory is mapped.
There are some "cookies" in the segment registers that condition
things, but that's not particularly germane. (Two bits are
privilege bits and one bit is the LDT/GDT selector.)
In order to implement a "flat" memory model the IA32 architecture
most often just has the segment registers point to a "flat"
structure where all of the segments start in the same place and
are the same size; Unless things have changed a lot in these
CPUs since the 486, this is how they work.
The ia32 architecture also provided for "call gates" which were
meant to be managed jumps to a privileged state for syscalls.
This doesn't help libraries much though.
The weakness of the flat memory model comes from a lack of
differentiation; Segment limitations are still in place but
the same address can be executed since it's the same byte in
the Code segment, Data segment, Stack segment and Extra segment.
The flat memory model took away the main feature of segmentation
yet gave us a "simpler" mechanism for managing memory.
I'm not sure we can do much to work around this because intel
was the only architecture that really used segment registers-
and that's a throwback to the 80286 and 8086 days.
Neither the MC68K, Alpha or PowerPC really use segmentation in
the same way (although the PowerPC memory mapping implies a
"segmentation" mechanism, it's all faked within a flat address
space) and I don't *ever* recalling anything special in the
old s/360 and s/370 architecture that would render clumps of
memory "unexecutable".
Sorry for the pedantry- I moved a FORTH-based application from
a protected-mode i286 to the 486 by slipping LynxOS under it-
so I had to be familiar with how segmentation worked on both
platforms. The code, data and stack segments always pointed
to the same area of ram for a user program.
--
John R. Campbell Speaker to Machines [EMAIL PROTECTED]
- As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!
"It is impossible for ANY man to learn about impotence the hard way." - me
"ZIF is not a desirable trait when selecting a spouse." - me
