A use-after-free exists in the Linux Kernel in tcnewtfilter that could allow a local attacker to gain privilege escalation. The exploit requires unprivileged user namespaces. We recommend upgrading past commit 04c2a47ffb13c29778e2a14e414ad4cb5a5db4b5
Summary
Log4j versions prior to 2.16.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache's Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.16.0, this behavior has been disabled by default.
Log4j version 2.15.0 contained an earlier fix for the vulnerability, but that patch did not disable attacker-controlled JNDI lookups in all situations. For more information, see the Updated advice for version 2.16.0 section of this advisory.
Impact
Logging untrusted or user controlled data with a vulnerable version of Log4J may result in Remote Code Execution (RCE) against your application. This includes untrusted data included in logged errors such as exception traces, authentication failures, and other unexpected vectors of user controlled input.
Affected versions
Any Log4J version prior to v2.15.0 is affected to this specific issue.
The v1 branch of Log4J which is considered End Of Life (EOL) is vulnerable to other RCE vectors so the recommendation is to still update to 2.16.0 where possible.
Security releases Additional backports of this fix have been made available in versions 2.3.1, 2.12.2, and 2.12.3
Affected packages Only the org.apache.logging.log4j:log4j-core package is directly affected by this vulnerability. The org.apache.logging.log4j:log4j-api should be kept at the same version as the org.apache.logging.log4j:log4j-core package to ensure compatability if in use.
Remediation Advice
Updated advice for version 2.16.0
The Apache Logging Services team provided updated mitigation advice upon the release of version 2.16.0, which disables JNDI by default and completely removes support for message lookups. Even in version 2.15.0, lookups used in layouts to provide specific pieces of context information will still recursively resolve, possibly triggering JNDI lookups. This problem is being tracked as CVE-2021-45046. More information is available on the GitHub Security Advisory for CVE-2021-45046.
Users who want to avoid attacker-controlled JNDI lookups but cannot upgrade to 2.16.0 must ensure that no such lookups resolve to attacker-provided data and ensure that the the JndiLookup class is not loaded.
Please note that Log4J v1 is End Of Life (EOL) and will not receive patches for this issue. Log4J v1 is also vulnerable to other RCE vectors and we recommend you migrate to Log4J 2.16.0 where possible.
A crafted request uri-path can cause modproxy to forward the request to an origin server choosen by the remote user. This issue affects Apache HTTP Server 2.4.48 and earlier.
An out-of-bounds (OOB) memory write flaw was found in preallocelemsandfreelist in kernel/bpf/stackmap.c in the bpf iin the Linux kernel. In this flaw, the multiplication to calculate the size could lead to an integer overflow, and this could allow a local attacker, with a special user privilege to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information.
Reference and upstream patch: https://github.com/torvalds/linux/commit/30e29a9a2bc6a4888335a6ede968b75cd329657a
A random memory access flaw was found in the Linux kernel's GPU i915 kernel driver functionality in the way a user may run malicious code on the GPU. This flaw allows a local user to crash the system or escalate their privileges on the system.
A use-after-free exists in drivers/tee/teeshm.c in the TEE subsystem in the Linux kernel through 5.15.11. This occurs because of a race condition in teeshmgetfromid during an attempt to free a shared memory object.
Impact What kind of vulnerability is it? Who is impacted?
The PGJDBC implementation of the java.sql.ResultRow.refreshRow() method is not performing escaping of column names so a malicious column name that contains a statement terminator, e.g. ;, could lead to SQL injection. This could lead to executing additional SQL commands as the application's JDBC user.
User applications that do not invoke the ResultSet.refreshRow() method are not impacted.
User application that do invoke that method are impacted if the underlying database that they are querying via their JDBC application may be under the control of an attacker. The attack requires the attacker to trick the user into executing SQL against a table name who's column names would contain the malicious SQL and subsequently invoke the refreshRow() method on the ResultSet.
For example:
sql CREATE TABLE refreshrowexample ( id int PRIMARY KEY, "1 FROM refreshrowexample; SELECT pgsleep(10); SELECT " int );
This example has a table with two columns. The name of the second column is crafted to contain a statement terminator followed by additional SQL. Invoking the ResultSet.refreshRow() on a ResultSet that queried this table, e.g. SELECT FROM refreshrow, would cause the additional SQL commands such as the SELECT pgsleep(10) invocation to be executed.
As the multi statement command would contain multiple results, it would not be possible for the attacker to get data directly out of this approach as the ResultSet.refreshRow() method would throw an exception. However, the attacker could execute any arbitrary SQL including inserting the data into another table that could then be read or any other DML / DDL statement.
Note that the application's JDBC user and the schema owner need not be the same. A JDBC application that executes as a privileged user querying database schemas owned by potentially malicious less-privileged users would be vulnerable. In that situation it may be possible for the malicious user to craft a schema that causes the application to execute commands as the privileged user.
Patches Has the problem been patched? What versions should users upgrade to?
Yes, versions 42.2.26, 42.3.7, and 42.4.1 have been released with a fix.
Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading?
Check that you are not using the ResultSet.refreshRow() method.
If you are, ensure that the code that executes that method does not connect to a database that is controlled by an unauthenticated or malicious user. If your application only connects to its own database with a fixed schema with no DDL permissions, then you will not be affected by this vulnerability as it requires a maliciously crafted schema.
pgjdbc is the offical PostgreSQL JDBC Driver. A security hole was found in the jdbc driver for postgresql database while doing security research. The system using the postgresql library will be attacked when attacker control the jdbc url or properties. pgjdbc instantiates plugin instances based on class names provided via authenticationPluginClassName, sslhostnameverifier, socketFactory, sslfactory, sslpasswordcallback connection properties. However, the driver did not verify if the class implements the expected interface before instantiating the class. This can lead to code execution loaded via arbitrary classes. Users using plugins are advised to upgrade. There are no known workarounds for this issue.
An IDOR (Insecure Direct Object Reference) vulnerability was found on Grafana Teams APIs. This flaw impacts the /teams/:teamId, /teams/:search, /teams/:teamId/members API endpoints and may allow an authenticated attacker to view unintended data by querying for the specific team ID or search for teams and see the total number of available teams (including for those teams where the user does not have access to).
GitHub security advisory: https://github.com/grafana/grafana/security/advisories/GHSA-63g3-9jq3-mccv
Grafana blog post: https://grafana.com/blog/2022/02/08/grafana-7.5.15-and-8.3.5-released-with-moderate-severity-security-fixes/
A Cross-site request forgery (CSRF) vulnerability was found in Grafana. This flaw allows anonymous attackers to elevate their privileges by mounting cross-origin attacks against authenticated high-privilege Grafana users (for example, editors or admins). An attacker can exploit this vulnerability for privilege escalation by tricking an authenticated user into inviting the attacker as a new user with high privileges.
A Cross-site scripting (XSS) vulnerability was found in the way Grafana handles data sources. This flaw allows an attacker to serve HTML content through the Grafana data source or plugin proxy and trick a user to visit this HTML page using a specially crafted link and execute a Cross-site scripting (XSS) attack. Should an existing data source connected to Grafana be compromised, it could be used to inappropriately gain access to other data sources connected to the same Grafana org.
A flaw was found in urijs due to the fix of CVE-2021-3647 not considering case-sensitive protocol schemes in the URL. This issue allows attackers to bypass the patch.
A flaw was found in the SQL plugin shipped with Cyrus SASL. The vulnerability occurs due to failure to properly escape SQL input and leads to an improper input validation vulnerability. This flaw allows an attacker to execute arbitrary SQL commands and the ability to change the passwords for other accounts allowing escalation of privileges.
An out-of-bounds read/write vulnerability was found in the modsed module of httpd. This flaw allows an attacker to overwrite the memory of an httpd instance that is using modsed with data provided by the attacker.
A carefully crafted request body can cause a read to a random memory area which could cause the process to crash. This issue affects Apache HTTP Server 2.4.52 and earlier.
A flaw was found in httpd. The inbound connection is not closed when it fails to discard the request body, which may expose the server to HTTP request smuggling.
A flaw was found in httpd, where it incorrectly limits the value of the LimitXMLRequestBody option. This issue can lead to an integer overflow and later causes an out-of-bounds write.
A carefully crafted request uri-path can cause modproxyuwsgi to read above the allocated memory and crash (DoS). This issue affects Apache HTTP Server versions 2.4.30 to 2.4.48 (inclusive).
A flaw was found in golang encoding/xml. When calling Decoder, Skip while parsing a deeply nested XML document, a panic can occur due to stack exhaustion and allows an attacker to impact system availability.
An out of bounds read vulnerability was found in debug/macho of the Go standard library. When using the debug/macho standard library (stdlib) and malformed binaries are parsed using Open or OpenFat, it can cause golang to attempt to read outside of a slice (array) causing a panic when calling ImportedSymbols. An attacker can use this vulnerability to craft a file which causes an application using this library to crash resulting in a denial of service.
A vulnerability was found in archive/zip of the Go standard library. Applications written in Go where Reader.Open (the API implementing io/fs.FS introduced in Go 1.16) can panic when parsing a crafted ZIP archive containing completely invalid names or an empty filename argument.
A flaw was found in golang. This vulnerability can only be triggered when invoking functions from vulnerable WASM (WebAssembly) Modules. Go can be compiled to WASM. If the product or service doesn't use WASM functions, it is not affected, although it uses golang.
A flaw was found in CORS Filter feature from the go-restful package. When a user inputs a domain which is in AllowedDomains, all domains starting with the same pattern are accepted. This issue could allow an attacker to break the CORS policy by allowing any page to make requests and retrieve data on behalf of users.
A security vulnerability was found in zlib. The flaw triggered a heap-based buffer in inflate in the inflate.c function via a large gzip header extra field. This flaw is only applicable in the call inflateGetHeader.
A flaw was found in OpenSSL. The issue in CVE-2022-1292 did not find other places in the crehash script where it possibly passed the file names of certificates being hashed to a command executed through the shell. Some operating systems distribute this script in a manner where it is automatically executed. On these operating systems, this flaw allows an attacker to execute arbitrary commands with the privileges of the script.
Impact
using string-to-date parsing in moment (more specifically rfc2822 parsing, which is tried by default) has quadratic (N^2) complexity on specific inputs noticeable slowdown is observed with inputs above 10k characters users who pass user-provided strings without sanity length checks to moment constructor are vulnerable to (Re)DoS attacks
Patches The problem is patched in 2.29.4, the patch can be applied to all affected versions with minimal tweaking.
Workarounds In general, given the proliferation of ReDoS attacks, it makes sense to limit the length of the user input to something sane, like 200 characters or less. I haven't seen legitimate cases of date-time strings longer than that, so all moment users who do pass a user-originating string to constructor are encouraged to apply such a rudimentary filter, that would help with this but also most future ReDoS vulnerabilities.
References There is an excellent writeup of the issue here: https://github.com/moment/moment/pull/6015#issuecomment-1152961973=
Details The issue is rooted in the code that removes legacy comments (stuff inside parenthesis) from strings during rfc2822 parsing. moment("(".repeat(500000)) will take a few minutes to process, which is unacceptable.
XStream is an open source java library to serialize objects to XML and back again. Versions prior to 1.4.19 may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. XStream 1.4.19 monitors and accumulates the time it takes to add elements to collections and throws an exception if a set threshold is exceeded. Users are advised to upgrade as soon as possible. Users unable to upgrade may set the NOREFERENCE mode to prevent recursion. See GHSA-rmr5-cpv2-vgjf for further details on a workaround if an upgrade is not possible.
A use-after-free flaw was found in the Expat package, caused by destruction of a shared DTD in XMLExternalEntityParserCreate in out-of-memory situations. This may lead to availability disruptions.
A flaw in XML parsing could have led to a use-after-free causing a potentially exploitable crash.In official releases of Firefox this vulnerability is mitigated by wasm sandboxing; versions managed by Linux distributions may have other settings.
A flaw was found in the libxml2 library in functions used to manipulate the xmlBuf and the xmlBuffer types. A substantial input causes values to calculate buffer sizes to overflow, resulting in an out-of-bounds write.