CMS_final: do not ignore CMS_dataFinal result

"git tag --contains 67c0460b89cc1b0644a1a59af78284dfd8d720af" shows that no release contains the upstream commit yet.

3.0.6 include this fix.

This should be fixed in lunar by merging openssl from Debian

Hi Gil,

Can you explain a bit the actual impact of this bug and/or a scenario to reproduce. The commit doesn't give us a lot of details and the issue appears to be possibly quite serious but without diving deep into the code and possibly writing a reproducer from scratch ourselves, it is hard to be sure we properly understand it.

Thanks.

Hi,
This is a serious bug.
CMS_final() finalises the structure cms. Its purpose is to perform any
operations necessary on cms.
CMS_final() call to SMIME_crlf_copy() and not checking the return value
from SMIME_crlf_copy() so even SMIME_crlf_copy() fail, CMS_final() will
return ok but with wrong CMS data.
SMIME_crlf_copy() copies data from in_bio to out_bio and it's used at the
final op on cms structure (for example before writing or sending cms object)
SMIME_crlf_copy will fail if some data in cms is missing or wrong.

Scenario to reproduce:
Create cms signature structure without the signature value and send it to
CMS_final(). CMS_final() will return ok even if the CMS_final() fails.
This causes the software to continue with incorrect information and pass it
on even though it is incorrect.

On Mon, Nov 14, 2022 at 5:40 PM Adrien Nader <email address hidden>
wrote:

> Hi Gil,
>
> Can you explain a bit the actual impact of this bug and/or a scenario to
> reproduce. The commit doesn't give us a lot of details and the issue
> appears to be possibly quite serious but without diving deep into the
> code and possibly writing a reproducer from scratch ourselves, it is
> hard to be sure we properly understand it.
>
> Thanks.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1994165
>
> Title:
> CMS_final: do not ignore CMS_dataFinal result
>
> Status in openssl package in Ubuntu:
> Triaged
> Status in openssl source package in Jammy:
> Triaged
> Status in openssl source package in Kinetic:
> Triaged
>
> Bug description:
> https://github.com/openssl/openssl/pull/18876
>
> The CMS_dataFinal result is important as signature may fail, however, it
> is ignored while returning success from CMS_final.
>
> Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"
>
> Thanks
>
> Upstream commit:
>
> ```
> commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
> Author: Alon Bar-Lev <email address hidden>
> Date: Tue Jul 26 15:17:06 2022 +0300
>
> Handle SMIME_crlf_copy return code
>
> Currently the SMIME_crlf_copy result is ignored in all usages. It
> does
> return failure when memory allocation fails.
>
> This patch handles the SMIME_crlf_copy return code in all
> occurrences.
>
> Signed-off-by: Alon Bar-Lev <email address hidden>
>
> Reviewed-by: Tomas Mraz <email address hidden>
> Reviewed-by: Paul Dale <email address hidden>
> Reviewed-by: Hugo Landau <email address hidden>
> (Merged from https://github.com/openssl/openssl/pull/18876)
> ```
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+subscriptions
>
>

Hi,
This is a serious bug.
CMS_final() finalises the structure cms. Its purpose is to perform any operations necessary on cms.
CMS_final() call to SMIME_crlf_copy() and not checking the return value from SMIME_crlf_copy() so even SMIME_crlf_copy() fail, CMS_final() will return ok but with wrong CMS data.
SMIME_crlf_copy() copies data from in_bio to out_bio and it's used at the final op on cms structure (for example before writing or sending cms object)
SMIME_crlf_copy will fail if some data in cms is missing or wrong.

Scenario to reproduce:
Create cms signature structure without the signature value and send it to CMS_final(). CMS_final() will return ok even if the CMS_final() fails.
This causes the software to continue with incorrect information and pass it on even though it is incorrect.

We'd need more details about the issue and its actual impact for you since upstream doesn't consider this a security issue since it only happens when signing, not when checking signatures (which makes sense). Without this there is no process for pushing an update to a released version.

Thanks.

I was closing this for the reasons I outlined above. However, since then, I've decided to try to do an SRU of openssl for Jammy and I can try to integrate these changes.

I've created a PPA for Jammy that incorporates the fix mentionned. The details are available at https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru . Could you test it and confirm your issue is solved?

Hi
It seems that the issue is solved.
Thanks

On Tue, Sep 12, 2023 at 12:16 PM Adrien Nader <email address hidden>
wrote:

