Discussion:
Bug#1076042: arm-trusted-firmware: CVE-2024-6563 CVE-2024-6564
Add Reply
Salvatore Bonaccorso
2024-07-09 20:20:01 UTC
Reply
Permalink
Source: arm-trusted-firmware
Version: 2.10.0+dfsg-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: ***@debian.org, Debian Security Team <***@security.debian.org>

Hi,

The following vulnerabilities were published for arm-trusted-firmware.

CVE-2024-6563[0]:
| Buffer Copy without Checking Size of Input ('Classic Buffer
| Overflow') vulnerability in Renesas arm-trusted-firmware allows
| Local Execution of Code. This vulnerability is associated with
| program files https://github.Com/renesas-rcar/arm-trusted-
| firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/i...
| https://github.Com/renesas-rcar/arm-trusted-
| firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/io_rcar.C .
| In line 313 "addr_loaded_cnt" is checked not to be
| "CHECK_IMAGE_AREA_CNT" (5) or larger, this check does not halt the
| function. Immediately after (line 317) there will be an overflow in
| the buffer and the value of "dst" will be written to the area
| immediately after the buffer, which is "addr_loaded_cnt". This will
| allow an attacker to freely control the value of "addr_loaded_cnt"
| and thus control the destination of the write immediately after
| (line 318). The write in line 318 will then be fully controlled by
| said attacker, with whichever address and whichever value ("len")
| they desire.


CVE-2024-6564[1]:
| Buffer overflow in "rcar_dev_init" due to using due to using
| untrusted data (rcar_image_number) as a loop counter before
| verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full
| bypass of secure boot.


If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2024-6563
https://www.cve.org/CVERecord?id=CVE-2024-6563
[1] https://security-tracker.debian.org/tracker/CVE-2024-6564
https://www.cve.org/CVERecord?id=CVE-2024-6564

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore
Diederik de Haas
2024-12-20 21:30:01 UTC
Reply
Permalink
Control: tag -1 fixed-upstream
Post by Salvatore Bonaccorso
Source: arm-trusted-firmware
Version: 2.10.0+dfsg-1
Severity: important
Tags: security upstream
The following vulnerabilities were published for arm-trusted-firmware.
| Buffer Copy without Checking Size of Input ('Classic Buffer
| Overflow') vulnerability in Renesas arm-trusted-firmware allows
| Local Execution of Code. This vulnerability is associated with
| program files https://github.Com/renesas-rcar/arm-trusted-
| firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/i...
| https://github.Com/renesas-rcar/arm-trusted-
| firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/io_rcar.C .
| In line 313 "addr_loaded_cnt" is checked not to be
| "CHECK_IMAGE_AREA_CNT" (5) or larger, this check does not halt the
| function. Immediately after (line 317) there will be an overflow in
| the buffer and the value of "dst" will be written to the area
| immediately after the buffer, which is "addr_loaded_cnt". This will
| allow an attacker to freely control the value of "addr_loaded_cnt"
| and thus control the destination of the write immediately after
| (line 318). The write in line 318 will then be fully controlled by
| said attacker, with whichever address and whichever value ("len")
| they desire.
What a horrible CVE description :-/
Half-finished lines, incorrect file names and line numbers.
It would be great if 'upstream' put a little more effort to make it
usuable and therefor easier to act upon.

/rant

The Notes in the security-tracker are useful, so thanks for that :-)

Fixed in tag v2.11-rc0 in commit:
ae4860b0f5c2 ("fix(rcar3-drivers): check loaded NS image area")
Post by Salvatore Bonaccorso
| Buffer overflow in "rcar_dev_init" due to using due to using
| untrusted data (rcar_image_number) as a loop counter before
| verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full
| bypass of secure boot.
Fixed in tag v2.11-rc0 in commit:
b469880e3b6b ("fix(rcar3-drivers): check "rcar_image_number" variable before use")
Post by Salvatore Bonaccorso
If you fix the vulnerabilities please also make sure to include the
CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
[0] https://security-tracker.debian.org/tracker/CVE-2024-6563
https://www.cve.org/CVERecord?id=CVE-2024-6563
[1] https://security-tracker.debian.org/tracker/CVE-2024-6564
https://www.cve.org/CVERecord?id=CVE-2024-6564
Please adjust the affected versions in the BTS as needed.
Not sure what's meant by this?
I've only/quickly checked the latter CVE and the offending code has been
present since tag v2.1-rc0 via commit:
c2f286820471 ("rcar_gen3: drivers: io [emmc/mem]")

I just checked the upstream lts-2.8 branch and the issue is still
present in tag lts-v2.8.26 (AFAICT the Debian package is at 2.8.0).
There's quite a high chance it's also present in oldstable.
While upstream *may* fix the issue in the lts-v2.8 branch, I think
there's little chance they'll fix prior versions as lts-v2.8 was their
first LTS branch.

Cheers,
Diederik
Vagrant Cascadian
2024-12-20 23:20:01 UTC
Reply
Permalink
Post by Diederik de Haas
Post by Salvatore Bonaccorso
The following vulnerabilities were published for arm-trusted-firmware.
| Buffer Copy without Checking Size of Input ('Classic Buffer
| Overflow') vulnerability in Renesas arm-trusted-firmware allows
| Local Execution of Code.racker are useful, so thanks for that :-)
...
Post by Diederik de Haas
ae4860b0f5c2 ("fix(rcar3-drivers): check loaded NS image area")
Post by Salvatore Bonaccorso
| Buffer overflow in "rcar_dev_init" due to using due to using
| untrusted data (rcar_image_number) as a loop counter before
| verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full
| bypass of secure boot.
b469880e3b6b ("fix(rcar3-drivers): check "rcar_image_number" variable before use")
...
Post by Diederik de Haas
I've only/quickly checked the latter CVE and the offending code has been
c2f286820471 ("rcar_gen3: drivers: io [emmc/mem]")
I just checked the upstream lts-2.8 branch and the issue is still
present in tag lts-v2.8.26 (AFAICT the Debian package is at 2.8.0).
There's quite a high chance it's also present in oldstable.
Present in the source code, perhaps, but not in shipped binaries in the
.deb! The rcar/renesas platform was not added to debian's
arm-trusted-firmware packages until version 2.9.0+dfsg-1.

Thanks for noting the upstream commits fixing the issue!

live well,
vagrant
Diederik de Haas
2024-12-21 00:00:01 UTC
Reply
Permalink
Post by Vagrant Cascadian
Post by Diederik de Haas
Post by Salvatore Bonaccorso
The following vulnerabilities were published for arm-trusted-firmware.
| Buffer overflow in "rcar_dev_init" due to using due to using
| untrusted data (rcar_image_number) as a loop counter before
| verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full
| bypass of secure boot.
b469880e3b6b ("fix(rcar3-drivers): check "rcar_image_number" variable before use")
...
Post by Diederik de Haas
I've only/quickly checked the latter CVE and the offending code has been
c2f286820471 ("rcar_gen3: drivers: io [emmc/mem]")
I just checked the upstream lts-2.8 branch and the issue is still
present in tag lts-v2.8.26 (AFAICT the Debian package is at 2.8.0).
There's quite a high chance it's also present in oldstable.
Present in the source code, perhaps, but not in shipped binaries in the
.deb! The rcar/renesas platform was not added to debian's
arm-trusted-firmware packages until version 2.9.0+dfsg-1.
Excellent, so we just need to update the package in Unstable then.

FTR: the problem is also present upstream in lts-v2.10.10.
I'm not going to do anything with it, but if someone feels inclined,
they could inform upstream about it.
Post by Vagrant Cascadian
Thanks for noting the upstream commits fixing the issue!
You're welcome. I find tracebility important and useful :-)
Did that with my kernel work too, but it doesn't seem to have inspired
others ;-P

Cheers,
Diederik

Diederik de Haas
2024-12-20 22:00:01 UTC
Reply
Permalink
In my previous response I forgot to fix the Subject, so ignore the
'weird' subject, but not its contents, which is fine.
Loading...