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

syscalls: Sanitize all pointers #606

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

agkaminski
Copy link
Member

@agkaminski agkaminski commented Oct 4, 2024

DONE: RTOS-939

Description

Motivation and Context

Fixes phoenix-rtos/phoenix-rtos-project#976

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Chore (refactoring, style fixes, git/CI config, submodule management, no code logic changes)

How Has This Been Tested?

  • Already covered by automatic testing.
  • New test added: (add PR link here).
  • Tested by hand on: (list targets here).

Checklist:

  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have added tests to cover my changes.
  • All new and existing linter checks and tests passed.
  • My changes generate no new compilation warnings for any of the targets.

Special treatment

  • This PR needs additional PRs to work (list the PRs, preferably in merge-order).
  • I will merge this PR by myself when appropriate.

Copy link

github-actions bot commented Oct 4, 2024

Unit Test Results

7 787 tests  +46   7 054 ✅ +28   43m 24s ⏱️ + 3m 41s
  461 suites ± 0     718 💤 + 3 
    1 files   ± 0      15 ❌ +15 

For more details on these failures, see this check.

Results for commit a3d15c4. ± Comparison against base commit 84b66c2.

♻️ This comment has been updated with latest results.

@agkaminski agkaminski marked this pull request as ready for review October 7, 2024 08:09
Comment on lines +186 to +193
if (vm_mapBelongs(proc, v, sizeof(v)) < 0) {
return -1;
}

for (i = 0;; ++i) {
if (vm_mapBelongs(proc, &v[i], sizeof(v)) < 0) {
return -1;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Wheni = 0 &v[i] == v

@@ -1120,6 +1122,32 @@ int vm_mapBelongs(const struct _process_t *proc, const void *ptr, size_t size)
}


int vm_mapStringBelongs(const struct _process_t *proc, const char *str)
Copy link
Contributor

Choose a reason for hiding this comment

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

This check has one more vulnerability than vm_mapBelongs has. User can also alter the string post NUL byte check. We either have to copy the string or pass the string with length found by this function.

@@ -173,52 +175,119 @@ int syscalls_release(void *ustack)
}


static int syscalls_sanitizeVector(process_t *proc, char **v)
Copy link
Contributor

Choose a reason for hiding this comment

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

On top of vulnerabilities of vm_mapStringBelongs and vm_mapStringBelongs, this function is also vulnerable to user changing the elements of vector. Unfortunatelly, I think that there's no way around copying the vector, but a FIXME note should be sufficient for now.

@badochov
Copy link
Contributor

badochov commented Oct 9, 2024

Probably beyond the scope of this PR, but it would be nice to be resiliant to

mov sp,0
int 0x80

Copy link
Member

@Darchiv Darchiv left a comment

Choose a reason for hiding this comment

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

Several syscalls (e.g. sys_munmap, mprotect) still lack any checks - is this intentional?

@@ -1120,6 +1122,32 @@ int vm_mapBelongs(const struct _process_t *proc, const void *ptr, size_t size)
}


int vm_mapStringBelongs(const struct _process_t *proc, const char *str)
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't there be a fast return for str == NULL or at least handle that per-syscall? To avoid arithmetic on NULLs and unnecessary locks.

@badochov badochov closed this Oct 21, 2024
@badochov badochov reopened this Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

kernel/posix: passing bad arguments to sys_unlink results in Page Fault in kernel
3 participants