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
CVE-2019-17362 - vulnerability in der_decode_utf8_string #507
Comments
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 [joakim bech: Extended commmit message] Acked-by: Joakim Bech <joakim.bech@linaro.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 [Joakim Bech: Extended commmit message] Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7)
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 [Joakim Bech: Extended commmit message] Signed-off-by: Luigi Coniglio <werew@ret2libc.com> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7)
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 [Joakim Bech: Extended commmit message] Signed-off-by: Luigi Coniglio <werew@ret2libc.com> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jens Wiklander <jens.wiklander@linaro.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
|
This vulnerability has now been attributed CVE ID: CVE-2019-17362 |
CVE-2019-17362: "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." Details: libtom/libtomcrypt#507 https://nvd.nist.gov/vuln/detail/CVE-2019-17362 Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
CVE-2019-17362: "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." Details: libtom/libtomcrypt#507 https://nvd.nist.gov/vuln/detail/CVE-2019-17362 Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> (cherry picked from commit 62b34ed) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
CVE-2019-17362: "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." Details: libtom/libtomcrypt#507 https://nvd.nist.gov/vuln/detail/CVE-2019-17362 Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> (cherry picked from commit 62b34ed) Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix a vulnerability in der_decode_utf8_string as specified here: libtom/libtomcrypt#507 Patch manually picked from: libtom/libtomcrypt@25c26a3 Signed-off-by: Luigi Coniglio <werew@ret2libc.com> [Joakim Bech: Extended commit message] Signed-off-by: Joakim Bech <joakim.bech@linaro.org> Acked-by: Joakim Bech <joakim.bech@linaro.org> Tested-by: Joakim Bech <joakim.bech@linaro.org> (QEMU v7) Acked-by: Jerome Forissier <jerome@forissier.org>
|
@werew : your write-up on this issue is really good. Thanks! One thing that seems unusual about the test vectors you provide (poc1, poc2) is that they begin with "\x30\x04..." but they are followed by more than four bytes. However, it doesn't seem like the der sequence length matters in this exploit. What is important is the value of "inlen", which is the input length that is passed in to |
Description: Minor changes to help test and clarify the way utf8 strings are decoded. This originated from my misunderstanding of the fix for issue libtom#507. Testing: $ make clean $ make CFLAGS="-DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS="../libtommath/libtommath.a" test $ ./test You can confirm that the new utf8 test data is correct using python: >>> s="\xD7\xA9\xD7\x9C\xD7\x95\xD7\x9D" >>> s.decode("utf-8") u'\u05e9\u05dc\u05d5\u05dd'
Description: Minor changes to help test and clarify the way utf8 strings are decoded. This originated from my misunderstanding of the fix for issue libtom#507. The new test-vector uses two bytes to encode each wide-char. Testing: $ make clean $ make CFLAGS="-DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS="../libtommath/libtommath.a" test $ ./test You can confirm that the new utf8 test data is correct using python: >>> s="\xD7\xA9\xD7\x9C\xD7\x95\xD7\x9D" >>> s.decode("utf-8") u'\u05e9\u05dc\u05d5\u05dd'
Description: Minor changes to help test and clarify the way utf8 strings are decoded. This originated from my misunderstanding of the fix for issue libtom#507. The new test-vector uses two bytes to encode each wide-char. Testing: $ make clean $ make CFLAGS="-DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS="../libtommath/libtommath.a" test $ ./test You can confirm that the new utf8 test data is correct using python: >>> s="\xD7\xA9\xD7\x9C\xD7\x95\xD7\x9D" >>> s.decode("utf-8") u'\u05e9\u05dc\u05d5\u05dd'
Description: Minor changes to help test and clarify the way utf8 strings are decoded. This originated from my misunderstanding of the fix for issue libtom#507. The new test-vector uses two bytes to encode each wide-char. The utf8 format is described here: https://tools.ietf.org/html/rfc3629#section-3 Testing: $ make clean $ make CFLAGS="-DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS="../libtommath/libtommath.a" test $ ./test You can confirm that the new utf8 test data is correct using python: >>> s="\xD7\xA9\xD7\x9C\xD7\x95\xD7\x9D" >>> s.decode("utf-8") u'\u05e9\u05dc\u05d5\u05dd'
Description: Minor changes to help test and clarify the way utf8 strings are decoded. This originated from my misunderstanding of the fix for issue libtom#507. The new test-vector uses two bytes to encode each wide-char. The utf8 format is described here: https://tools.ietf.org/html/rfc3629#section-3 Testing: $ make clean $ make CFLAGS="-DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS="../libtommath/libtommath.a" test $ ./test You can confirm that the new utf8 test data is correct using python: >>> s="\xD7\xA9\xD7\x9C\xD7\x95\xD7\x9D" >>> s.decode("utf-8") u'\u05e9\u05dc\u05d5\u05dd'
Description
The
der_decode_utf8_stringfunction (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.
Attack vectors
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).
Details
This vulnerability affects LibTomCrypt 1.18.2 and earlier versions.
For the remainder of this issue I will be referring to the code of LibTomCrypt last released version (i.e. version 1.18.2, https://www.libtom.net/news/LTC_1.18.2/).
The cause of the problem lies in the decoding-loop at line 71 of der_decode_utf8_string.c:
Here the variable
tmpcontains the value of the first byte of the utf-8 encoded character.In accordance to utf-8 encoding rules the number of most significant bits of
tmpset at 1 (from left to right) prior to a 0, indicates the number of bytes used to encode the utf-8 character (i.e. a sequence starting by 110xxxxx indicates a size of 2 bytes) .However notice that 10xxxxxx is not a valid 1st byte.
The loop in question fails to detect this case and process a sequence starting with 10xxxxxx as if it was a sequence of two bytes.
A valid utf-8 sequence of two bytes is of the form: 110xxxxx 10xxxxxx and can encode values up to 0x7FF. Yet
der_decode_utf8_stringaccepts sequences of two bytes of the form: 10xxxxxx 10xxxxxx.This invalid form offers an additional free bit and can therefore encode values up to 0xFFF, hence including a range of values that would normally be encodable only using a sequence of at least 3 bytes.
This behavior can be used to trick
der_length_utf8_stringinto reporting a length bigger than the actual size of the encoded string.This works because the function
der_utf8_charsizereturns a number of bytes based on the size of the decoded value.To see an example of how this can be exploited to crash the program or read data after the DER-buffer, let us consider the function
der_decode_sequence_flexi(used to decode X509 certificates).When an utf-8 entry is encountered this function will first decode it in an array pointed by
l->dataand then compute the length usingder_length_utf8_stringon the decoded data:The computed
lenis later used to move forward some pointers:/* advance pointers */ totlen += len; in += len; *inlen -= len;The variable
inlenpoints to the size of the remaining number of bytes to decode.Using the aforementioned bug it is possible to craft an input such that
len > *inlen.In this case
*inlenwill underflow resulting in a much bigger value than the actual size of user's input.Finally, this can be used to crash the program (e.g. by reading invalid memory location) or to trick the DER-decoder into including adjacent data into the decoded sequence.
PoC
Following I include two profs of concept.
poc1 will likely cause a program to crash by triggering a read of 0xffffffff additional bytes (thus probably ending up in an invalid memory page).
poc2 will add 0xffff bytes of adjacent memory to the decoded sequence. This data can then be accessed, in a 2-steps attack scenario, by exporting the certificate.
Notice that poc2 will very likely NOT cause the program to crash since any invalid DER-type encountered after the leaked data will just cause the decoding to stop gracefully without causing any further error (line 436 of der_decode_sequence_flexi.c).
The text was updated successfully, but these errors were encountered: