Impact What kind of vulnerability is it? Who is impacted?

All users of Nautobot versions earlier than 1.5.7 are impacted.

In Nautobot 1.5.7 we have enabled sandboxed environments for the Jinja2 template engine used internally for template rendering for the following objects:

- extras.ComputedField - extras.CustomLink - extras.ExportTemplate - extras.Secret - extras.Webhook

While we are not aware of any active exploits, we have made this change as a preventative measure to protect against any potential remote code execution attacks utilizing maliciously crafted template code.

This change forces the Jinja2 template engine to use a SandboxedEnvironment on all new installations of Nautobot.

This addresses any potential unsafe code execution everywhere the helper function nautobot.utilities.utils.renderjinja2 is called. Additionally, our documentation that was previously suggesting the direct use of jinja2.Template has been revised to utilize renderjinja2.

Patches Has the problem been patched? What versions should users upgrade to?

Yes. Users should upgrade to Nautobot 1.5.7 or newer.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

Enabling Sandboxed Environments

For users that are unable to upgrade to the latest release of Nautobot, you may add the following setting to your nautobotconfig.py to apply the sandbox environment enforcement:

python TEMPLATES[1]["OPTIONS"]["environment"] = "jinja2.sandbox.SandboxedEnvironment"

After applying this change, you must restart all Nautobot services, including any Celery worker processes.

Note: Nautobot specifies two template engines by default, the first being “django” for the Django built-in template engine, and the second being “jinja” for the Jinja2 template engine. This recommended setting will update the second item in the list of template engines, which is the Jinja2 engine.

Restricting Jinja2 using Access Controls

For users that are unable to immediately update their configuration such as if a Nautobot service restart is too disruptive to operations, access to provide custom Jinja2 template values may be mitigated using permissions to restrict “change” (write) actions to the affected object types listed in the first section.

Note: This solution is intended to be stopgap until you can successfully update your nautobotconfig.py or upgrade your Nautobot instance to apply the sandboxed environment enforcement.

Updating Existing App or Job Code

For Nautobot App (formerly plugin) authors or Job authors, additionally we recommend that if you have any custom code that may for example be using jinaj2.Template that you no longer use that. Instead, please always use our nautobot.utilities.utils.renderjinja2 function which will make sure that the centrally-provided Jinja2 template engine with sandboxing enforced is being utilized.

Anywhere you’ve been using this pattern:

python from jinja2 import Template

mytemplate = Template(templatecode) config = mytemplate.render(context)

We recommend that you replace it with this pattern:

python from nautobot.utilities.utils import renderjinja2 config = renderjinja2(templatecode, context)

References Are there any links users can visit to find out more?

Please see the Nautobot 1.5.7 release notes.

https://docs.nautobot.com/projects/core/en/stable/release-notes/version-1.5/#v157-2023-01-04

Impact

Nautobot's Webhook data model and associated feature set could be configured by users with sufficient access to perform requests to various hosts and IP addresses that should not be permitted, allowing for various behaviors similar to server-side request forgery (SSRF).

Patches

Fixes are available in Nautobot v2.4.33 and v3.1.2.

In support of this fix, three new settings variables have been added to Nautobot:

- WEBHOOKALLOWEDSCHEMES - By default new or updated Webhook records will be restricted to HTTP or HTTPS only, disallowing other schemes that may have been previously allowed. Administrators should audit existing Webhook records to identify any that are invalid, and either update/delete said records or customize WEBHOOKALLOWEDSCHEMES as appropriate. - WEBHOOKADDITIONALBLOCKEDNETWORKS - This can be used to specify additional IP networks that should be denied to Webhook sending, for example some deployments may wish to disallow RFC1918 addresses or even disallow all networks and carve out specific exemptions using the following setting. - WEBHOOKALLOWEDHOSTS - This can be used to provide an allow-list of specific hosts that would otherwise be blocked by any WEBHOOKADDITIONALBLOCKEDNETWORKS configuration.

Workarounds

