-
Notifications
You must be signed in to change notification settings - Fork 2k
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
shell/rtc: Fix out of bounds access; document error behavior #19141
Conversation
fe52a4d
to
cd62aea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bors merge
🕐 Waiting for PR status (GitHub check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set. |
@@ -39,10 +40,24 @@ static int dow(int year, int month, int day) | |||
{ | |||
/* calculate the day of week using Tøndering's algorithm */ | |||
static int t[] = {0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated optimization proposal: this could be
static int t[] = {0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4}; | |
static const int8_t t[] = {0, 3, 2, 5, 0, 3, 5, 1, 4, 6, 2, 4}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(or even uint8_t
but that's less about optimization and more type correctness)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this even needed?
rtc_tm_normalize()
will already do this - no need to implement this logic in a shell command.
(Ok, wday and yday are only set with RTC_NORMALIZE_COMPAT
enabled because no RTC implementation uses those - but that's even less reason to have them calculated here)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, indeed rtc_utils.c's _wday
is a duplicate of this function, with different properties (it already has the const uint8_t type; it doesn't perform overflow checks but then again is only called with pre-sanitized input).
Honestly, if it was for me, struct tm
would have no place in an embedded OS at all -- I won't impede work on it, and am happy to handle security issues arising from it (even biting down any snark), but addressing this duplication will require judgement calls on "Should the shell RTC command do the full normalization rtc_tm_normalize
performs?" and "Should the shell RTC command pull in RTC_NORMALIZE_COMPAT=1
?", and my answer to both would be mu.
bors merge |
Build succeeded: |
19143: boards: common: stdio_cdc_acm: let tests wait a bit for serial port [backport 2023.01] r=kaspar030 a=kaspar030 # Backport of #19128 19144: shell/rtc: Fix out of bounds access; document error behavior [backport 2023.01] r=kaspar030 a=kaspar030 # Backport of #19141 ### Contribution description ### Testing procedure Should be trivial enough, especially as the difference is hard to spot interactively. On native, run the default example (and wait for the traffic to settle). Then, run ``` > rtc poweron > rtc settime 2022-01-01 00:00:00 > rtc settime 2022-99-01 00:00:00 ``` Both still work, but the latter doesn't access unassigned memory any more ### Issues/PRs references This fixes an issue that was submitted anonymously. Co-authored-by: Martine Lenders <m.lenders@fu-berlin.de> Co-authored-by: chrysn <chrysn@fsfe.org>
19144: shell/rtc: Fix out of bounds access; document error behavior [backport 2023.01] r=kaspar030 a=kaspar030 # Backport of #19141 ### Contribution description ### Testing procedure Should be trivial enough, especially as the difference is hard to spot interactively. On native, run the default example (and wait for the traffic to settle). Then, run ``` > rtc poweron > rtc settime 2022-01-01 00:00:00 > rtc settime 2022-99-01 00:00:00 ``` Both still work, but the latter doesn't access unassigned memory any more ### Issues/PRs references This fixes an issue that was submitted anonymously. Co-authored-by: chrysn <chrysn@fsfe.org>
19010: bootloaders/riotboot: add tinyUSB DFU support r=benpicco a=gschorcht ### Contribution description This PR provides - the tinyUSB DFU and DFU Runtime support and - the `riotboot_tinyusb_dfu` bootloader that uses the tinyUSB DFU mode to flash new application images. ~This PR includes PR #18983 for now to be compilable.~ ### Testing procedure 1. Use any board that supports the `riotboot´ and `tinyusb_device` features and flash the bootloader first, for example ``` BOARD=nucleo-f767zi make -C bootloaders/riotboot_tinyusb_dfu flash ``` and check that the `riotboot_tinyusb_dfu` bootloader is in DFU mode: ``` dfu-util --list ``` 3. Flash a first application using the following command: ``` FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \ make -C tests/saul PROGRAMMER=dfu-util riotboot/flash-slot0 ``` and check that the application starts and is seen as upgradable: ``` dfu-util --list ``` 4. Restart the node in bootloader DFU mode by: ``` dfu-util -e ``` Flash a second application, for example ``` FEATURES_REQUIRED=riotboot USEMODULE=tinyusb_dfu BOARD=nucleo-f767zi \ make -C tests/shell PROGRAMMER=dfu-util riotboot/flash-slot1 ``` and check that the second application starts and is seen as upgradable: ``` dfu-util --list ``` ### Issues/PRs references ~Depends on PR #18983~ 19149: SECURITY: Describe that declassification is an option r=benpicco a=chrysn ### Contribution description Our security policy does not contain provisions for the case when what is reported is not what we consider an actual security issue. As it is described now, everything reported through security@ would go through the full treatment, including a point release. I'm not sure it belongs into the text itself (as it's more about how security reporters interact with the project than internals), but declassification should IMO be backed at least by 3 maintainers, and no strong NACK. ### Issues/PRs references #19141 followed that procedure after some chat on it on the maintainers channel. (In the discussion, I proposed declassification, with 2.5 people supporting it and one "I was about to, but can we be sure nobody is using it?" voice). Co-authored-by: Gunar Schorcht <gunar@schorcht.net> Co-authored-by: chrysn <chrysn@fsfe.org>
Contribution description
When converting a date passed through the shell, the day-of-week calculation performs an out of bounds read access to the month-to-day-of-week calculation array by entering a month outside the 1-12 range. Especially on devices with bit-banded memory, this allows a shell user to read arbitrary memory.
Security Impact
The issue's impact is considered low because the RIOT shell is not generally accessible to users who are not the owner of the device.
Testing procedure
Should be trivial enough, especially as the difference is hard to spot interactively.
On native, run the default example (and wait for the traffic to settle).
Then, run
Both still work, but the latter doesn't access unassigned memory any more
Issues/PRs references
This fixes an issue that was submitted via the security mailing list by Guy Farrelly.
[edit: added missing description, added name of reporter]