> I've created a PPA for Jammy that incorporates the fix mentionned. The
> details are available at
> https://launchpad.net/~adrien-n/+archive/ubuntu/openssl-jammy-sru .
> Could you test it and confirm your issue is solved?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1994165
>
> Title:
> CMS_final: do not ignore CMS_dataFinal result
>
> Status in openssl package in Ubuntu:
> Fix Released
> Status in openssl source package in Jammy:
> In Progress
> Status in openssl source package in Kinetic:
> Won't Fix
> Status in openssl source package in Lunar:
> Fix Released
>
> Bug description:
> https://github.com/openssl/openssl/pull/18876
>
> The CMS_dataFinal result is important as signature may fail, however, it
> is ignored while returning success from CMS_final.
>
> Please add this fix to The openssl 3.0.2 "Jammy Jellyfish (supported)"
>
> Thanks
>
> Upstream commit:
>
> ```
> commit 67c0460b89cc1b0644a1a59af78284dfd8d720af
> Author: Alon Bar-Lev <email address hidden>
> Date: Tue Jul 26 15:17:06 2022 +0300
>
> Handle SMIME_crlf_copy return code
>
> Currently the SMIME_crlf_copy result is ignored in all usages. It
> does
> return failure when memory allocation fails.
>
> This patch handles the SMIME_crlf_copy return code in all
> occurrences.
>
> Signed-off-by: Alon Bar-Lev <email address hidden>
>
> Reviewed-by: Tomas Mraz <email address hidden>
> Reviewed-by: Paul Dale <email address hidden>
> Reviewed-by: Hugo Landau <email address hidden>
> (Merged from https://github.com/openssl/openssl/pull/18876)
> ```
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1994165/+subscriptions
>
>

Thanks a lot for taking the time to test and provide feedback.

Hello,

ubuntu-sponsors is subscribed to this bug but I couldn't find anything actionable. I'm unsubscribing ubuntu-sponsors; feel free to subscribe it again if there's anything that needs sponsoring. Thanks.

Ah, I noticed that this is part of a big SRU that's being completed on bug #2033422. Just leaving a comment here for the record.

A version containing a fix for this has been uploaded to the Jammy queue to be processed by the SRU team. Thanks, Adrien :)

There are two changes here:

a) The original bug: CMS_final() was not taking into account the result of CMS_dataFinal() when returning its return code. It might be that CMS_dataFinal() failed, in which case an error would even be raised, but the return code of CMS_final() would be that of SMIME_crlf_copy().

b) While fixing (a), it was noticed that tons of other places in the code were not checking the result code of SMIME_crlf_copy(). It looks like this function returns a failure (0) when BIO_new() fails, so, a memory allocation.

I checked an openssl build log[1], and there are tests for CMS, and none of them failed.

The failure case is explained in [2]:
"""
It means some broken message that will later fail parsing/decryption/signature verification can be produced.
"""

So, my ponderings:
- for (a), was there perhaps a test case added to the openssl case to cover for that mistake? If not, could we come up with one in the test suite?

- the fix for (b) was a drive-by fix, and seems correct, but it is touching more code. What do you think about isolating the fix in this SRU to just the CMS_final() function? Pros and cons? So we fix the CMS_final() function, in the sense that we will keep checking both the return code of SMIME_crlf_copy() and CMS_dataFinal().

1. https://launchpadlibrarian.net/692262295/buildlog_ubuntu-jammy-amd64.openssl_3.0.2-0ubuntu1.12_BUILDING.txt.gz
2. https://github.com/openssl/openssl/pull/18876#issuecomment-1323830916

Indeed, there is an "extra" change which I saw fit to include after reviewing the change with care.

Replicating the issue directly involves using the openssl C APIs because higher-level interfaces like the command-line ones prevent calling the affected code in a way that will trigger the issue. This significantly increases the effort required to write the testcase. I don't think upstream wrote one either although that is their habit nowadays but it's been some time and I will have to look at it again.

Removing (b) wouldn't cause a security issue and it seems (a) is enough to fix the functional issue that has been reported. On the other hand this is a diff from current upstream versions, it will require new tests and the (a+b) changes have seen a lot of use worlwide by now. When including (b), I knew that it was probably not strictly required and I'm fine with removing it even though I would prefer to keep it for the above reasons.

I think the concerns Andreas raises regarding debian/patches/lp1994165/0002-Handle-SMIME_crlf_copy-return-code.patch are valid. Yes, there are cases where the return value of SMIME_crlf_copy() is currently ignored and this results in other API calls returning success when they should not.

However, it appears no one is reporting bugs about this behavior. This means either the code is never called in a way that triggers this wrong behavior; or, it is called, hits the wrong behavior, and the current wrong behavior is being handled up the stack[1]. From an SRU perspective, if no one is reporting bugs about the current behavior, it is better to leave it alone - I would not expect a change in *how* the failure of SMIME_crlf_copy() is handled to result in "good" behavior by the caller - the function still failed and isn't supposed to - so there's basically no upside here within the SRU guidelines, only possible downside.

I'm therefore rejecting this upload; please reupload without debian/patches/lp1994165/0002-Handle-SMIME_crlf_copy-return-code.patch.

[1] Note that "handled up the stack" could mean "user knows that the behavior is broken in this way and just copes with it rather than filing a bug report in Ubuntu"; or "user encounters this error, is puzzled by it, but doesn't file a bug (maybe they don't know how)". I am not asserting that the current error handling is *good*; only that it is *stable*, and therefore if no one is reporting a bug, it's best not to change the current behavior.

