Skip Menu |

This queue is for tickets about the Crypt-SMIME CPAN distribution.

Report information
The Basics
Id: 133084
Status: resolved
Priority: 0/
Queue: Crypt-SMIME

People
Owner: Nobody in particular
Requestors: bsafford [...] proofpoint.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



CC: "tl [...] tripletail.jp" <tl [...] tripletail.jp>
Subject: NULL character support
Date: Thu, 30 Jul 2020 23:35:24 +0000
To: "bug-Crypt-SMIME [...] rt.cpan.org" <bug-Crypt-SMIME [...] rt.cpan.org>
From: Brian Safford <bsafford [...] proofpoint.com>
If any part of a message being encrypted or signed by Crypt::SMIME contains a NULL ( \x00 ) character, the incoming raw message bits will be truncated at the NULL character because: BIO_new_mem_buf(plaintext, -1); is used ( the -1 indicates it expects a NULL-terminated string ). I realize that NULL characters in email messages aren’t *supposed* to happen, but there is a lot of brokenness out there, and I don’t see any harm in repairing Crypt::SMIME to account for it. Regards, Brian Safford l Senior Developer Proofpoint, Inc. M: 248.662.5291 E: bsafford@proofpoint.com<mailto:bsafford@proofpoint.com>
CC: "tl [...] tripletail.jp" <tl [...] tripletail.jp>
Subject: [rt.cpan.org #133084] Re: NULL character support
Date: Fri, 31 Jul 2020 18:10:51 +0000
To: "bug-Crypt-SMIME [...] rt.cpan.org" <bug-Crypt-SMIME [...] rt.cpan.org>
From: Brian Safford <bsafford [...] proofpoint.com>
Here is the diff showing the changes I made to fix the encryption issue: <----------------------- snip -------------------> --- SMIME.xs.orig 2020-07-29 12:01:29.143519247 -0700 +++ SMIME.xs 2020-07-30 11:02:00.307061888 -0700 @@ -274,7 +274,7 @@ return result; } -static SV* _encrypt(Proofpoint_SMIME smime, char* plaintext) { +static SV* _encrypt(Proofpoint_SMIME smime, char* plaintext, unsigned int len) { BIO* inbuf; BIO* outbuf; CMS_ContentInfo* enc; @@ -283,7 +283,7 @@ BUF_MEM* bufmem; SV* result; - inbuf = BIO_new_mem_buf(plaintext, -1); + inbuf = BIO_new_mem_buf(plaintext, len); if (inbuf == NULL) { return NULL; } @@ -651,7 +651,13 @@ RETVAL SV* -_encrypt(Proofpoint_SMIME smime, char* plaintext) +_encrypt(Proofpoint_SMIME smime, plaintext) + PREINIT: + STRLEN len; + + INPUT: + char * plaintext = (char *)SvPV(ST(1), len); + CODE: /* public key required, error if not set */ if (smime->pubkeys_stack == NULL) { @@ -663,7 +669,7 @@ smime->cipher = EVP_des_ede3_cbc(); } - RETVAL = _encrypt(smime, plaintext); + RETVAL = _encrypt(smime, plaintext, len); if (RETVAL == NULL) { OPENSSL_CROAK("Proofpoint::SMIME#encrypt: failed to encrypt the message"); } <----------------------- snip -------------------> Brian Safford l Senior Developer Proofpoint, Inc. M: 248.662.5291 E: bsafford@proofpoint.com<mailto:bsafford@proofpoint.com> From: Brian Safford <bsafford@proofpoint.com> Date: Thursday, July 30, 2020 at 7:35 PM To: "bug-Crypt-SMIME@rt.cpan.org" <bug-Crypt-SMIME@rt.cpan.org> Cc: "tl@tripletail.jp" <tl@tripletail.jp> Subject: NULL character support If any part of a message being encrypted or signed by Crypt::SMIME contains a NULL ( \x00 ) character, the incoming raw message bits will be truncated at the NULL character because: BIO_new_mem_buf(plaintext, -1); is used ( the -1 indicates it expects a NULL-terminated string ). I realize that NULL characters in email messages aren’t *supposed* to happen, but there is a lot of brokenness out there, and I don’t see any harm in repairing Crypt::SMIME to account for it. Regards, Brian Safford l Senior Developer Proofpoint, Inc. M: 248.662.5291 E: bsafford@proofpoint.com<mailto:bsafford@proofpoint.com>
Thank you for your patch. I have applied it with some modifications and released 0.26.