Administrators should review which users have been granted add or change permissions for the Webhook data model, and should review currently defined Webhook records for safety and validity. Other than that, no specific workaround has been identified.

References

- 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/16aa4aa9796ab7a31c4d615ec945e1f16d8c77c4">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/7324c8f0d8c7245fbc691e15d729adc2d2707d08">patch</a>)

Impact

In Nautobot 2.0.x, certain REST API endpoints, in combination with the ?depth=<N> query parameter, can expose hashed user passwords as stored in the database to any authenticated user with access to these endpoints.

The passwords are not exposed in plaintext. Nautobot 1.x is not affected by this vulnerability.

Example:

GET /api/users/permissions/?depth=1

HTTP 200 OK API-Version: 2.0 Allow: GET, POST, PUT, PATCH, DELETE, HEAD, OPTIONS Content-Type: application/json Vary: Accept

json { "count": 1, "next": null, "previous": null, "results": [ { "id": "28ea85e4-5039-4389-94f1-9a3e1c787149", "objecttype": "users.objectpermission", "display": "Run Job", "url": "http://localhost:8080/api/users/permissions/28ea85e4-5039-4389-94f1-9a3e1c787149/", "naturalslug": "run-job28ea", "objecttypes": [ "extras.job" ], "name": "Run Job", "description": "", "enabled": true, "actions": [ "run", "view" ], "constraints": null, "groups": [ { "id": 1, "objecttype": "auth.group", "display": "A Group", "url": "http://localhost:8080/api/users/groups/1/", "naturalslug": "a-group1", "name": "A Group" } ], "users": [ { "id": "e73288e2-1326-4bfb-8fea-041290dd7473", "objecttype": "users.user", "display": "admin", "url": "http://localhost:8080/api/users/users/e73288e2-1326-4bfb-8fea-041290dd7473/", "naturalslug": "admine732", "password": "pbkdf2sha256$260000$jQb7hA48HYJ0MLWQgOZiBl$b72+gz6SpZiRpxceRQfT5Zv/aUac0eJ4NdBTZ8ECOow=", "lastlogin": "2023-10-18T14:19:08.780857Z", "issuperuser": true, "username": "admin", "firstname": "", "lastname": "", "email": "", "isstaff": true, "isactive": true, "datejoined": "2023-10-18T14:18:55.854023Z", "configdata": {} } ] } ] }

Note the "password" field present in the nested "users" data.

This information is not exposed during direct access to the /api/users/users/ endpoint, but can be exposed through any endpoint which contains a nested reference to User object(s) when an appropriate ?depth=<N> query parameter is specified. Known impacted endpoints include:

- /api/dcim/rack-reservations/?depth=1(or any greater depth value) - /api/extras/job-results/?depth=1 (or any greater depth value) - /api/extras/notes/?depth=1 (or any greater depth value) - /api/extras/object-changes/?depth=1 (or any greater depth value) - /api/extras/scheduled-jobs/?depth=1 (or any greater depth value) - /api/users/permissions/?depth=1 (or any greater depth value)

but this is not necessarily an exhaustive list.

Plugin REST API endpoints for any models with a foreign key to the User model may also be impacted by this issue.

The patch identified below mitigates the issue for both Nautobot core REST APIs and plugin REST APIs; no code change in plugins is required to address this issue.

Patches

Refer to https://github.com/nautobot/nautobot/pull/4692 for the patch that resolved this issue.

Workarounds

Upgrading to v2.0.3 or later, or applying the above patch, is the preferred workaround for this issue; while it could also be partially mitigated by updating permissions to deny user access to the above list of impacted REST API endpoints, that is not recommended as other endpoints may also expose this issue until patched.

References

https://github.com/nautobot/nautobot/pull/4692

Impact

It was discovered that due to improper handling and escaping of user-provided query parameters, a maliciously crafted Nautobot URL could potentially be used to execute a Reflected Cross-Site Scripting (Reflected XSS) attack against users. All filterable object-list views in Nautobot are vulnerable, including:

