Skip to content
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

Merged
merged 1 commit into from
Jan 13, 2023

Conversation

chrysn
Copy link
Member

@chrysn chrysn commented Jan 13, 2023

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

> 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 via the security mailing list by Guy Farrelly.

[edit: added missing description, added name of reporter]

@chrysn chrysn added the Impact: minor The PR is small in size and might only require a quick look of a knowledgeable reviewer label Jan 13, 2023
@chrysn chrysn requested a review from kaspar030 January 13, 2023 15:09
@github-actions github-actions bot added the Area: sys Area: System label Jan 13, 2023
Copy link
Member

@maribu maribu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bors merge

@bors
Copy link
Contributor

bors bot commented Jan 13, 2023

🕐 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.

@maribu maribu added CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) Area: security Area: Security-related libraries and subsystems labels Jan 13, 2023
@@ -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};
Copy link
Member

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

Suggested change
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};

Copy link
Member

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)

Copy link
Contributor

@benpicco benpicco Jan 13, 2023

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)

Copy link
Member Author

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.

@riot-ci
Copy link

riot-ci commented Jan 13, 2023

Murdock results

✔️ PASSED

cd62aea shell/rtc: Fix out of bounds access; document error behavior

Success Failures Total Runtime
6768 0 6768 12m:19s

Artifacts

@maribu
Copy link
Member

maribu commented Jan 13, 2023

bors merge

@kaspar030 kaspar030 added the Process: needs backport Integration Process: The PR is required to be backported to a release or feature branch label Jan 13, 2023
@bors
Copy link
Contributor

bors bot commented Jan 13, 2023

Build succeeded:

@bors bors bot merged commit d89379e into RIOT-OS:master Jan 13, 2023
bors bot added a commit that referenced this pull request Jan 13, 2023
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>
bors bot added a commit that referenced this pull request Jan 14, 2023
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>
@chrysn chrysn deleted the rtc-dow-overflow branch January 15, 2023 10:05
bors bot added a commit that referenced this pull request Jan 15, 2023
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>
@jia200x jia200x added this to the Release 2023.04 milestone Apr 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: security Area: Security-related libraries and subsystems Area: sys Area: System CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR Impact: minor The PR is small in size and might only require a quick look of a knowledgeable reviewer Process: needs backport Integration Process: The PR is required to be backported to a release or feature branch Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
No open projects
Status: Fix in release branch
Development

Successfully merging this pull request may close these issues.

7 participants