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

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

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

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

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

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