Re: pgp in Debian: obsolete?
On Thu, Aug 12, 2004 at 11:20:28PM +0200, Florian Weimer wrote: >> Quoting Florian Weimer ([EMAIL PROTECTED]): >> Just out of curiosity, are there now, or have there been in the >> past, any _other_ implementations of the OpenPGP spec, besides >> GnuPG? > GnuPG is not a complete implementation of OpenPGP, either. > Other partial implementations are contained in some PGP products, > some NAI products, CryptoEx by Glück & Kanja, and so on. There is HushMail, too. -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Need me,ds? 3r1r
cpgitturdmvnibljrofzqmzptxtbibhastysohipaarstbfwnbjnwaoycncohere Enjoy up to 85% off Buy ViaNDcoANDdin OaNDnliANDne Get VaNDiagANDra/CiaaNDlANDis Buy VANDalANDiuaNDm for CHaNDEAP Get XaANDnaaNDx onlANDine from our OANDnlaNDine phaANDrmANDacy. MANY OTHaNDERS ALSO AVAIaNDLABLE! NO PraNDesANDcriaNDption reqANDuired DiscaNDreet/FAST shaNDippaNDing. Plus *No ShaNDipANDping caNDharge* And always 10aND0% monaNDey back guaraaNDntee CliaNDck heANDre for more inaNDfo qblnfojfzsxsoinmtosffbiimdvyewiiwgioiwxoadoubkzxgvpreplaceableresourcefulnoxioussalamiedify
Re: apache / exe process taking 99 % cpu
Am Wednesday, 1. September 2004 14:24 schrieb Marcin Owsiany: > Check whether the index.php looks like something that was created by > the attacker, or it is just a legitimate but buggy script file. It is a normal index.php File from a legitimate user. It seems to be programmed poorly, because it doesn't check the contents of variable that's beeing passed as a parameter to the script itself. > > How can I genereally close this hole for now? I guess there is a > > setting in php.ini or so. I will take a look at it. > > Probably there is a setting for this very feature that facilitated > this exploitation (HTTP-enabled open() I guess). But there are two > problems with that: new security implications of certain PHP features > are discovered rather regularily, and many users depend on such > features. The russian website from which the link I have posted mentions a php.ini setting "allow_url_fopen". We did some testing and it worked to prevent the loading of external urls. But I am not sure if this setting can stop that hack from happening. We'll see. :) > Actually allowing not-very-experienced programmers to run arbitrary > code on your machine is the more general problem we are facing, for > which there is no easy solution. > > My current plan is to run PHP via suexec, so that I can easily find out > which user's website was cracked. Then I would shut down the particular > web page and tell the client to either fix it or say goodbye ]:-> > > Unfortunately I hear that there are some PHP features (something having > to do with authentication) which don't work when PHP is not run as an > Apache module, so I cannot migrate all users in a batch. Generally, PHP > is a little bit like a nightmare for me :-) This is so right. I will sooner or later also take some measures, gr-security and/or a chroot environment for apache. Thank to everyone who answered me. I will be prepared if it happens again and will try to record more info to provide it. Kind regards Timo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