- /dcim/location-types/ - /dcim/locations/ - /dcim/racks/ - /dcim/rack-groups/ - /dcim/rack-reservations/ - /dcim/rack-elevations/ - /tenancy/tenants/ - /tenancy/tenant-groups/ - /extras/tags/ - /extras/statuses/ - /extras/roles/ - /extras/dynamic-groups/ - /dcim/devices/ - /dcim/platforms/ - /dcim/virtual-chassis/ - /dcim/device-redundancy-groups/ - /dcim/interface-redundancy-groups/ - /dcim/device-types/ - /dcim/manufacturers/ - /dcim/cables/ - /dcim/console-connections/ - /dcim/power-connections/ - /dcim/interface-connections/ - /dcim/interfaces/ - /dcim/front-ports/ - /dcim/rear-ports/ - /dcim/console-ports/ - /dcim/console-server-ports/ - /dcim/power-ports/ - /dcim/power-outlets/ - /dcim/device-bays/ - /dcim/inventory-items/ - /ipam/ip-addresses/ - /ipam/prefixes - /ipam/rirs/ - /ipam/namespaces/ - /ipam/vrfs/ - /ipam/route-targets/ - /ipam/vlans/ - /ipam/vlan-groups/ - /ipam/services/ - /virtualization/virtual-machines/ - /virtualization/interfaces/ - /virtualization/clusters/ - /virtualization/cluster-types/ - /virtualization/cluster-groups/ - /circuits/circuits/ - /circuits/circuit-types/ - /circuits/providers/ - /circuits/provider-networks/ - /dcim/power-feeds/ - /dcim/power-panels/ - /extras/secrets/ - /extras/secrets-groups/ - /extras/jobs/ - /extras/jobs/scheduled-jobs/approval-queue/ - /extras/jobs/scheduled-jobs/ - /extras/job-results/ - /extras/job-hooks/ - /extras/job-buttons/ - /extras/object-changes/ - /extras/git-repositories/ - /extras/graphql-queries/ - /extras/relationships/ - /extras/notes/ - /extras/config-contexts/ - /extras/config-context-schemas/ - /extras/export-templates/ - /extras/external-integrations/ - /extras/webhooks/ - /extras/computed-fields/ - /extras/custom-fields/ - /extras/custom-links/

as well as any similar object-list views provided by any Nautobot App.

Patches

Fixed in Nautobot 1.6.20 and 2.2.3.

Workarounds

No workaround has been identified

References

- #5646 - #5647

Credit to Michael Panorios for reporting this issue.

Impact

A Nautobot user with admin privileges can modify the BANNERTOP, BANNERBOTTOM, and BANNERLOGIN configuration settings via the /admin/constance/config/ endpoint. Normally these settings are used to provide custom banner text at the top and bottom of all Nautobot web pages (or specifically on the login page in the case of BANNERLOGIN) but it was reported that an admin user can make use of these settings to inject arbitrary HTML, potentially exposing Nautobot users to security issues such as cross-site scripting (stored XSS).

Patches Has the problem been patched? What versions should users upgrade to?

Patches will be released as part of Nautobot 1.6.22 and 2.2.4.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

As described in the Nautobot documentation, these settings are only configurable through the admin UI of Nautobot if they are not explicitly set to some non-empty value in the nautobotconfig.py or equivalent Nautobot configuration file. Therefore, adding the following configuration to said file completely mitigates this vulnerability in both Nautobot 1.x and 2.x:

python BANNERLOGIN = " " BANNERTOP = " " BANNERBOTTOM = " "

or alternately (Nautobot 2.x only), if those variables are not defined explicitly in your configuration file, setting the following environment variables for the Nautobot user account serves the same purpose:

shell NAUTOBOTBANNERLOGIN=" " NAUTOBOTBANNERTOP=" " NAUTOBOTBANNERBOTTOM=" "

Limiting all users who do not need elevated privileges to non-admin access (issuperuser: False and isstaff: False) is a partial mitigation as well.

References

- https://github.com/nautobot/nautobot/pull/5697 - https://github.com/nautobot/nautobot/pull/5698

Impact

