Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libtomcrypt: fix vulnerability in der_decode_utf8_string CVE-2019-17362 #319

Closed
wants to merge 1 commit into from

Conversation

ynezz
Copy link
Contributor

@ynezz ynezz commented Aug 21, 2024

[ cherry pick of upstream commit 64d1153e5a515740ab56f39c46baf4cf6991a9d3 ]

The der_decode_utf8_string function (in der_decode_utf8_string.c) does not properly detect certain invalid UTF-8 sequences. This allows context-dependent attackers to cause a denial of service (out-of-bounds read and crash) or read information from other memory locations via carefully crafted DER-encoded data.

To exploit this vulnerability an attacker must be able to provide crafted DER-encoded data to LibTomCrypt (e.g. by importing a X509 certificate). Information disclosure is made possible by a 2-steps attack where the imported data is later somehow re-encoded and sent to the attacker (e.g. import and then export X509 certificate).

Fixes: CVE-2019-17362
References: libtom/libtomcrypt#507

[ cherry pick of upstream commit 64d1153e5a515740ab56f39c46baf4cf6991a9d3 ]

The der_decode_utf8_string function (in der_decode_utf8_string.c) does
not properly detect certain invalid UTF-8 sequences.  This allows
context-dependent attackers to cause a denial of service (out-of-bounds
read and crash) or read information from other memory locations via
carefully crafted DER-encoded data.

To exploit this vulnerability an attacker must be able to provide
crafted DER-encoded data to LibTomCrypt (e.g. by importing a X509
certificate).  Information disclosure is made possible by a 2-steps
attack where the imported data is later somehow re-encoded and sent to
the attacker (e.g. import and then export X509 certificate).

Fixes: CVE-2019-17362
References: libtom/libtomcrypt#507
Signed-off-by: werew <werew@ret2libc.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz> [backport]
ynezz added a commit to ynezz/openwrt that referenced this pull request Aug 22, 2024
…E-2019-17362

[ cherry pick of upstream commit 64d1153e5a515740ab56f39c46baf4cf6991a9d3 ]

The der_decode_utf8_string function (in der_decode_utf8_string.c) does
not properly detect certain invalid UTF-8 sequences.  This allows
context-dependent attackers to cause a denial of service (out-of-bounds
read and crash) or read information from other memory locations via
carefully crafted DER-encoded data.

To exploit this vulnerability an attacker must be able to provide
crafted DER-encoded data to LibTomCrypt (e.g. by importing a X509
certificate).  Information disclosure is made possible by a 2-steps
attack where the imported data is later somehow re-encoded and sent to
the attacker (e.g. import and then export X509 certificate).

Fixes: CVE-2019-17362
References: libtom/libtomcrypt#507
Upstream-Status: Submitted [mkj/dropbear#319]
Signed-off-by: werew <werew@ret2libc.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
ynezz added a commit to ynezz/openwrt that referenced this pull request Aug 22, 2024
…E-2019-17362

[ cherry pick of upstream commit 64d1153e5a515740ab56f39c46baf4cf6991a9d3 ]

The der_decode_utf8_string function (in der_decode_utf8_string.c) does
not properly detect certain invalid UTF-8 sequences.  This allows
context-dependent attackers to cause a denial of service (out-of-bounds
read and crash) or read information from other memory locations via
carefully crafted DER-encoded data.

To exploit this vulnerability an attacker must be able to provide
crafted DER-encoded data to LibTomCrypt (e.g. by importing a X509
certificate).  Information disclosure is made possible by a 2-steps
attack where the imported data is later somehow re-encoded and sent to
the attacker (e.g. import and then export X509 certificate).

Fixes: CVE-2019-17362
References: libtom/libtomcrypt#507
Upstream-Status: Submitted [mkj/dropbear#319]
Signed-off-by: werew <werew@ret2libc.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
@mkj
Copy link
Owner

mkj commented Aug 23, 2024

Dropbear isn't using LTC's DER functions (can confirm by putting #error nope in der_decode_utf8_string). I don't mind cherry picking this in, but I don't think the extra patch on top will be much help if people are trying to determine whether Dropbear is affected by the CVE. Thoughts?

@ynezz
Copy link
Contributor Author

ynezz commented Aug 23, 2024

tl;dr I would patch it (I proposed patching it in OpenWrt)

Dropbear isn't using LTC's DER functions (can confirm by putting #error nope in der_decode_utf8_string)

Indeed, that was my impression as well while quickly grepping through the source code.

I don't think the extra patch on top will be much help if people are trying to determine whether Dropbear is affected by the CVE.

Well I've noticed this in some downstream fix and simply checked state of this codebase and looked up CVE-2019-17362 in issues/pull requests, but couldn't find anything, thus I've created this pull request. I can imagine, that most of the folks consider this a CVE security theater, but IMO better safe, than sorry.

There are more aspects to consider, like transitive risks in downstream projects, future code changes, security scanners and compliance, project reputation and trust to name a few.

Anyways, I'll leave the decision up to you, good luck! :)

@Neustradamus
Copy link

@mkj: Any progess on it?

@mkj
Copy link
Owner

mkj commented Aug 27, 2024

I don't think merging the unused patch has much benefit in practice, I'll close this. @ynezz thanks for reporting it though, at least now there's a github issue for people to refer to.

Once there's a new upstream release I'll merge that into Dropbear. There won't be a separate Dropbear release for that purpose though.

@mkj mkj closed this Aug 27, 2024
ynezz added a commit to ynezz/openwrt that referenced this pull request Aug 27, 2024
…E-2019-17362

[ cherry pick of upstream commit 64d1153e5a515740ab56f39c46baf4cf6991a9d3 ]

The der_decode_utf8_string function (in der_decode_utf8_string.c) does
not properly detect certain invalid UTF-8 sequences.  This allows
context-dependent attackers to cause a denial of service (out-of-bounds
read and crash) or read information from other memory locations via
carefully crafted DER-encoded data.

To exploit this vulnerability an attacker must be able to provide
crafted DER-encoded data to LibTomCrypt (e.g. by importing a X509
certificate).  Information disclosure is made possible by a 2-steps
attack where the imported data is later somehow re-encoded and sent to
the attacker (e.g. import and then export X509 certificate).

Fixes: CVE-2019-17362
References: libtom/libtomcrypt#507
Upstream-Status: Denied [mkj/dropbear#319]
Signed-off-by: werew <werew@ret2libc.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
@Neustradamus
Copy link

@mkj: I do not understand why it is not possible to currently fix the CVE-2019-17362 and to close all which are refered to.
It is normal to keep a CVE in the current code?

@mkj
Copy link
Owner

mkj commented Aug 28, 2024

CVE-2019-17362 is a vulnerability in libtomcrypt but not in Dropbear (or in Dropbear's use of libtomcrypt - the der routines are not used). Changing the unused code in Dropbear's copy of libtomcrypt doesn't change anything functional.

@Neustradamus
Copy link

@mkj, @ynezz: I have informed the @libtom team about the libtomcrypt CVE-2019-17362 which is not fixed:

Hope a new libtomcrypt release build after the current latest release build 1.18.2 (2018-07-02) - 6 years, 2 moths soon.

cc: @kloczek.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants