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:[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, "",
|~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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
