On Sun, Jul 29, 2007 at 11:18:29PM -0400, Steven M. Bellovin wrote:
> On Sun, 29 Jul 2007 12:37:26 +0200
> Adam Hamsik <haaaad@gmail.com> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> > On Jul 29, 2007, at 7:57 AM, Darren Reed wrote:
> > 
> > > Simon 'corecode' Schubert wrote:
> > > ...
> > >> But the writer is not supposed to write there in the first place!
> > >> >> But even if this is a bug in the writer (writing after the end
> > >> >> of the
> > >> (mapped) file), it is still writing to a file which can be read by
> > >> >> users with the appropriate permissions.  I don't really see a
> > >> >> security >> problem
> > >> there.
> > >
> > > If buggy software writes in an area of memory that it shouldn't,
> > > lets say it puts your password there by accident, then it appears
> > > another process can get that.
> > >
> > if buggy software creates file in /tmp with my password other process
> > can get that pass ,too.
> > 
> > > It is a security exposure (but not a serious one) because it is a
> > > means for data from one application to be "stolen" by another.
> > >
> > I doesn't see your point here, it's application problem.
> 
> No, Darren is right.  Consider this text from the Orange Book, the 1985
> US Department of Defense security criteria standard:
> 
>      2.2.1.2   Object Reuse
>              
>          WHEN A STORAGE OBJECT IS INITIALLY ASSIGNED, ALLOCATED,
> 	OR REALLOCATED TO A SUBJECT FROM THE TCB'S POOL OF
> 	UNUSED STORAGE OBJECTS, THE TCB SHALL ASSURE THAT THE OBJECT
> 	CONTAINS NO DATA FOR WHICH THE SUBJECT IS NOT AUTHORIZED.

But the object here (the memory page) is not in the pool of unused object,
it belongs to the mapped file.

Pavel