On Fri, Feb 07, 2003 at 05:38:04PM -0500, Len Sorensen wrote:
> I was playing around with figuring out why dba_open creates an ndbm
> database when run in stand alone mode (as requested) but creates a db2
> database when run as an apache module.  This is in php 4.2.3 on a Debian
> 3.0 system.  I haven't tried with 4.3 yet.  I am not sure if this is a
> bug somewhere, or a configuration problem, but it does seem odd.
> Something I noticed while playing with this, is that all the files
> created by dba_open contain a lot of other old memory contents from the
> apache/php process when created, some of which perhaps shouldn't be
> dumped into files being saved.
> My guess is that when the db lib used by dba_open creates a file, it
> does a malloc of a certain size, and uses that as the basis for the
> file, and it doesn't clear this memory (after all why should it care
> what is in it before it creates it's db structure).  I assume that when
> php's garbage collector frees memory, it does not clear it, and hence
> script code, sql query contents, etc are still present in the freed
> memory, which may be allocated by another malloc later in the same
> thread without being cleared (since it was already used by that process
> there is no point in the OS clearing it, assuming the OS is ever
> responsible for clearing memory).  As a result, content of SQL queries
> sent to postgres from a previous request on that web server, may end up
> written to the db2 or ndbm or gdbm file (whichever is used), when you
> create a new file with dba_open, meaning potentially private information
> could end up in a file you may end up giving to someone else later.
> So does anyone have any idea who is to blame for this problem?  Is it
> PHP?  libc?  The OS?  Apache?  The DB library in use?  I am certainly
> not sure, but given I don't know of a way for the php user to make php
> wipe it's memory, I can't think of any way to prevent the data from
> ending up in the file, short of changing the lib*db* code to zero the
> memory it allocs before writing the file.  Somehow that seems like the
> wrong place to attack it.  Calling bzero every time you call free in php
> also seems like the wrong approach.
> Opinions and possible fixes are welcome.
> Telling me another mailing list that is better suited for the question
> would be fine too given this could happen with other libraries included
> with php.

I also occoured to me, that any user that can create php scripts and run
them, could use dba_open, to dump a chunk of memory to a file, and then
send that file using readfile, or the like to the user viewing the page,
even if that file isn't in a location apache itself would serve.  What if
that memory dump contained passwords used on other parts of the site?
Does this concern anyone else?

Len Sorensen

PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to