ghsa

### Summary In `eza`, there exists a potential heap overflow vulnerability, first seen when using Ubuntu for Raspberry Pi series system, on `ubuntu-raspi` kernel, relating to the `.git` directory. ### Details The vulnerability seems to be triggered by the `.git` directory in some projects. This issue may be related to specific files, and the directory structure also plays a role in triggering the vulnerability. Files/folders that may be involved in triggering the vulnerability include `.git/HEAD`, `.git/refs`, and `.git/objects`. As @polly pointed out to me, this is likely caused by [GHSA-j2v7-4f6v-gpg8](https://github.com/libgit2/libgit2/security/advisories/GHSA-j2v7-4f6v-gpg8), which we do seem to use currently. ### PoC For more information check @CuB3y0nd's blogpost [blog](https://www.cubeyond.net/blog/eza-cve-report). ### Impact Arbitrary code execution.

### Impact A vulnerability has been identified in which unauthenticated cross-site scripting (XSS) in the API Server's public API endpoint can be exploited. This can lead to an attacker exploiting the vulnerability to trigger JavaScript code and execute commands remotely. The attack vector was identified as a Reflected XSS. API Server propagates malicious payloads from user input to the UI, which renders the output. For example, a malicious URL gets rendered into a script that is executed on a page. The changes addressed by this fix are: - Encode input that comes from the request URL before adding it to the response. - The request input is escaped by changing the URL construction that is used for links to use `url.URL`. - The request input is escaped by escaping the JavaScript and CSS variables with attribute encoding as defined by [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary). ### Patches Pat...

### Impact A vulnerability has been identified in which unauthenticated cross-site scripting (XSS) in Norman's public API endpoint can be exploited. This can lead to an attacker exploiting the vulnerability to trigger JavaScript code and execute commands remotely. The attack vector was identified as a Reflected XSS. Norman API propagates malicious payloads from user input to the UI, which renders the output. For example, a malicious URL gets rendered into a script that is executed on a page. The changes addressed by this fix are: - Encode input that comes from the request URL before adding it to the response. - The request input is escaped by changing the URL construction that is used for links to use `url.URL`. - The request input is escaped by escaping the JavaScript and CSS variables with attribute encoding as defined by [OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#output-encoding-rules-summary). ### Patches Patched ver...

### Impact A vulnerability has been identified which may lead to sensitive data being leaked into Rancher's audit logs. [Rancher Audit Logging](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log) is an opt-in feature, only deployments that have it enabled and have [AUDIT_LEVEL](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#audit-log-levels) set to `1 or above` are impacted by this issue. The leaks might be caught in the audit logs upon these actions: - Creating cloud credentials or new authentication providers. It is crucial to note that **all** [authentication providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/authentication-config#external-vs-local-authentication) (such as AzureAD) and [cloud providers](https://ranchermanager.docs.rancher.com/pages-for-subheaders/set-up-cloud-providers) (such as Google) are impacted. - Downloading a kubeconfig file from a downstream...

### Impact A vulnerability has been identified when granting a `create` or `*` **global role** for a resource type of "namespaces"; no matter the API group, the subject will receive `*` permissions for core namespaces. This can lead to someone being capable of accessing, creating, updating, or deleting a namespace in the project. This includes reading or updating a namespace in the project so that it is available in other projects in which the user has the "manage-namespaces" permission or updating another namespace in which the user has normal "update" permissions to be moved into the project. The expected behavior is to not be able to create, update, or delete a namespace in the project or move another namespace into the project since the user doesn't have any permissions on namespaces in the core API group. Moving a namespace to another project could lead to leakage of secrets, in case the targeted project has secrets. And also can lead to the namespace being able to abuse the res...

### Impact The attachment file of an existing record can be replaced if the user has `"read"` permission on one of the parent (collection or bucket). And if the `"read"` permission is given to `"system.Everyone"` on one of the parent, then the attachment can be replaced on a record using an anonymous request. Note that if the parent has no explicit read permission, then the records attachments are safe. ### Patches - Patch released in kinto-attachment 6.4.0 - https://github.com/Kinto/kinto-attachment/commit/f4a31484f5925cbc02b59ebd37554538ab826ca1 ### Workarounds None if the read permission has to remain granted. Updating to 6.4.0 or applying the patch individually (if updating is not feasible) is strongly recommended. ### References - https://bugzilla.mozilla.org/show_bug.cgi?id=1879034

An issue in NPM IP Package v.1.1.8 and before allows an attacker to execute arbitrary code and obtain sensitive information via the `isPublic()` function. This can lead to potential Server-Side Request Forgery (SSRF) attacks. The core issue is the function's failure to accurately distinguish between public and private IP addresses.

# Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. # Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the .be/.Local folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. # PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 1. On FILE_ACTION_ADDED, check if the folder name is .be 1. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 1. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 1. Do hacker things when the engine escalates and the malicious DLL is loaded Proper naming f...

# Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. # Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the .be/.Local folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. # PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 1. On FILE_ACTION_ADDED, check if the folder name is .be 1. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 1. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 1. Do hacker things when the engine escalates and the malicious DLL is loaded Proper naming f...

### Summary .be TEMP folder is vulnerable to DLL redirection attacks that allow the attacker to escalate privileges. ### Details If the bundle is not run as admin, the user's TEMP folder is used and not the system TEMP folder. A utility is able to monitor the user's TEMP folder for changes and drop its own DLL into the **.be/<bundle>.Local** folder immediately when the .be folder is created. When the burn engine elevates, the malicious DLL receives elevated privileges. ### PoC As a standard, non-admin user: 1. Monitor the user's TEMP folder for changes using ReadDirectoryChangesW 2. On FILE_ACTION_ADDED, check if the folder name is .be 3. Create a folder in .be named after the bundle + .Local (e.g. MyInstaller.exe.Local) 4. Put the malicious COMCTL32.DLL in the .Local folder following the naming used for the real DLL (e.g. MyInstaller.exe.Local/x86_microsoft.windows.common-controls_.../COMCTL32.dll) 5. Do hacker things when the engine escalates and the malicious DLL is loaded Proper...