#git

Missing Authentication for Critical Function in GitHub repository answerdev/answer prior to v1.1.3.

Missing Authentication for Critical Function in GitHub repository answerdev/answer prior to v1.1.3.

After leaving many questions unanswered, a new post mortem from Microsoft explains the series of slip-ups that allowed attackers to steal and abuse a valuable cryptographic key.

WireMock is a tool for mocking HTTP services. WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. Until WireMock Webhooks Extension 3.0.0-beta-15, the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passing a token, discovered using another exploit, via authentication headers. This issue has been addressed in versions 2.35.1 and 3.0.3 of wiremock. Wiremock studio h...

### Impact WireMock can be configured to only permit proxying (and therefore recording) to certain addresses. This is achieved via a list of allowed address rules and a list of denied address rules, where the allowed list is evaluated first. [Documentation](https://wiremock.org/docs/configuration/#preventing-proxying-to-and-recording-from-specific-target-addresses). Until WireMock Webhooks Extension [3.0.0-beta-15](https://github.com/wiremock/wiremock/releases/tag/3.0.0-beta-15), the filtering of target addresses from the proxy mode DID NOT work for Webhooks, so the users were potentially vulnerable regardless of the `limitProxyTargets` settings. Via the WireMock webhooks configuration, POST requests from a webhook might be forwarded to an arbitrary service reachable from WireMock’s instance. For example, If someone is running the WireMock docker Container inside a private cluster, they can trigger internal POST requests against unsecured APIs or even against secure ones by passin...

**Component**: Cosmovisor **Criticality**: Medium **Affected Versions**: Cosmovisor < v1.0.0 (distributed with Cosmos-SDK < 0.46) **Affected Users**: Validators and Node operators utilizing unsupported versions of Cosmovisor **Impact**: DOS, potential RCE on node depending on configuration An issue has been identified on unsupported versions of Cosmovisor which may result in a Denial of Service or Remote Code Execution path depending on configuration for a node or validator using the vulnerable version to manage their node. If a validator is utilizing an affected version of Cosmovisor with `DAEMON_ALLOW_DOWNLOAD_BINARIES` set to true, a non-default configuration, it may be possible for an attacker to trigger a Remote Code Execution path as well on the host. In this configuration it is recommended to immediately stop use of the `DAEMON_ALLOW_DOWNLOAD_BINARIES` feature, and then proceed with an upgrade of Cosmovisor. It is recommended that all validators utilizing unsupported versio...

In pf packet processing with a 'scrub fragment reassemble' rule, a packet containing multiple IPv6 fragment headers would be reassembled, and then immediately processed. That is, a packet with multiple fragment extension headers would not be recognized as the correct ultimate payload. Instead a packet with multiple IPv6 fragment headers would unexpectedly be interpreted as a fragmented packet, rather than as whatever the real payload is. As a result, IPv6 fragments may bypass pf firewall rules written on the assumption all fragments have been reassembled and, as a result, be forwarded or processed by the host.

### Impact Apps that are launched as command line executables are impacted. E.g. if your app exposes itself in the path as `myapp --help` Specifically this issue can only be exploited if the following conditions are met: * Your app is launched with an attacker-controlled working directory * The attacker has the ability to write files to that working directory This makes the risk quite low, in fact normally issues of this kind are considered outside of our threat model as similar to Chromium we exclude [Physically Local Attacks](https://github.com/electron/electron/security/advisories/GHSA-7x97-j373-85x5#:~:text=Physically%20Local%20Attacks) but given the ability for this issue to bypass certain protections like ASAR Integrity it is being treated with higher importance. Please bear this in mind when reporting similar issues in the future. ### Workarounds There are no app side workarounds, you must update to a patched version of Electron. ### Fixed Versions * `26.0.0-beta.13` * `25...

### Impact A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. Details about this bug will be released within 4-8 weeks, as per our official [vulnerability disclosure policy](https://geth.ethereum.org/docs/developers/geth-developer/disclosures). ### Patches The fix is included in geth version `1.12.1-stable`, i.e, `1.12.2-unstable` and onwards. ### Workarounds No known workarounds. ### Credits This bug was reported by Patrick McHardy and reported via [bounty@ethereum.org](mailto:bounty@ethereum.org). ### References

go-ethereum (geth) is a golang execution layer implementation of the Ethereum protocol. A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. The fix is included in geth version `1.12.1-stable`, i.e, `1.12.2-unstable` and onwards. Users are advised to upgrade. There are no known workarounds for this vulnerability.