An upload of openssl to jammy-proposed has been rejected from the upload queue for the following reason: "Please reupload without debian/patches/lp1994165/0002-Handle-SMIME_crlf_copy-return-code.patch".

Hello Gil, or anyone else affected,

Accepted openssl into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/openssl/3.0.2-0ubuntu1.13 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

All autopkgtests for the newly accepted openssl (3.0.2-0ubuntu1.13) for jammy have finished running.
The following regressions have been reported in tests triggered by the package:

diffoscope/205 (armhf)
dotnet6/6.0.126-0ubuntu1~22.04.1 (amd64, arm64)
ganeti/3.0.2-1ubuntu1 (armhf)
linux-aws-5.19/5.19.0-1029.30~22.04.1 (arm64)
linux-aws-6.5/6.5.0-1011.11~22.04.1 (arm64)
linux-azure-6.2/6.2.0-1018.18~22.04.1 (arm64)
linux-gcp-6.2/6.2.0-1019.21~22.04.1 (arm64)
linux-gke/5.15.0-1048.53 (arm64)
linux-lowlatency-hwe-6.2/6.2.0-1018.18~22.04.1 (arm64)
linux-lowlatency-hwe-6.5/6.5.0-14.14.1~22.04.1 (arm64)
linux-mtk/5.15.0-1029.33 (arm64)
linux-nvidia-6.5/6.5.0-1010.10 (arm64)
linux-oracle-6.2/6.2.0-1017.18~22.04.1 (arm64)
puma/5.5.2-2ubuntu2 (arm64)
python-bonsai/1.3.0+ds-3build1 (armhf)
ruby3.0/3.0.2-7ubuntu2.4 (amd64, arm64, i386)
seqkit/2.1.0+ds-1 (s390x)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/jammy/update_excuses.html#openssl

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Gil, can you do the verification? Thanks.

As expected, it wasn't very easy to create a reproducer since the openssl tool couldn't be used and it required introducing errors in lower layers. Moreover the CMS_dataFinal symbol cannot be overriden in a meaningful way, probably either due to LTO or symbol visibility. Fortunately it was still possible to do it through GDB even though it couldn't locate the symbol at first (hence the message "Function "CMS_dataFinal" not defined.")

# apt-get install -y gdb

# cat > gdb_commands << EOF
> set breakpoint pending on
break CMS_dataFinal
r
return (int) 0
c
q
EOF

# echo foo > mail.txt

# openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -sha256 -days 30
# echo use "1234" as password and press enter for each subsequent question

# gdb --return-child-result --batch-silent --command=gdb_commands --args openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem -noindef -nodetach -passin pass:1234; echo $?
Function "CMS_dataFinal" not defined.
0

# echo edit sources.list and apt install -t jammy-proposed libssl3

# # gdb --return-child-result --batch-silent --command=gdb_commands --args openssl cms -sign -in mail.txt -out mail.msg -signer cert.pem -inkey key.pem -noindef -nodetach -passin pass:1234; echo $?
Function "CMS_dataFinal" not defined.
80FBF0F7FF7F0000:error:17000067:CMS routines:CMS_final:cms datafinal error:../crypto/cms/cms_smime.c:890:
3

As can be seen, after the update, the return code is non-0, indicating the error was properly bubbled up.

This bug was fixed in the package openssl - 3.0.2-0ubuntu1.13

---------------
openssl (3.0.2-0ubuntu1.13) jammy; urgency=medium

  * Fix (upstream): crash when using an engine for ciphers used by DRBG
    (LP: #2023545)
    - lp2023545/0001-Release-the-drbg-in-the-global-default-context-befor.patch
  * Fix (upstream): do not ignore return values for S/MIME signature
    (LP: #1994165)
    - lp1994165/0001-REGRESSION-CMS_final-do-not-ignore-CMS_dataFinal-res.patch
  * Perf (upstream): don't empty method stores and provider synchronization
    records when flushing the query cache (LP: #2033422)
    - lp2033422/0001-Drop-ossl_provider_clear_all_operation_bits-and-all-.patch
    - lp2033422/0002-Refactor-method-construction-pre-and-post-condition.patch
    - lp2033422/0003-Don-t-empty-the-method-store-when-flushing-the-query.patch
    - lp2033422/0004-Make-it-possible-to-remove-methods-by-the-provider-t.patch
    - lp2033422/0005-Complete-the-cleanup-of-an-algorithm-in-OSSL_METHOD_.patch
    - lp2033422/0006-For-child-libctx-provider-don-t-count-self-reference.patch
    - lp2033422/0007-Add-method-store-cache-flush-and-method-removal-to-n.patch

 -- Adrien Nader <email address hidden> Tue, 09 Jan 2024 11:42:50 +0100

The verification of the Stable Release Update for openssl has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.