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?
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php