All users of Nautobot versions earlier than 1.6.10 or 2.1.2 are potentially impacted.

Due to inadequate input sanitization, any user-editable fields that support Markdown rendering, including:

- Circuit.comments - Cluster.comments - CustomField.description - Device.comments - DeviceRedundancyGroup.comments - DeviceType.comments - Job.description - JobLogEntry.message - Location.comments - Note.note - PowerFeed.comments - Provider.noccontact - Provider.admincontact - Provider.comments - ProviderNetwork.comments - Rack.comments - Tenant.comments - VirtualMachine.comments - Contents of any custom fields of type markdown - Job class description attributes - The SUPPORTMESSAGE system configuration setting

are potentially susceptible to cross-site scripting (XSS) attacks via maliciously crafted data.

Patches

Fixed in Nautobot versions 1.6.10 and 2.1.2.

References

https://github.com/nautobot/nautobot/pull/5133 https://github.com/nautobot/nautobot/pull/5134

Impact What kind of vulnerability is it? Who is impacted?

All users of Nautobot versions prior to 2.4.10 or prior to 1.6.32 are potentially affected.

Due to insufficient security configuration of the Jinja2 templating feature used in computed fields, custom links, etc. in Nautobot:

1. A malicious user could configure this feature set in ways that could expose the value of Secrets defined in Nautobot when the templated content is rendered. 2. A malicious user could configure this feature set in ways that could call Python APIs to modify data within Nautobot when the templated content is rendered, bypassing the object permissions assigned to the viewing user.

Patches Has the problem been patched? What versions should users upgrade to?

Nautobot versions 1.6.32 and 2.4.10 will include fixes for the vulnerability.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

The vulnerability can be partially mitigated by configuring object permissions appropriately to limit the below actions to only trusted users:

- extras.addsecret - extras.changesecret - extras.viewsecret - extras.addcomputedfield - extras.changecomputedfield - extras.addcustomlink - extras.changecustomlink - extras.addjobbutton - extras.changejobbutton

References Are there any links users can visit to find out more?

- https://jinja.palletsprojects.com/en/stable/sandbox/ - https://docs.djangoproject.com/en/4.2/ref/templates/api/#alters-data-description - https://github.com/nautobot/nautobot/pull/7417 - https://github.com/nautobot/nautobot/pull/7429

Impact

A user with access to add/change a GitRepository record could use the REST API to directly set the currenthead field on the record, which was not intended to be user-editable. Doing so could cause Nautobot's local clone(s) of the relevant repository to checkout a commit other than the latest commit on the specified branch (resulting in misleading state), or potentially to be unable to make use of the repository at all (until manually remediated) due to the currenthead pointing to a nonexistent commit hash or malformed value.

Patches

The issue has been remediated in Nautobot v2.4.33 and 3.1.2.

Workarounds

Note that many of the same end-result symptoms could be caused by a user with the same level of access simply changing the branch or remoteurl of a GitRepository rather than crafting the currenthead. Administrators are encouraged to carefully review which users are granted permissions to create and modify GitRepository records.

References

- 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9deddfc91ad9260ad17b5e20084e9e2d15be3609">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/c46f97040b2bde4320be36b23577f19a8bcbd8c3">patch</a>)

Impact

All users of Nautobot versions earlier than 1.6.6 or 2.0.5 are potentially affected.

Due to incorrect usage of Django's marksafe() API when rendering certain types of user-authored content, including:

- custom links - job buttons - computed fields

it is possible that users with permission to create or edit these types of content could craft a malicious payload (such as JavaScript code) that would be executed when rendering pages containing this content.

Patches Has the problem been patched? What versions should users upgrade to?

We have fixed the incorrect uses of marksafe() (generally by replacing them with appropriate use of formathtml() instead) to prevent such malicious data from being executed.

Users on Nautobot 1.6.x LTM should upgrade to v1.6.6 and users on Nautobot 2.0.x should upgrade to v2.0.5.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

Appropriate object permissions can and should be applied to restrict which users are permitted to create or edit the aforementioned types of user-authored content. Other than that, there is no direct fix available.

References Are there any links users can visit to find out more?

- https://github.com/nautobot/nautobot/pull/4832 - https://github.com/nautobot/nautobot/pull/4833 - https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.html.formathtml - https://docs.djangoproject.com/en/3.2/ref/utils/#django.utils.safestring.marksafe

Impact What kind of vulnerability is it? Who is impacted?

A user with permissions to view Dynamic Group records (extras.viewdynamicgroup permission) can use the Dynamic Group detail UI view (/extras/dynamic-groups/<uuid>/) and/or the members REST API view (/api/extras/dynamic-groups/<uuid>/members/) to list the objects that are members of a given Dynamic Group.

In versions of Nautobot between 1.3.0 (where the Dynamic Groups feature was added) and 1.6.22 inclusive, and 2.0.0 through 2.2.4 inclusive, Nautobot fails to restrict these listings based on the member object permissions - for example a Dynamic Group of Device objects will list all Devices that it contains, regardless of the user's dcim.viewdevice permissions or lack thereof.

Patches Has the problem been patched? What versions should users upgrade to?

Fixed in Nautobot 1.6.23 and 2.2.5.

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

This vulnerability can be partially mitigated by removing extras.viewdynamicgroup permission from users; a full fix will require upgrading.

References Are there any links users can visit to find out more?

- https://github.com/nautobot/nautobot/pull/5757 - https://github.com/nautobot/nautobot/pull/5762

Impact

Nautobot UI object-bulk-rename endpoints (for example, /dcim/interfaces/rename/) were vulnerable to application-wide denial of service via maliciously crafted regular expressions in the find field in combination with the useregex flag.

Patches

A general-purpose timeout has been added to these endpoints in Nautobot v2.4.33 and v3.1.2, which ensures that the request will fail early with an appropriate message if regular expression evaluation takes more than a short period of time, instead of continuing to execute for an indefinite duration.

Workarounds

No known workaround has been identified at this time.

References

- 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/c2b766966d814a7141f62c7bc90c85fefb7892ee">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/5a30d0916953afbeedd24a784709e762cc3879cd">patch</a>)

Impact

Files uploaded by users to Nautobot's MEDIAROOT directory, including DeviceType image attachments as well as images attached to a Location, Device, or Rack, are served to users via a URL endpoint that was not enforcing user authentication. As a consequence, such files can be retrieved by anonymous users who know or can guess the correct URL for a given file.

For DeviceType image attachments, a mitigating factor is that no URL endpoint exists for listing the contents of the devicetype-images/ subdirectory, and the file names are as specified by the uploading user, so any given DeviceType image attachment can only be retrieved by correctly guessing its file name.

Similarly, for all other image attachments, while the images can be listed by accessing the /api/extras/image-attachments/ endpoint as an authenticated user only, absent that authenticated access, accessing the files would again require guessing file names correctly.

Patches

Nautobot v2.4.10 and v1.6.32 will address this issue by adding enforcement of Nautobot user authentication to this endpoint.

Workarounds

No workaround other than applying the patch given in https://github.com/nautobot/nautobot/pull/6672 (2.x) or https://github.com/nautobot/nautobot/pull/6703 (1.6)

References Are there any links users can visit to find out more?

- https://github.com/nautobot/nautobot/commit/9c892dc300429948a4714f743c9c2879d8987340 - https://github.com/nautobot/nautobot/commit/d99a53b065129cff3a0fa9abe7355a9ef1ad4c95

Impact

In the case of inter-object references via GenericForeignKey (a pattern allowing an object to reference another object that may belong to one of several different "content types" or database tables), when creating or updating an object containing a GenericForeignKey, Nautobot's REST API failed to enforce user "view" permissions when determining whether a given reference to another object would be valid.

As a concrete example, a user:

- who has permission to create or update ImageAttachment records - but who lacks permission to view (some or all) Device records - but who knows (via some other mechanism) the UUID of a specific Device that they do not otherwise have access to

could create via the REST API an ImageAttachment linked to that specific Device.

