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

Server-Side Template Injection in webhooks, export templates and custom links. #6921

Closed
kkthxbye-code opened this issue Aug 9, 2021 · 5 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@kkthxbye-code
Copy link
Contributor

kkthxbye-code commented Aug 9, 2021

NetBox version

v.2.11.10

Python version

3.8

Steps to Reproduce

  1. Create a site
  2. Create export template for sites
  3. Fill out required fields
  4. Enter {{ ''.__class__.__mro__[1].__subclasses__()[199]('id', shell=True,stdout=-1).communicate()}} in template code. Indexes for mro and subclasses will probably differ per instance.
  5. Go to sites and execute the export template
  6. Open generated csv file

Expected Behavior

Error or default csv file generated

Observed Behavior

.csv file contains (b'uid=101 gid=0(root)\n', None)

Suggestions

I see two immediate options.

  1. Make it clear in the documentation that having rights to create webhooks, export templates or custom links is dangerous and allows RCE on the host.
  2. Use the jinja2 sandbox: https://jinja.palletsprojects.com/en/3.0.x/sandbox/

With option 2 there should probably still be a note in the documentation, as sandboxes are rarely known to be perfect.

@kkthxbye-code kkthxbye-code added the type: bug A confirmed report of unexpected behavior in the application label Aug 9, 2021
@jeremystretch
Copy link
Member

This is a pretty well-known issue with Jinja2 other templating engines in general. We could add some form of additional warning, I guess, though it may be difficult to succinctly convey the relative risk. Given that only authenticated users who have been specifically granted access can create these objects in the first place, it's probably not a huge concern.

The sandbox is a neat idea, but we'll need to dig into it more to see if there are any blockers.

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Aug 9, 2021
@jeremystretch
Copy link
Member

.csv file contains (b'uid=101 gid=0(root)\n', None)

By the way, you shouldn't be running NetBox as a member of the root group. The installation docs recommend creating a unique netbox user with its own group.

@kkthxbye-code
Copy link
Contributor Author

kkthxbye-code commented Aug 9, 2021

By the way, you shouldn't be running NetBox as a member of the root group.

It's not a production system, it's a completely clean run of netbox-docker. I also run docker with user namespaces, so it doesn't even map to the root group on the host. Anyway, not sure why they change the user and not the group in the compose file.

@sdktr
Copy link
Contributor

sdktr commented Aug 9, 2021

By the way, you shouldn't be running NetBox as a member of the root group.

It's not a production system, it's a completely clean run of netbox-docker. I also run docker with user namespaces, so it doesn't even map to the root group on the host. Anyway, not sure why they change the user and not the group in the compose file.

Let's open an issue on the netbox-docker to discuss the user/group assignments/mappings when running netbox in a container

Edit: not the first permission related issue in netbox-docker. Check this enhancement: netbox-community/netbox-docker#546

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Aug 11, 2021
@jeremystretch jeremystretch self-assigned this Aug 11, 2021
@jeremystretch
Copy link
Member

I've updated the render_jinja2() we use for all Jinja2 code to employ the SandboxedEnvironment as suggested, and updated the relevant documentation to call out the relative risks of allowing user-submitted code.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 9, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants