Re: [Sheflug] Re: Segfaults & ld.so wierditude

[Matthew John Palmer <nospam [at] uow.edu.au>]

On Wed, 3 May 2000, Bob Ham wrote:

> > > allowed to write over malloc()'s hosuekeeping data?
> > 
> > Where else is malloc() going to keep it's data?  You've got to remember that
> > malloc() is within the purvue of the process, and doesn't have access to any
> > memory that any code that you write doesn't have access to (mprotect not
> > withstanding).
> 
> I assumed the heap was a system-wide thing, with blocks being allocated
> all over the heap to processes, as opposed to each process having a
> heap.  I'm not that well versed in low-level OS stuff :)

No, each process has it's own malloc thing going.

What malloc basically does is keep a list of memory pages that are it's
personal domain.  When a request for memory comes in, it checks it's free
blocks list for a space to put your request into.  If it finds one, it
updates it's free block table, writes some housekeeping data to the
beginning of the block, and wgives you the memory address of tthe start of
where you're allowed to write memory.

If there isn't a spare block available that's big enough, it goes and gets
another page (or severla, if you've requested that much memory) and then
continues as above.  If it can't get a page from the OS, it'll return NULL
and set errno == ENOMEM.

At least, that's how it's usually done.  There's no rule that it has to be
done like that, but however it's done, it's all done in the process' address
space.  The page bit is why it's sometimes possible to write to addresses
which aren't exactly in your malloced bit but aren't too far away, without
segfaulting - because, although malloc didn't say you could write there,
it's still got that address available to do stuff with.

> > > >     >> Have you tried Electric Fence and cousins?
> > > > 
> > > >     Bob> Never heard of it; care to expand on that?
> > 
> > Immediately segfaults on any access to a memory area not allocated to the
> > process' data area.  This is useful because a process can usually fiddle
> > with data that it hasn't allocated, but is still in the current memory page.
> 
> Is that implemented as a library with its own version of malloc(), or
> does it replace glibc's malloc() somehow?

Replaces the malloc system above with an extended version that does an
mprotect (stops you reainding, writing, or thinking about the memory area)
on any memory that the process is not allowed to fiddle with.  Of course,
before it does a free() or allocates new space or anything, it munprotect()s
the appropriate bit, does it's fiddle, then mprotect()s again before
returning to your code.

When I first used it, I thought it was useless.  Then I started writing real
programs, rather than toy programs.  It's now a constant companion, along
with ccmalloc.

> > With this you can determine the instruction that is writing somewhere it
> > shouldn't, because running the program in a debugger, the segfault will
> > allow you to do a bt and find out the call chain.
> 
> Indeed useful; as I say, I assumed that was what you got a segfault for.
> If my programs in fact are allowed to write to bits in its page that
> aren't allocated to it, that would indeed be helpful.

Well, the page is technically allocated to your process, but your code
shouldn't be playing with bits it hasn't told itself it can use (so to
speak).  That's what efence is good for  -enforcing that rule.  It's kind of
like putting a lock on the cookie jar and giving the key to someone else -
you're regulating something that's yours by not trusting yourself.

Good security paradigm.

> I have fixed the bug now; it was a double free().  I'd modified a
> function to use realloc() instead of a static char array, and assign it
> to a char ** arguement, but for some reason I put a free() in there
> (yes, I am stupid :)

No, we've all made dumb mistakes like that.  I once wrote a huge chunk of
code in which all of the string allocations were done with

newstr = malloc(strlen(oldstr + 1));

And then I wondered why efence was complaining when I did the subsequent
strcpy().


-- 
-----------------------------------------------------------------------
#include <disclaimer.h>
Matthew Palmer
mjp16@uow.edu.au

---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.