Since the conversation has come up, I'll post my leaking code again.
Here's just the function that crashes (only after many iterations) for
quick reference.
//**********************************************************************
*****
// FUNCTION: Validate_File_Signature
//
// DESCRIPTION:
// This function uses the supplied public key to validate the
signature
// on the specified file.
//
// PARAMETERS:
// Public_Key - Public_Key_Typ - Input by const reference
// The public key to validate the file signature with.
// File_Path - char* - Input by const pointer
// The pathname of the file to validate.
//
// FILES:
// File_Path - Input only
// The file signature is computed from the file contents.
//
// Signature_File_Path - Input only
// The signature file (File_Path + ".sig") is read and verified
// against the file contents.
//**********************************************************************
*****
bool Validate_File_Signature(const Public_Key_Typ& Public_Key,
const char* File_Path)
{
bool File_Valid = false;
char Signature_File_Path[500];
VerifierFilter* Verifier_Filter = NULL;
try
{
//
// Append ".sig" to the file path to create the signature name.
//
strcpy(Signature_File_Path, File_Path);
strcat(Signature_File_Path, ".sig");
//
// In order for the signature verifier to construct, it expects
the
// key to come from a 'Source'. Since our key is in string form,
// create the String variety of a Source and pass that into the
// verifier.
//
StringSource Public_String((char*) Public_Key, true, new
HexDecoder);
RSASSA_PKCS1v15_SHA_Verifier Verifier(Public_String);
//
// Load the signature file. If the signature length is correct,
// perform the file signature validation.
//
FileSource Signature_File(Signature_File_Path, true, new
HexDecoder);
if (Signature_File.MaxRetrievable() == Verifier.SignatureLength())
{
//
// Get the signature from the signature file.
//
SecByteBlock Signature(Verifier.SignatureLength());
Signature_File.Get(Signature, Signature.size());
//
// A verifier filter is used to validate the signature against
// the contents of the file.
//
Verifier_Filter = new VerifierFilter(Verifier);
if (Verifier_Filter != NULL)
{
Verifier_Filter->Put(Signature, Verifier.SignatureLength());
//
// Verifier_Filter memory is passed into the File_Source and
// we assume that it is released upon destruction
//
FileSource File_Source(File_Path,
true,
Verifier_Filter);
//
// Get the result of the signature verification.
//
File_Valid = Verifier_Filter->GetLastResult();
}
}
}
catch (CryptoPP::Exception)
{
//
// Catch all Crypto++ exceptions.
//
File_Valid = false;
};// End try
return(File_Valid);
}
A memory corruption is occurring during signature validation. In a
larger app, after running code identical to this, various crypto
functions start failing including key generation.
After a certain number of iterations (usually between 5 and 100), the
application crashes with a typical Windows error message "The
instruction at '0x77fcc024' referenced memory at '0x00000000'. The
memory could not be written". Something is obviously corrupting memory
so that it points to NULL. My current guess is that memory is being
corrupted inside the library code. If I'm wrong (and I hope I am),
please let me know where.
After much debugging, I'm fairly certain that the trouble is in the
FileSource creation / destruction. I can not tell if the VerifierFilter
is being destroyed properly, though running it through the debugger
seems to indicate that it is at least being mangled, if not properly
destroyed. If I catch all exceptions, the program does not crash, but
that is hardly a successful run.
When running a debug version of the executable, it runs fine, which
leads me to think that some memory is being tested for NULL without ever
being initialized. The debugger initializes all memory nicely, but a
running executable can not be assumed to do the same.
I must use a FIPS compliant library so if any of the fixes for this
require moving to a newer version of Crypto++, I'm in serious trouble.
Important details:
Windows 2000 (current updates)
Visual Studio 6.0 (service pack 5 + processor pack) FIPS complaint
Crypto++ headers and dll (5.0.4)
Thank you very much in advance for any possible help.
PS.
I assume that everyone knows by now that creating and destroying the
random number generator enough times will, by itself, cause a crash, but
it would have been nice to have that posted somewhere. The functions of
Crypto++ seem to work fine, but try to create and delete objects in a
loop and it's nothing but memory corrupting crashes.
-----Original Message-----
From: James Vanns [mailto:[EMAIL PROTECTED]
Sent: Monday, June 20, 2005 4:17 AM
To: [email protected]
Subject: RE: Memory Leak
This is quite alarming. Does anyone have any indication as to [exactly]
where the memory leak(s) is/are? I also have code (going live date
approaching) that uses Crypto++' RSASS implementation.
Jim
On Wed, 2005-06-15 at 08:53 +0800, ZENG Ke wrote:
> I have the same observation, cryptopp causes severe memory leak.
>
> > -----Original Message-----
> > From: Newman, Christofer [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, June 15, 2005 8:48 AM
> > To: [email protected]
> > Subject: RE: Memory Leak
> >
> > From what I've been able to tell, that's exactly where the memory
> > leak is. We've had to stop using cryptopp for signing and
> > verification. I've posted twice asking for help. I hope you have
> > beter luck. I'll be watching the board.
> >
> > -Chris
> >
> > -----Original Message-----
> > From: Seshu Madabushi [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, June 14, 2005 3:33 PM
> > To: [email protected]
> > Subject: Memory Leak
> >
> > All
> >
> > I am using cryptopp.dll (FIPS version) to do signing and
> > verification process. When debugging my application through Bounds
> > Checker I noticed that memory leaks. Below is the code snippet I am
> > using for signing. Can anyone please explain whether the leak is in
CryptoPP?
> >
> > StringSource privFile(prvkey1,len,true, NULL);
> > RSASSA_PKCS1v15_SHA_Signer priv(privFile);
> > priv.SignMessage(GlobalRNG(), (byte *) DigestValue, TotDigestLen ,
> > (byte *) signature);
> >
> > Thanks
> > Seshu
> >
>
>
>
--
James Vanns BSc (Hons) MCP
Linux Systems Administrator
Software Engineer (Linux / C & C++)
Canterbury Christ Church University College Public Key:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x24045370
