Re: [PATCH v2 00/14] vboot: Fix forged-configuration vulnerability
Hi, On Fri, 16 Oct 2020 at 01:40, guoyujie (C) wrote: > > Hi,I’m a developer using u-boot-2020.01,where can I get the patch fixing > CVE-2020-10648 for u-boot-2020.01? Upstream commit is 0e29648f8e7 and following Cover letter is here: https://lists.denx.de/pipermail/u-boot/2020-March/403409.html Patchwork here: http://patchwork.ozlabs.org/project/uboot/list/?series=165191=* Unfortunately only the cover letter mentions CVE-2020-10648 and that did not make it into the commits. Regards, Simon
[PATCH v2 00/14] vboot: Fix forged-configuration vulnerability
Hi,I'm a developer using u-boot-2020.01,where can I get the patch fixing CVE-2020-10648 for u-boot-2020.01?
Re: [PATCH v2 00/14] vboot: Fix forged-configuration vulnerability
On Mon, Mar 30, 2020 at 05:11:38PM -0600, Simon Glass wrote: > Hi, > > On Wed, 18 Mar 2020 at 11:44, Simon Glass wrote: > > > > When booting a FIT, if 'bootm' is used without a specified configuration, > > U-Boot will use the default one provided in the FIT. But it does not > > actually check that the signature is for that configuration. > > > > This means that it is possible to duplicate a configuration conf-1 to > > produce conf-2 (with all the signatures intact), set the default > > configuration to conf-2 and then boot the image. U-Boot will verify conf-2 > > (in fact since hashed-nodes specifies the conf-1 nodes it will effectively > > verify conf-1). Then it will happily boot conf-2 even though it might have > > a different kernel. > > > > This series corrects this problem and adds a test to verify it. It also > > updates fit_check_sign to allow the configuration to be specified. > > > > This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of > > F-Secure, who also wrote the vboot_forge script included here. > > > > This is CVE-2020-10648 > > > > Changes in v2: > > - Bring in new vboot_forge file from the authors > > > > Simon Glass (14): > > image: Correct comment for fit_conf_get_node() > > image: Be a little more verbose when checking signatures > > image: Return an error message from fit_config_verify_sig() > > test: vboot: Drop unnecessary parameter for fit_check_sign > > test: vboot: Add a test for a forged configuration > > test: vboot: Parameterise the test > > image: Check hash-nodes when checking configurations > > image: Load the correct configuration in fit_check_sign > > fit_check_sign: Allow selecting the configuration to verify > > test: vboot: Tidy up the code a little > > test: vboot: Fix pylint errors > > image: Use constants for 'required' and 'key-name-hint' > > test: vboot: Move key creation into a function > > test: vboot: Reduce fake kernel size to 500 bytes > > > > common/bootm.c | 6 +- > > common/image-cipher.c| 2 +- > > common/image-fit.c | 26 +-- > > common/image-sig.c | 49 +++- > > include/image.h | 24 +- > > lib/rsa/rsa-sign.c | 6 +- > > test/py/tests/test_vboot.py | 155 +++-- > > test/py/tests/vboot_forge.py | 423 +++ > > tools/fdt_host.h | 3 +- > > tools/fit_check_sign.c | 8 +- > > tools/image-host.c | 17 +- > > 11 files changed, 601 insertions(+), 118 deletions(-) > > create mode 100644 test/py/tests/vboot_forge.py > > This is applied to dm/master. > > Tom, shall I send a pull request? Yes please, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/14] vboot: Fix forged-configuration vulnerability
Hi, On Wed, 18 Mar 2020 at 11:44, Simon Glass wrote: > > When booting a FIT, if 'bootm' is used without a specified configuration, > U-Boot will use the default one provided in the FIT. But it does not > actually check that the signature is for that configuration. > > This means that it is possible to duplicate a configuration conf-1 to > produce conf-2 (with all the signatures intact), set the default > configuration to conf-2 and then boot the image. U-Boot will verify conf-2 > (in fact since hashed-nodes specifies the conf-1 nodes it will effectively > verify conf-1). Then it will happily boot conf-2 even though it might have > a different kernel. > > This series corrects this problem and adds a test to verify it. It also > updates fit_check_sign to allow the configuration to be specified. > > This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of > F-Secure, who also wrote the vboot_forge script included here. > > This is CVE-2020-10648 > > Changes in v2: > - Bring in new vboot_forge file from the authors > > Simon Glass (14): > image: Correct comment for fit_conf_get_node() > image: Be a little more verbose when checking signatures > image: Return an error message from fit_config_verify_sig() > test: vboot: Drop unnecessary parameter for fit_check_sign > test: vboot: Add a test for a forged configuration > test: vboot: Parameterise the test > image: Check hash-nodes when checking configurations > image: Load the correct configuration in fit_check_sign > fit_check_sign: Allow selecting the configuration to verify > test: vboot: Tidy up the code a little > test: vboot: Fix pylint errors > image: Use constants for 'required' and 'key-name-hint' > test: vboot: Move key creation into a function > test: vboot: Reduce fake kernel size to 500 bytes > > common/bootm.c | 6 +- > common/image-cipher.c| 2 +- > common/image-fit.c | 26 +-- > common/image-sig.c | 49 +++- > include/image.h | 24 +- > lib/rsa/rsa-sign.c | 6 +- > test/py/tests/test_vboot.py | 155 +++-- > test/py/tests/vboot_forge.py | 423 +++ > tools/fdt_host.h | 3 +- > tools/fit_check_sign.c | 8 +- > tools/image-host.c | 17 +- > 11 files changed, 601 insertions(+), 118 deletions(-) > create mode 100644 test/py/tests/vboot_forge.py This is applied to dm/master. Tom, shall I send a pull request? Regards, Simon
[PATCH v2 00/14] vboot: Fix forged-configuration vulnerability
When booting a FIT, if 'bootm' is used without a specified configuration, U-Boot will use the default one provided in the FIT. But it does not actually check that the signature is for that configuration. This means that it is possible to duplicate a configuration conf-1 to produce conf-2 (with all the signatures intact), set the default configuration to conf-2 and then boot the image. U-Boot will verify conf-2 (in fact since hashed-nodes specifies the conf-1 nodes it will effectively verify conf-1). Then it will happily boot conf-2 even though it might have a different kernel. This series corrects this problem and adds a test to verify it. It also updates fit_check_sign to allow the configuration to be specified. This vulnerability was found by Dmitry Janushkevich and Andrea Barisani of F-Secure, who also wrote the vboot_forge script included here. This is CVE-2020-10648 Changes in v2: - Bring in new vboot_forge file from the authors Simon Glass (14): image: Correct comment for fit_conf_get_node() image: Be a little more verbose when checking signatures image: Return an error message from fit_config_verify_sig() test: vboot: Drop unnecessary parameter for fit_check_sign test: vboot: Add a test for a forged configuration test: vboot: Parameterise the test image: Check hash-nodes when checking configurations image: Load the correct configuration in fit_check_sign fit_check_sign: Allow selecting the configuration to verify test: vboot: Tidy up the code a little test: vboot: Fix pylint errors image: Use constants for 'required' and 'key-name-hint' test: vboot: Move key creation into a function test: vboot: Reduce fake kernel size to 500 bytes common/bootm.c | 6 +- common/image-cipher.c| 2 +- common/image-fit.c | 26 +-- common/image-sig.c | 49 +++- include/image.h | 24 +- lib/rsa/rsa-sign.c | 6 +- test/py/tests/test_vboot.py | 155 +++-- test/py/tests/vboot_forge.py | 423 +++ tools/fdt_host.h | 3 +- tools/fit_check_sign.c | 8 +- tools/image-host.c | 17 +- 11 files changed, 601 insertions(+), 118 deletions(-) create mode 100644 test/py/tests/vboot_forge.py -- 2.25.1.481.gfbce0eb801-goog
