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

Fortify Issue: Path Manipulation #294

Closed
cmheazel opened this issue Dec 31, 2017 · 5 comments · Fixed by #515
Closed

Fortify Issue: Path Manipulation #294

cmheazel opened this issue Dec 31, 2017 · 5 comments · Fixed by #515
Assignees
Projects
Milestone

Comments

@cmheazel
Copy link
Contributor

A Fortify scan of the December 28, 2017 source tree has identified 80 Path Manipulation vulnerabilities. A path manipulation vulnerability is a situation where a user may be able to use TeamEngine to access or modify files which they should not have access to. One approach to dealing with this vulnerability is to introduce a "ValidPath" class for managing all file system paths. I have written such a class and integrated it into a branch of TeamEngine. However, the criteria for which paths are valid is not clear.

  1. Is this the best approach for addressing this issue?
  2. How do we distinguish between valid and invalid paths?
@cmheazel cmheazel self-assigned this Jan 3, 2018
@cmheazel
Copy link
Contributor Author

Please review and comment on branch Fortify-Issue-307. The changes in this branch have impacts throughout the code. I would rather catch them earlier than latter. Major changes are:

  1. RuntimeOptions now validates arguments on all "set" operations (returning a boolean) and initializes all properties (no more null responses to a "get" operation).
  2. RuntimeOptions properties are now private. They can only be accessed through "get" and "set".
  3. SetupOptions implements the same changes as were done in RuntimeOptions.
  4. TEPath is used to validate file system paths. The comments in TEPath.java file describe the rules for a valid path.
    In addition, dead code has been isolated (usually by making public operations private), and misc. other potential problems have been repaired.

@cmheazel
Copy link
Contributor Author

This issue was briefed to the CITE Sub Committee membership at the March 2018 TC meetings. The consensus was that it should be sufficient to run TeamEngine in a VM. This leaves us with two actions:

  1. Add a security issues section to the documentation including a discussion of path manipulation and how to counter it.
  2. Complete the code modifications so that if plan A is not sufficient we will still have the code mods to fall back on. Note that this is dependent on merging pull request 317.

@dstenger dstenger added this to In progress in CITE Apr 11, 2019
@dstenger dstenger moved this from In progress to To do in CITE Jan 7, 2020
@namrata-12345
Copy link

Can you please help me how can i fix the path manipulation issue?

@dstenger
Copy link
Contributor

@bpross-52n Can you please check if this issue is solved by #515?

@dstenger dstenger moved this from To do to In progress in CITE Apr 14, 2022
@bpross-52n
Copy link
Contributor

Yes, this is solved by #515.

@dstenger dstenger moved this from In progress to To verify in CITE May 9, 2022
@dstenger dstenger assigned dstenger and unassigned bpross-52n and cmheazel May 9, 2022
CITE automation moved this from To verify to Done May 9, 2022
@dstenger dstenger added this to the 5.5 milestone May 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
CITE
  
Done
Development

Successfully merging a pull request may close this issue.

5 participants