[xmlsec] xmlSecDSigCtxVerify fails
Aleksey Sanin
aleksey at aleksey.com
Wed Feb 10 21:25:57 PST 2010
Thanks! Great to know!
Aleksey
On 2/10/2010 9:25 PM, mahendra N wrote:
> Hi Aleksey,
> We were able to sort out the problem. We had to compile
> our program with
> XMLSEC_NO_SIZE_T flag before porting it to MIPS 64 bit system. Thanks
> for all your time Aleksey.
> Thanks and Regards,
> Mahendra Naik
>
> 2010/2/4 mahendra N <mahendra0203 at gmail.com <mailto:mahendra0203 at gmail.com>>
>
> Hi,
> What should the function return. 0 or -1? Is the code piece
> right..?..
> Thanks an Regards,
> Mahendra Naik
>
>
> 2010/2/4 Aleksey Sanin <aleksey at aleksey.com
> <mailto:aleksey at aleksey.com>>
>
> Ah, OK. I was looking at the other place.
>
> Aleksey
>
>
> On 2/3/2010 11:03 PM, mahendra N wrote:
>
> Hi,
>
> I have attached some comments inline
>
> Thanks and Regards,
> Mahendra Naik
>
> 2010/2/4 Aleksey Sanin <aleksey at aleksey.com
> <mailto:aleksey at aleksey.com> <mailto:aleksey at aleksey.com
> <mailto:aleksey at aleksey.com>>>
>
>
> See my answers inline.
>
> Aleksey
>
>
>
> On 2/3/2010 10:15 PM, mahendra N wrote:
>
> Hi Aleksey,
>
> In /xmlSecDSigCtxVerify/ there are
> calls to two
> functions
> /xmlSecDSigCtxProcessSignatureNode/ and
> /xmlSecTransformVerifyNodeContent/
> / After the call to
> x/mlSecDSigCtxProcessSignatureNode /there is
> a check
>
> placed for /
> / dSigCtx->status!=xmlSecDSigStatusUnknown .If
> there is a
> success
> then the function returns 0. Is this check
> absolutely necessary
> at that
> point in the code?. Because when we comment the
> check and proceed
> further, then /xmlSecTransformVerifyNodeContent
> /returns -1 for
> any XML
> file that is tampered./
>
>
> [Aleksey] The check there returns -1 if the status is
> NOT equal to
> xmlSecDSigStatusUnknown. This is a check to make sure
> that we don't
> have unexpected state in the signature. One of the
> possible cases where
> it might happen is if you are re-using the *same*
> xmlDsigCtx for
> multiple signatures w/o calling xmlSecDSigCtxFinalize().
>
> The check returns 0 not -1.
> I am attaching the code piece here.I've marked the
> concerned part in
> bold.
> int xmlSecDSigCtxVerify(xmlSecDSigCtxPtr dsigCtx,
> xmlNodePtr node) {
> int ret;
>
> xmlSecAssert2(dsigCtx != NULL, -1);
> xmlSecAssert2(node != NULL, -1);
> xmlSecAssert2(node->doc != NULL, -1);
>
> /* add ids for Signature nodes */
> dsigCtx->operation = xmlSecTransformOperationVerify;
> dsigCtx->status = xmlSecDSigStatusUnknown;
> xmlSecAddIDs(node->doc, node, xmlSecDSigIds);
>
> /* read siganture info */
> ret = xmlSecDSigCtxProcessSignatureNode(dsigCtx, node);
> if(ret < 0) {
> xmlSecError(XMLSEC_ERRORS_HERE,
> NULL,
> "xmlSecDSigCtxSigantureProcessNode",
> XMLSEC_ERRORS_R_XMLSEC_FAILED,
> XMLSEC_ERRORS_NO_MESSAGE);
> return(-1);
> }
> xmlSecAssert2(dsigCtx->signMethod != NULL, -1);
> xmlSecAssert2(dsigCtx->signValueNode != NULL, -1);
>
> /* references processing might change the status */
> *if(dsigCtx->status != xmlSecDSigStatusUnknown) {*
> * return(0); *
> * }*
>
> /* verify SignatureValue node content */
> ret = xmlSecTransformVerifyNodeContent(dsigCtx->signMethod,
> dsigCtx->signValueNode,
> &(dsigCtx->transformCtx));
> if(ret < 0) {
> xmlSecError(XMLSEC_ERRORS_HERE,
> NULL,
> "xmlSecTransformVerifyNodeContent",
> XMLSEC_ERRORS_R_XMLSEC_FAILED,
> XMLSEC_ERRORS_NO_MESSAGE);
> return(-1);
> }
>
> /* set status and we are done */
> if(dsigCtx->signMethod->status ==
> xmlSecTransformStatusOk) {
> dsigCtx->status = xmlSecDSigStatusSucceeded;
> } else {
> dsigCtx->status = xmlSecDSigStatusInvalid;
> }
> return(0);
> }
>
>
>
> /
> /
> /
> /
> /And I tried with purify tool, there was no memory
> corruption
> reported/
>
> /./
> /Aleksey the system where this error is reproduced
> is a 64-bit, MIPS
> architecture ,Windriver linux/
> /
> /
> /.Are there any specific compiler flags to be set
> for the above
> mentioned configuration./
> /
>
> [Aleksey] No idea. Never used such a setup.
>
> /
> /
>
> /
> Some more investigation that was done:
> (i) The unpredictable behaviour is due to mismatch
> of memory
> location
> of status member of the structure struct xmlSecDSigCtx.
> (ii) I tried to get the adress of each of the member
> variable of
> structure xmlSecDSigCtx. Please find it below.
> Inside the ImplLibXml(our local file)
>
> dsigCtx Address ( 4832286288) + size (8)
> Address of userData(4832286288) + size(8)
> Address of flags(4832286296) + size(4)
> Address of flags2(4832286300) + size(4)
> Address of keyInfoReadCtx(4832286304) + size(368)
> Address of keyInfoWriteCtx(4832286672) + size(368)
> Address of transformCtx(4832287040) + size(136)
> Address of enabledReferenceUris(4832287176) + size(4)
> Address of enabledReferenceTransforms(4832287184) +
> size(8)
> Address of referencePreExecuteCallback(4832287192) +
> size(8)
> Address of defSignMethodId(4832287200) + size(8)
> Address of defC14NMethodId(4832287208) + size(8)
> Address of defDigestMethodId(4832287216) + size(8)
> Address of signKey(4832287224) + size(8)
> Address of operation(4832287232) + size(4)
> Address of result(4832287240) + size(8)
> Address of status(4832287248) + size(4)
> Address of signMethod(4832287256) + size(8)
> Address of preSignMemBufMethod(4832287272) + size(8)
> Address of signValueNode(4832287280) + size(8)
> Address of id(4832287288) + size(8)
> Address of signedInfoReferences(4832287296) + size(40)
> Address of manifestReferences(4832287336) + size(40)
> Address of reserved0(4832287376) + size(8)
> Address of reserved1(4832287384) + size(8)
>
> ImplLibXml **END**
>
> Inside xmlsec
>
> dsigCtx Address ( 4832286288) + size (8)
> Address of userData(4832286288) + size(8)
> Address of flags(4832286296) + size(4)
> Address of flags2(4832286300) + size(4)
> Address of keyInfoReadCtx(4832286304) + size(344)
> Address of keyInfoWriteCtx(4832286648) + size(344)
> Address of transformCtx(4832286992) + size(128)
> Address of enabledReferenceUris(4832287120) + size(4)
> Address of enabledReferenceTransforms(4832287128) +
> size(8)
> Address of referencePreExecuteCallback(4832287136) +
> size(8)
> Address of defSignMethodId(4832287144) + size(8)
> Address of defC14NMethodId(4832287152) + size(8)
> Address of defDigestMethodId(4832287160) + size(8)
> Address of signKey(4832287168) + size(8)
> Address of operation(4832287176) + size(4)
> Address of result(4832287184) + size(8)
> Address of status(4832287192) + size(4)
> Address of signMethod(4832287200) + size(8)
> Address of preSignMemBufMethod(4832287216) + size(8)
> Address of signValueNode(4832287224) + size(8)
> Address of id(4832287232) + size(8)
> Address of signedInfoReferences(4832287240) + size(32)
> Address of manifestReferences(4832287272) + size(32)
> Address of reserved0(4832287304) + size(8)
> Address of reserved1(4832287312) + size(8)
>
> xmlSecDSigCtxVerify****************END**********
>
> Please observe that the main culprit for mismatch of
> memory
> location are
> three user defined data members
> Address of keyInfoReadCtx(4832286304) + size(368) --
> more 24 bytes
> Address of keyInfoWriteCtx(4832286672) + size(368)
> -- more 24 bytes
> Address of transformCtx(4832287040) + size(136)
> -- more 8 bytes.
>
> But I find the consistency in case of status member
> is that the
> difference of location (i.e. between the status
> member in xmlsec
> and in
> ImplLibXml )is always 56 bytes as above the memory
> difference is
> also 56
> bytes.I feel issue on MIPS is somehow related to
> memory mapping
> issues.
>
>
> [Aleksey] Bingo! As I said, it feels like you have a problem
> with compiler flags. Check data alignment related flags
> for xmlsec
> compilation vs. your program compilation. This obviously
> explains
> why you can't reproduce this problem with xmlsec command
> line tool.
>
>
>
>
More information about the xmlsec
mailing list