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

Fix `in_exposed_bounds` security vulnerability #1114

Merged
merged 1 commit into from Jul 16, 2018

Conversation

Projects
None yet
4 participants
@alevy
Copy link
Member

alevy commented Jul 13, 2018

Pull Request Overview

in_exposed_bounds was checking whether a buffer was within a process's entire memory space, rather than just the memory currently exposed (by the MPU) to the process. This region ends at the kernel_memory_break, not at mem_end().

An example attack is a process calls the allow system call with a buffer located somewhere in the current grant region, thus overlapping with an allocated grant. Whichever capsules gets to access this buffer would have access to that grant's private fields.

(Credit to @bradjc for finding this bug)

Testing Strategy

TODO

TODO or Help Wanted

At the time of writing, I don't have hardware on hand. If someone gets to testing this, please update. Let's probably not merge before testing.

Documentation Updated

  • Updated the relevant files in /docs, or no updates are required.

Formatting

  • Ran make formatall.

@alevy alevy added the bug label Jul 13, 2018

@ppannuto
Copy link
Member

ppannuto left a comment

Nice catch.

Should that unsafe offset the line before be doing some bounds checking as well? The size parameter is passed directly from userland as an argument to allow.

I think an adversarial size parameter would result in undefined behavior: https://doc.rust-lang.org/std/primitive.pointer.html#method.offset ?

Fix in_exposed_bounds bug
`in_exposed_bounds` was checking whether a buffer was within a process's
_entire_ memory space, rather than _just_ the memory currently _exposed_
(by the MPU) to the process. This region ends at the
`kernel_memory_break`, not at `mem_end()`.

Added a comment to clarify what `in_exposed_bounds` is meant to do.

@alevy alevy force-pushed the alevy:bug/in_exposed_bounds branch from 0f5abee to 7778187 Jul 16, 2018

@alevy

This comment has been minimized.

Copy link
Member

alevy commented Jul 16, 2018

@ppannuto addressed your comment

@bradjc

bradjc approved these changes Jul 16, 2018

@alevy alevy merged commit f76a785 into tock:master Jul 16, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
deploy/netlify Deploy preview ready!
Details

@alevy alevy deleted the alevy:bug/in_exposed_bounds branch Jul 16, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment