#auth

Google has once again pushed its plans to deprecate third-party tracking cookies in its Chrome web browser as it works to address outstanding competition concerns from U.K. regulators over its Privacy Sandbox initiative. The tech giant said it's working closely with the U.K. Competition and Markets Authority (CMA) and hopes to achieve an agreement by the end of the year. As part of the

A security-check flaw was found in the way the Heketi 5 server API handled user requests. An authenticated Heketi user could send specially crafted requests to the Heketi server, resulting in remote command execution as the user running Heketi server and possibly privilege escalation.

### Summary An authenticated user can change the download folder and upload a crafted template to the specified folder lead to remote code execution ### Details example version: 0.5 file:src/pyload/webui/app/blueprints/app_blueprint.py ```python @bp.route("/render/<path:filename>", endpoint="render") def render(filename): mimetype = mimetypes.guess_type(filename)[0] or "text/html" data = render_template(filename) return flask.Response(data, mimetype=mimetype) ``` So, if we can control file in the path "pyload/webui/app/templates" in latest version and path in "module/web/media/js"(the difference is the older version0.4.20 only renders file with extension name ".js"), the render_template func will works like SSTI(server-side template injection) when render the evil file we control. in /settings page and the choose option general/general, where we can change the download folder. ![image](https://github.com/pyload/pyload/assets/48705773/0b239138-9aaa-45c4-bf84-c1c3103c452a...

### Impact A flaw discovered in Rancher versions from 2.5.0 up to and including 2.5.9 allows an authenticated user to impersonate any user on a cluster through the Steve API proxy, without requiring knowledge of the impersonated user's credentials. This is due to the Steve API proxy not dropping the impersonation header before sending the request to the Kubernetes API. A malicious user with authenticated access to Rancher could use this to impersonate another user with administrator access in Rancher, receiving, then, administrator level access in the cluster. ### Patches Patched versions include releases 2.5.10, 2.6.0 and later versions. ### Workarounds Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions. ### For more information If you have any questions or comments about this advisory: * Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquir...

### Impact This vulnerability only affects customers using group based authentication in Rancher versions up to and including 2.4.17, 2.5.11 and 2.6.2. When removing a Project Role associated to a group from a project, the bindings that grant access to cluster scoped resources for those subjects do not get deleted. This happens due to an incomplete authorization logic check. A user who is a member of an affected group with authenticated access to Rancher could use this to access resources they should no longer have access to. The exposure level will depend on the original permission level granted to the affected project role. ### Patches Patched versions include releases 2.4.18, 2.5.12, 2.6.3 and later versions. ### Workarounds Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions. ### References Cluster and project roles documentation for Rancher [2.6](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rba...

Gitea 0.9.99 through 1.12.x before 1.12.6 does not prevent a git protocol path that specifies a TCP port number and also contains newlines (with URL encoding) in ParseRemoteAddr in modules/auth/repo_form.go.

Unlike the SolarWinds and CodeCov incidents, all that it took for an adversary to nearly pull off a massive supply chain attack was some slick social engineering and a string of pressure emails.

The city is stymied in efforts to pinpoint the issue since its IT systems were shut down in the wake of the cyberattack.

### Impact Due to default case-insensitive collation in MySQL or MariaDB databases, third-party authentication user IDs are not case-sensitive and could cause different IDs to match. ### Patches This issue has been addressed by https://github.com/python-social-auth/social-app-django/pull/566 and fix released in 5.4.1. ### Workarounds An immediate workaround would be to change collation of the affected field: ```mysql ALTER TABLE `social_auth_association` MODIFY `uid` varchar(255) COLLATE `utf8_bin`; ``` ### References This issue was discovered by folks at https://opencraft.com/.

### SpEL Injection in `GET /api/v1/policies/validation/condition/<expr>` (`GHSL-2023-236`) ***Please note, only authenticated users have access to PUT / POST APIS for /api/v1/policies. Non authenticated users will not be able to access these APIs to exploit the vulnerability. A user must exist in OpenMetadata and have authenticated themselves to exploit this vulnerability.*** The [`‎CompiledRule::validateExpression`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L51) method evaluates an SpEL expression using an [`StandardEvaluationContext`](https://github.com/open-metadata/OpenMetadata/blob/main/openmetadata-service/src/main/java/org/openmetadata/service/security/policyevaluator/CompiledRule.java#L57), allowing the expression to reach and interact with Java classes such as `java.lang.Runtime`, leading to Remote Code Execution. The `/api/v1/policies/validation/condition/<ex...