Other models that use GenericForeignKey and may be writable via the REST API, and hence have a similar vulnerability to ImageAttachment, may include:

- ApprovalWorkflow - Cable - ConfigContext - ContactAssociation - DataCompliance - Device - ExportTemplate - GraphQLQuery - Note - ObjectMetadata - RelationshipAssociation - StaticGroupAssociation - VirtualMachine

Additionally, any Nautobot Apps that provide models with a REST API and use GenericForeignKey may have a similar vulnerability for their models.

Patches

A general-purpose fix has been implemented in Nautobot 2.4.33 and 3.1.2, which ensures correct application of "view" permissions when creating or modifying object references via GenericForeignKey throughout the REST API. Individual models/views/serializers generally will not require any specific code changes to benefit from this fix.

Workarounds

No known workarounds at this time.

References

- 2.4.33 (<a href="https://github.com/nautobot/nautobot/commit/9918bdb9bcf1eb42cda72c344f420a64ef7665f1">patch</a>) - 3.1.2 (<a href="https://github.com/nautobot/nautobot/commit/36cde7148a207234de6212ec074f321dbc9d1b5b">patch</a>)

Impact

A number of Nautobot URL endpoints were found to be improperly accessible to unauthenticated (anonymous) users, including the following:

- /api/graphql/ (1) - /api/users/users/session/ (Nautobot 2.x only; the only information exposed to an anonymous user is which authentication backend classes are enabled on this Nautobot instance) - /dcim/racks/<uuid:pk>/dynamic-groups/ (1) - /dcim/devices/<uuid:pk>/dynamic-groups/ (1) - /extras/job-results/<uuid:pk>/log-table/ - /extras/secrets/provider/<str:providerslug>/form/ (the only information exposed to an anonymous user is the fact that a secrets provider with the given slug (e.g. environment-variable or text-file) is supported by this Nautobot instance) - /ipam/prefixes/<uuid:pk>/dynamic-groups/ (1) - /ipam/ip-addresses/<uuid:pk>/dynamic-groups/ (1) - /virtualization/clusters/<uuid:pk>/dynamic-groups/ (1) - /virtualization/virtual-machines/<uuid:pk>/dynamic-groups/ (1)

(1) These endpoints will not disclose any Nautobot data to an unauthenticated user unless the Nautobot configuration variable EXEMPTVIEWPERMISSIONS is changed from its default value (an empty list) to permit access to specific data by unauthenticated users.

Of these endpoints, the only one that poses any significant risk of sensitive information disclosure under normal Nautobot operation with a default configuration is /extras/job-results/<uuid:pk>/log-table/. This endpoint returns an HTML table containing all of the logs associated with the specified JobResult; while these logs may contain sensitive information depending on the Jobs executed in Nautobot, this exposure is mitigated somewhat by the fact that any attacker would have to have prior knowledge of the existence of a JobResult with a particular UUID.

In the interest of full disclosure, the following additional endpoints were also accessible to anonymous users, but do not disclose any sensitive data when accessed (only a listing of other API endpoints).

- /api/ - /api/circuits/ - /api/dcim/ - /api/extras/ - /api/ipam/ - /api/plugins/ - /api/tenancy/ - /api/users/ - /api/virtualization/

All of the above endpoints have been corrected to require user authentication, with the exception of /api/users/users/session/ which is unused at this time and therefore has been simply removed from Nautobot 2.1.9. Additionally, we have added test automation which enumerates available Nautobot URL endpoints and verifies that appropriate authentication requirements are in place; this test was instrumental in identifying the above comprehensive list.

Patches

Fixes will be included in Nautobot 1.6.16 and 2.1.9.

Workarounds

Partial workaround: If your configuration includes a non-default value for EXEMPTVIEWPERMISSIONS (the Nautobot default is an empty list), reverting it to default will prevent exposure of Nautobot information to unauthenticated users via the endpoints marked with (1) above.

References Are there any links users can visit to find out more?

Impact

