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
