Re: mcrypt issues

Hello, crashes that are related to closing modules are probably because a change in the mcrypt library... I just found this in the manual: The library is closed by calling mcrypt_module_close(), but you should not call that function if mcrypt_generic_end() is called before. and: int mcrypt_generic_end( MCRYPT td); This function terminates encryption specified by the encryption descriptor (td). Actually it clears all buffers, and closes all the modules used. Returns a negative value on error. This function is deprecated. Use mcrypt_generic_deinit() and mcrypt_module_close() instead. In earlier versions this was neccesairy, but now it can cause crashes. If I find some more time (hopefully this weekend), I'll dig in it. regards, Derick On Thu, 23 Aug 2001, Michael S. Fischer wrote: > Would anyone care to comment on this thread? Seems we've uncovered yet > another mcrypt-related bug in PHP 4.0.6. > > Thanks, > > --Michael > > -----Original Message----- > From: Dathan Pattishall > Sent: Thursday, August 23, 2001 10:44 AM > To: RO - Sever Filoti; Dathan Pattishall > Cc: Drew Folta; ACP-Split > Subject: RE: I think I found a mcrypt work around > > > Actually I should of went into more detail, about the work around. I did the > same thing but did not make the open call global. I committed the changes to > the splitdb gate, and have it working on realacp06 and realacp08. Take a > look at url_encode.inc now, and see if the seg fault is still troubling you. > > > Great digging, and thanks for the follow up! > > -- > D > > |~-----Original Message----- > |~From: Sever Filoti [mailto:sever@auctionwatch.ro] > |~Sent: Wednesday, August 22, 2001 11:42 PM > |~To: Dathan Pattishall > |~Cc: Drew Folta; ACP-Split > |~Subject: Re: I think I found a mcrypt work around > |~Importance: High > |~ > |~ > |~Actually I did this kind of digging myself some time ago, but it was > |~before ticket code push so I didn't get the time to publish > |~the results. > |~ > |~Anyway, only commenting mcrypt_generic_end did not do the > |~trick for me, > |~apache still segfaulted... strange. > |~Then I've put the initialization part at global level: > |~ > |~$__encode_td = mcrypt_module_open (MCRYPT_DES, "", > |~MCRYPT_MODE_ECB, ""); > |~ > |~$__encode_iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td), > |~MCRYPT_RAND); > |~ > |~and reused these variables in called function, as well as removing the > |~generic_end call. > |~ > |~Apache stopped segfaulting, and I even ran an ab (apache > |~benchmark) on a > |~shop page, thousands of iterations and no segfault :-), also no memory > |~leaks did occur during the benchmark. > |~ > |~As about the speed, Dathan is right: module_open/generic_end > |~translates > |~in having mcrypt library do dlopen (scan for libs...) on cipher > |~libraries, allocate buffers, then deallocate buffers and > |~unload (dlcose) > |~the modules; this would happen per obfuscated link so it's very > |~expensive. > |~ > |~I guess what happens is that after the two mcrypt modules (tripledes, > |~ecb) are loaded, another .so it's needed and hence loaded; but after > |~encryption ends and generic_end tries to unload explicitly > |~(dlclose) the > |~mcrypt module, dynamic loader whines "cannot close resident > |~module", and > |~probably next encryption step works with same module loaded but with > |~encryption buffers drained and this leads to signal 11. > |~ > |~Next 'mistery': apache stopped segfaulting but with the hacked code > |~tested with ab I could see in apache's error log messages like: > |~ > |~[Thu Aug 16 01:27:09 2001] [notice] child pid 729 exit signal Aborted > |~(6) > |~apache: dl-close.c:119: _dl_close: Assertion `new_opencount[0] == 0' > |~failed. > |~[Thu Aug 16 01:27:20 2001] [notice] child pid 724 exit signal Aborted > |~(6) > |~ > |~A failed assertion, probably related to shared libraries loading / > |~unloading as well. Fortunately, seems to happen only when an apache > |~process exists, thus has no user visible effects (response already > |~sent). > |~ > |~Dathan Pattishall wrote: > |~ > |~> Could be, I'll do a more in-depth analysis when I finish > |~the aw_setup > |~> script. But when these boxes have 2GB of memory and the apache is > |~> restarted every day, I don't see this as being much of an issue > |~> (short-term) > |~> > |~> -----Original Message----- > |~> From: Drew Folta > |~> Sent: Wednesday, August 22, 2001 3:46 PM > |~> To: Dathan Pattishall; ACP-Split > |~> Subject: RE: I think I found a mcrypt work around > |~> Importance: High > |~> > |~> OK, but are the apaches leaking memory (more than usual) > |~> ?Drew > |~> > |~> -----Original Message----- > |~> From: Dathan Pattishall > |~> Sent: Wednesday, August 22, 2001 3:27 PM > |~> To: ACP-Split > |~> Subject: I think I found a mcrypt work around > |~> > |~> After doing some debugging and looking at > |~> TripleDes, I ran across a resource re-allocate > |~> function for mcrypt, called mcrypt_generic_end . > |~> To me this sounds like some sort of destructor > |~> that is going out of bounds and attempts to modify > |~> memory that the resource does not own, i.e.. the > |~> cause of the seg-fault.So, I turned that option > |~> off, and just allow Zend / Apache control it's own > |~> resources, and low-en-behold the seg fault stops, > |~> page rendering is 3 times faster, and I'm much > |~> happier.if (PHP_VERSION > 3) { > |~> $td = mcrypt_module_open (MCRYPT_DES, "", > |~> MCRYPT_MODE_ECB, ""); > |~> $iv = mcrypt_create_iv > |~> (mcrypt_enc_get_iv_size ($td), MCRYPT_RAND); > |~> mcrypt_generic_init ($td, $__key, $iv); > |~> $query_string = mdecrypt_generic ($td, $s); > |~> //mcrypt_generic_end ($td); > |~> } else { > |~> $query_string = mcrypt_ecb(MCRYPT_TripleDES, > |~> $__key, $s, MCRYPT_DECRYPT); > |~> }I commented out mcrypt_generic_endwhich > |~> doesThis function terminates encryption specified > |~> by the encryption descriptor (td). Actually it > |~> clears all buffers, and closes all the modules > |~> used. Returns FALSE on error, or TRUE on success. > |~> > |~ > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > Derick Rethans --------------------------------------------------------------------- PHP: Scripting the Web - www.php.net - derick@php.net SRM: Site Resource Manager - www.vl-srm.net ---------------------------------------------------------------------