In Nautobot 1.x and 2.0.x, the URLs /files/get/?name=... and /files/download/?name=... are used to provide admin access to files that have been uploaded as part of a run request for a Job that has FileVar inputs. Under normal operation these files are ephemeral and are deleted once the Job in question runs.

It was reported by @kircheneer that in the default implementation used in Nautobot, as provided by django-db-file-storage, these URLs do not by default require any user authentication to access; they should instead be restricted to only users who have permissions to view Nautobot's FileProxy model instances.

Note that no URL mechanism is provided for listing or traversal of the available file name values, so in practice an unauthenticated user would have to guess names to discover arbitrary files for download, but if a user knows the file name/path value, they can access it without authenticating, so we are considering this a vulnerability.

Patches

Fixes will be included in Nautobot 1.6.7 and Nautobot 2.0.6.

Workarounds

No workaround other than applying the patches included in https://github.com/nautobot/nautobot/pull/4959/files (2.0.x) or https://github.com/nautobot/nautobot/pull/4964/files (1.6.x)

References

- https://github.com/victor-o-silva/dbfilestorage/blob/master/dbfilestorage/views.py

Impact

In Nautobot versions prior to 2.4.30 or prior to 3.0.10, user creation and editing via the REST API fails to apply the password validation rules defined by Django's AUTHPASSWORDVALIDATORS setting (which defaults to an empty list, i.e., no specific rules, but can be configured in Nautobot's nautobotconfig.py to apply various rules if desired). This can potentially allow for the creation or modification of users to have passwords that are weak or otherwise do not comply with configured standards.

Management of users via the Nautobot admin UI does correctly enforce configured password validation at this time.

Patches

The issue is resolved in Nautobot versions 2.4.30 and 3.0.10 and later.

- https://github.com/nautobot/nautobot/pull/8778 - https://github.com/nautobot/nautobot/pull/8779

Workarounds

Review which users have been granted object permissions to create and modify user accounts as well as having access tokens for the REST API, and restrict access as appropriate.

It may be appropriate furthermore to rotate passwords for any user accounts suspected to have been given weak passwords.

References

- https://docs.djangoproject.com/en/4.2/ref/settings/#std-setting-AUTHPASSWORDVALIDATORS - http://docs.djangoproject.com/en/4.2/topics/auth/passwords/#password-validation

Impact

When submitting a Job to run via a Job Button, only the model-level extras.runjob permission is checked (i.e., does the user have permission to run Jobs in general?). Object-level permissions (i.e., does the user have permission to run this specific Job?) are not enforced by the URL/view used in this case (/extras/job-button/<uuid>/run/) The effect is that a user with permissions to run even a single Job can actually run all configured JobButton Jobs.

Not all Jobs can be configured as JobButtons; only those implemented as subclasses of JobButtonReceiver can be used in this way, so this vulnerability only applies specifically to JobButtonReceiver subclasses.

Additionally, although the documentation states that both extras.runjob permission and extras.runjobbutton permission must be granted to a user in order to run Jobs via JobButton, the extras.runjobbutton permission is not actually enforced by the view code, only by the UI by disabling the button from being clicked normally. Furthermore, the extras.runjobbutton permission never prevented invoking Jobs (including JobButtonReceiver subclasses) via the normal "Job Run" UI, so after some discussion, we've decided that the extras.runjobbutton permission is redundant, and as it never achieved its stated/documented purpose, the fixes below will remove the UI check for extras.runjobbutton and all other references to the extras.runjobbutton permission, rather than adding enforcement of this previously unenforced permission.

Patches Has the problem been patched? What versions should users upgrade to?

Fix will be available in Nautobot 1.6.8 (https://github.com/nautobot/nautobot/pull/4995) and 2.1.0 (https://github.com/nautobot/nautobot/pull/4993)

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?

Partial mitigation can be achieved by auditing JobButtonReceiver subclasses defined in the system and restricting which users are permitted to create or edit JobButton records.

References

- https://github.com/nautobot/nautobot/issues/4988 - https://github.com/nautobot/nautobot/pull/4993 - https://github.com/nautobot/nautobot/pull/4995