mcrypt issues

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. |~> |~