#git

Meet the guy who taught US intelligence agencies how to make the most of the ad tech ecosystem, "the largest information-gathering enterprise ever conceived by man."

The German BSI has published its 2023 state of IT security report which names identity theft as the main threat for consumers.

Apache James prior to version 3.7.5 and 3.8.0 exposes a JMX endpoint on localhost subject to pre-authentication deserialisation of untrusted data. Given a deserialisation gadjet, this could be leveraged as part of an exploit chain that could result in privilege escalation. Note that by default JMX endpoint is only bound locally. We recommend users to:  - Upgrade to a non-vulnerable Apache James version  - Run Apache James isolated from other processes (docker - dedicated virtual machine)  - If possible turn off JMX

diffoscope before 256 allows directory traversal via an embedded filename in a GPG file. Contents of any file, such as ../.ssh/id_rsa, may be disclosed to an attacker. This occurs because the value of the gpg --use-embedded-filenames option is trusted.

Cross Site Request Forgery vulnerability in Bagisto before v.1.3.2 allows an attacker to execute arbitrary code via a crafted HTML script.

### Summary When using a modified client or the grpc interface directly, the `RegisterRepository` call accepts _both_ the repository owner / repo **and** the repo_id. Furthermore, these two are not checked for matching before registering webhooks and data in the database. ### Details It is possible for an attacker to register a repository with a invalid or differing upstream ID, which causes Minder to report the repository as registered, but not remediate any future changes which conflict with policy (because the webhooks for the repo do not match any known repository in the database). When attempting to register a repo with a different repo ID, the registered provider must have admin on the named repo, or a 404 error will result. Similarly, if the stored provider token does not have repo access, then the remediations will not apply successfully. Lastly, it appears that reconciliation actions do not execute against repos with this type of mismatch. ### PoC With an RPC like the...

### Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection. This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers. ### Patches Patched versions: * 9.4.54 * 10.0.20 * 11.0.20 * 12.0.6 ### Workarounds Disable HTTP/2 and HTTP/...

### Summary When using the built-in `extract32(b, start)`, if the `start` index provided has for side effect to update `b`, the byte array to extract `32` bytes from, it could be that some dirty memory is read and returned by `extract32`. ### Details Before evaluating `start`, the function `Extract32.build_IR` caches only: - The pointer in memory/storage to `b`: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L916-L918 - The length of `b`: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L920-L922 but do not cache the actual content of `b`. This means that if the evaluation of `start` changes `b`'s content and length, an outdated length will be used with the new content when extracting 32 bytes from `b`. ### PoC Calling the function `foo` of the following contract returns `b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789'` meaning that `extract32` accessed some dirty ...

### Problem User sessions in the @nfid/embed SDK with Ed25519 keys are vulnerable due to a compromised private key `535yc-uxytb-gfk7h-tny7p-vjkoe-i4krp-3qmcl-uqfgr-cpgej-yqtjq-rqe`. This exposes users to potential loss of funds on ledgers and unauthorized access to canisters they control. ### Solution Using version >1.0.1 of @dfinity/auth-client and @dfinity/identity packages, or @nfid/embed >0.10.1-alpha.6 includes patched versions of the issue. User sessions will be automatically fixed when they re-authenticate. ### Why this happened The DFINITY auth client library provides a function, `Ed25519KeyIdentity.generate`, for generating an Ed25519 key pair. This function includes an optional parameter to supply a 32-byte seed value, which will be utilized as the secret key. In cases where no seed value is provided, the library is expected to generate the secret key using secure randomness. However, a recent update of DFINITY libraries has compromised this assurance by employing an insec...

### Impact When SAML is used as the authentication mechanism, Central Dogma accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected. ### Patches The vulnerability has been patched in Central Dogma 0.64.3 by updating its Armeria dependency to 1.27.2. All users who use SAML as the authentication mechanism must upgrade from 0.64.3 or later. ### Workarounds A user can manually upgrade the `armeria-saml` module with the one from Armeria 1.27.2 or later, either by replacing the JAR in the Central Dogma distribution or by updating the dependency tree of the build. ### References [`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)