Would anyone care to comment on this thread?  Seems we've uncovered yet
another mcrypt-related bug in PHP 4.0.6.



-----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!


|~-----Original Message-----
|~From: Sever Filoti [mailto:[EMAIL PROTECTED]]
|~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, "", 
|~$__encode_iv = mcrypt_create_iv (mcrypt_enc_get_iv_size ($td),
|~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 
|~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
|~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
|~apache: dl-close.c:119: _dl_close: Assertion `new_opencount[0] == 0'
|~[Thu Aug 16 01:27:20 2001] [notice] child pid 724 exit signal Aborted
|~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
|~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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to