-
Notifications
You must be signed in to change notification settings - Fork 405
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
Conversation
[ 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]
…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>
…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>
Dropbear isn't using LTC's DER functions (can confirm by putting |
tl;dr I would patch it (I proposed patching it in OpenWrt)
Indeed, that was my impression as well while quickly grepping through the source code.
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! :) |
@mkj: Any progess on it? |
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. |
…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>
@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. |
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. |
@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. |
[ 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