Security
Headlines
HeadlinesLatestCVEs

Tag

#ubuntu

Ubuntu Security Notice USN-6984-1

Ubuntu Security Notice 6984-1 - It was discovered that WebOb incorrectly handled certain URLs. An attacker could possibly use this issue to control a redirect or forward to another URL.

Packet Storm
Open in Source
#vulnerability#web#ubuntu
Ubuntu Security Notice USN-6983-1

Ubuntu Security Notice 6983-1 - Zeng Yunxiang discovered that FFmpeg incorrectly handled memory during video encoding. An attacker could possibly use this issue to perform a denial of service, or execute arbitrary code.

Ubuntu Security Notice USN-6982-1

Ubuntu Security Notice 6982-1 - It was discovered that Dovecot did not not properly have restrictions on the size of address headers. A remote attacker could possibly use this issue to cause denial of service.

GHSA-wh2w-39f4-rpv2: Hyperledger Indy's update process of a DID does not check who signs the request

# Name Updating a DID with a nym transaction will be written to the ledger if neither ROLE or VERKEY are being changed, regardless of sender. # Description A malicious DID with no particular role can ask an update for another DID (but cannot modify its verkey or role). This is bad because: 1. Any DID can write a nym transaction to the ledger (i.e., any DID can spam the ledger with nym transactions). 1. Any DID can change any other DID's alias. 1. The update transaction modifies the ledger metadata associated with a DID. # Expected vs Observed We expect that if a DID (with no role) wants to update another DID (not its own or one it is the endorser), then the nodes should refuse the request. We can see that requirements in the [Indy default auth_rules](https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md) in Section "Who is the owner" in the last point of "Endorser using". We observe that with a normal DID, we can update the field `from` for a random DID, ...

GHSA-4rr6-2v9v-wcpc: CRLF Injection in RestSharp's `RestRequest.AddHeader` method

### Summary The second argument to `RestRequest.AddHeader` (the header value) is vulnerable to CRLF injection. The same applies to `RestRequest.AddOrUpdateHeader` and `RestClient.AddDefaultHeader`. ### Details The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method: <https://github.com/restsharp/RestSharp/blob/777bf194ec2d14271e7807cc704e73ec18fcaf7e/src/RestSharp/Request/HttpRequestMessageExtensions.cs#L32> This method does not check for CRLF characters in the header value. This means that any headers from a `RestSharp.RequestHeaders` object are added to the request in such a way that they are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. ### PoC The below example code creates a console app that takes one command line variable "api key" and then makes a request to some status page with the provided key inse...

Ubuntu Security Notice USN-6972-4

Ubuntu Security Notice 6972-4 - Yuxuan Hu discovered that the Bluetooth RFCOMM protocol driver in the Linux Kernel contained a race condition, leading to a NULL pointer dereference. An attacker could possibly use this to cause a denial of service. It was discovered that a race condition existed in the Bluetooth subsystem in the Linux kernel, leading to a null pointer dereference vulnerability. A privileged local attacker could use this to possibly cause a denial of service.