#auth

In Sulu v2.0.0 through v2.6.4 are vulnerable against XSS whereas a low privileged user with an access to the “Media” section can upload an SVG file with a malicious payload. Once uploaded and accessed, the malicious javascript will be executed on the victims’ (other users including admins) browsers.

Despite what lessons we thought we learned from Colonial Pipeline, none of those lessons have been able to be put into practice.

Although the veto was a setback, it highlights key debates in the emerging field of AI governance and the potential for California to shape the future of AI regulation.

### Impact An abstract UNIX domain socket responsible for introspection is available without authentication locally to any user with access to the network namespace where the local juju agent is running. On a juju controller agent, denial of service can be performed by using the `/leases/revoke` endpoint. Revoking leases in juju can cause availability issues. On a juju machine agent that is hosting units, disabling the unit component can be performed using the `/units` endpoint with a "stop" action. ### Patches Patch: https://github.com/juju/juju/commit/43f0fc59790d220a457d4d305f484f62be556d3b Patched in: - 3.5.4 - 3.4.6 - 3.3.7 - 3.1.10 - 2.9.51 ### Workarounds No workaround. ### References https://github.com/juju/juju/blob/725800953aaa29dbeda4f806097bf838e61644dd/worker/introspection/worker.go#L125

### Impact When combined with an attack of `JUJU_CONTEXT_ID`, any user on the local system with access to the default network namespace may connect to the `@/var/lib/juju/agents/unit-xxxx-yyyy/agent.socket` and perform actions that are normally reserved to a juju charm. ### Patches Patch: https://github.com/juju/juju/commit/2f2ec128ef5a8ca81fc86ae79cfcdbab0007c206 Patched in: - 3.5.4 - 3.4.6 - 3.3.7 - 3.1.10 - 2.9.51 ### Workarounds No workarounds available. ### References [GHSA-mh98-763h-m9v4](https://github.com/juju/juju/security/advisories/GHSA-mh98-763h-m9v4) https://github.com/juju/juju/blob/725800953aaa29dbeda4f806097bf838e61644dd/worker/uniter/paths.go#L222

Authd PAM module up to version 0.3.4 can allow broker-managed users to impersonate any other user managed by the same broker and perform any PAM operation with it, including authenticating as them. This is possible using tools such as `su`, `sudo` or `ssh` (and potentially others) that, so far, do not ensure that the PAM user at the end of the transaction is matching the one who initiated the transaction. Authd 0.3.5 fixes this by not allowing changing the user unless it was never set before in the PAM stack. `su` version that will include https://github.com/util-linux/util-linux/pull/3206 will not be affected `ssh` version that will include https://github.com/openssh/openssh-portable/pull/521 will not be affected `sudo` version that will include https://github.com/sudo-project/sudo/pull/412 will not be affected `login` not affected `passwd` not affected <details> <summary>Old report</summary> ### Summary An user can access as another user using its own credentials ### Details ...

`JUJU_CONTEXT_ID` is the authentication measure on the unit hook tool abstract domain socket. It looks like `JUJU_CONTEXT_ID=appname/0-update-status-6073989428498739633`. This value looks fairly unpredictable, but due to the random source used, it is highly predictable. `JUJU_CONTEXT_ID` has the following components: - the application name - the unit number - the hook being currently run - a uint63 decimal number On a system the application name and unit number can be deduced by reading the structure of the filesystem. The current hook being run is not easily deduce-able, but is a limited set of possible values, so one could try them all. Finally the random number, this is generated from a non cryptographically secure random source. Specifically the random number generator built into the go standard library, using the current unix time in seconds (at startup) as the seed. There is no rate limiting on the abstract domain socket, the only limiting factor is time (window of time the h...

For years, securing a company’s systems was synonymous with securing its “perimeter.” There was what was safe “inside” and the unsafe outside world. We built sturdy firewalls and deployed sophisticated detection systems, confident that keeping the barbarians outside the walls kept our data and systems safe. The problem is that we no longer operate within the confines of physical on-prem

San Francisco, United States / California, 3rd October 2024, CyberNewsWire

Singapore, Singapore, 3rd October 2024, CyberNewsWire