Description
When using the sandbox with a SourcePolicyInterface, Twig does not always apply the sandbox restriction that forbids non-Closure callbacks for callback-accepting filters.
The issue affects the sort, filter, map, and reduce filters.
In the affected versions, the runtime check that rejects non-Closure callbacks in sandbox mode does not use the current template Source. As a result, when the sandbox is enabled through a source policy instead of being enabled globally, Twig can incorrectly treat the current execution as non-sandboxed for these callback checks.
This can allow user-controlled templates to pass arbitrary PHP callables to callback-accepting filters even though the template is being sandboxed through a source policy.
The issue happens when all these conditions are met:
- The sandbox is not enabled globally; - A SourcePolicyInterface enables the sandbox for the rendered template; - The template uses one of the sort, filter, map, or reduce filters; - The callback is not a Closure.
Resolution
The patch makes callback sandbox checks source-aware by propagating the current template Source to callback-accepting filters and using it when deciding whether sandbox restrictions apply.
Credits
We would like to thank XavLim and Wade Sparks for reporting the issue and Fabien Potencier for fixing the issue.
rsync 3.1.0 < 3.5.0 Access Control Bypass via DNS Resolution Failure
rsync before 3.5.0 contains an algorithmic complexity vulnerability in the hashsearch() function that allows a remote attacker to cause a denial of service by delivering a carefully constructed file list. A sender can exploit the quadratic-time worst-case behavior in hash lookups to exhaust receiver CPU resources with a modest number of crafted entries, causing a sustained denial of service.
rsync 3.0.0 < 3.5.0 Out-of-Bounds Write via FLAGHLINKED Handling
rsync 2.3.3 < 3.5.0 Path Traversal via --partial-dir/--backup-dir Symlink
rsync 3.0.1 < 3.5.0 Heap Out-of-Bounds Write via readargs()
rsync before 3.5.0 contains a path confinement bypass vulnerability that allows remote clients to escape the intended inner-module root confinement by constructing paths that resolve outside the chroot boundary when the module root contains a /./ boundary marker. Attackers can exploit improper handling of the /./ notation or forge delta-basis transfers referencing xname paths that cross the /./ boundary to gain unauthorized read or write access to files outside the module's subtree.
rsync before 3.5.0 contains a time-of-check to time-of-use (TOCTOU) race condition vulnerability in the rrsync restricted shell wrapper that allows authenticated clients to escape enforced directory restrictions by substituting a symlink for a path component after validation but before transfer processing. Attackers can additionally leverage unrestricted flags such as --copy-unsafe-links, -D, and --log-file through rrsync to read or write files outside the permitted directory subtree.
rsync before 3.5.0 contains multiple command and argument injection vulnerabilities that allow attackers to execute arbitrary commands by supplying malicious input through several code paths, including the RSYNCCONNECTPROG environment variable, daemon hooks, the rsync-ssl wrapper, and remote-shell command newline injection. Attackers can inject shell metacharacters or newline characters into unsanitized user-supplied values such as hostnames and hostspecs to execute arbitrary commands under the privileges of the rsync process or the invoking user.
rsync before 3.5.0 contains a path traversal vulnerability that allows a malicious sender to write files outside the intended destination directory tree by crafting relative paths with symlink components in --relative mode. The makepath() function follows symlinks pointing outside the destination tree while creating intermediate directories without verifying that created paths remain within the destination boundary, enabling arbitrary file writes on the receiver's filesystem.
A flaw was found in OpenSSH. This vulnerability, a heap out-of-bounds read, occurs during the cleanup of GSSAPI (Generic Security Service Application Programming Interface) indicators when a trailing NULL termination is missing in the auth-indicators array. A remote attacker, under specific configurations involving GSSAPI authentication and a Kerberos environment, could exploit this to cause the SSH authentication path to crash or abort. This leads to a denial of service (DoS), impacting the availability of the SSH service.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow low-privileged users to query arbitrary indices and read sensitive data due to missing authorization.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow an authenticated attacker to send unauthorized requests from the system due to server-side request forgery. This could be used to enumerate network resources or to support further attacks.
BM API Connect Analytics (analytics-v2-director) versions in the v10.0.8 release stream are vulnerable to a Regular Expression Denial of Service (ReDoS) attack and to improper neutralisation of wildcard query operators.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to read arbitrary files on the server due to external control of a file name or path.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to probe internal network services due to improper validation of a user-supplied URL.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to obtain sensitive information due to the use of a hard-coded cryptographic key.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to server-side request forgery.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to obtain sensitive information due to XML external entity (XXE) injection.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to an insecure direct object reference.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote attacker to enumerate usernames due to observable differences in response behavior.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to the insertion of sensitive information into log files.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a local attacker to obtain sensitive information due to improper use of cryptography. The encryption applied to stored data is not implemented with sufficient strength, which weakens its protection.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information belonging to other tenants due to an injection vulnerability. Input used to build a data query is not properly neutralized, which could allow the query to return data the user is not permitted to see.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to broken object-level authorization.
IBM API Connect 12.1.0.0 through 12.1.1.2 could allow a remote authenticated attacker to obtain sensitive information due to a server-side request forgery vulnerability.
Summary Several Net::IMAP commands accept a raw string argument that is sent to the server without validation or escaping. If this string is derived from user-controlled input, it may contain contain CRLF sequences, which an attacker can use to inject arbitrary IMAP commands.
Details
Net::IMAP's generic argument handling, used by most command arguments, interprets string arguments as an IMAP astring. Depending on the string contents and the connection's UTF-8 support, this encodes strings as either a atom, quoted, or literal. These are safe from command or argument injection.
But the following commands transform specific String arguments to Net::IMAP::RawData, which bypasses normal argument validation and encoding and prints the string directly to the socket: #uidsearch, #search when criteria is a String, it is sent raw #uidfetch, #fetch when attr is a String, it is sent raw when attr is an Array, each String in attr is sent raw #uidstore, #store when attr is a String, it is sent raw #setquota: limit is interpolated with #tos and that string is sent raw
Because these string arguments are sent without any neutralization, they serve as a direct vector for command splitting. Any user controlled data interpolated into these strings can be used to break out of the intended command context.
Using "raw data" arguments for #uidstore, #store, and #setquota I both inappropriate and unnecessary. Net::IMAP's generic argument handling is sufficient to safely validate and encode their arguments. Users of the library probably do not expect arguments to these commands to be sent raw and might not be wary of passing unvalidated input.
The API for search criteria and fetch attributes is intentionally low-level and "close to the wire". It allows developers to use some IMAP extensions without requiring explicit support from the library and allows developers to use complex IMAP grammar without complex argument translation. Even so, basic validation is appropriate and could neutralize command injection.
Although this was explicitly documented for search criteria, it was insufficiently documented for fetch attr. So developers may not have realized that the attr argument to #fetch and #uidfetch is sent as "raw data".
Impact
If a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.
The SEARCH, STORE, and FETCH commands, and their UID variants are some of the most commonly used features of the library. Applications that build search queries or fetch attributes dynamically based on user input (e.g., mail clients or archival tools) may be at significant risk.
Expected use of Net::IMAP#setquota is much more limited: SETQUOTA is often only usable by users with special administrative privileges. Depending on the server, quota administration might be managed through server configuration rather than via the IMAP protocol SETQUOTA command. It is expected to be uncommonly used in system administration scripts or in interactive sessions, it should be completely controlled by trusted users, and should only use trusted inputs. Calling #setquota with untrusted user input is expected to be a very uncommon use case. Please note however this might be combined with other attacks, for example CSRF, which provide unauthorized access to trusted inputs, and may specifically target users or scripts with administrator privileges.
Mitigation - Update to a patched version of net-imap which: - validates that Net::IMAP::RawData is composed of well-formed IMAP text, literal, and literal8 values, with no unescaped NULL, CR, or LF bytes. - does not use Net::IMAP::RawData for #store, #uidstore, or #setquota. - Prefer to send search criteria as an array of key value pairs. Avoid sending it as an interpolated string. - If an immediate upgrade is not possible: - String inputs to search criteria and fetch attributes can be validated against command injection by checking for \r and \n characters. - Hard-coding the store attr argument is often appropriate. Alternatively, user controlled inputs can be restricted to a small enumerated list which is valid for the calling application. - Use Kernel#Integer to coerce and validate user controlled inputs to #setquota limit.
DOMPurify is a DOM-only cross-site scripting sanitizer for HTML, MathML, and SVG. Prior to 3.4.7, DOMPurify INPLACE sanitization could skip shadow contents attached to an element inside <template>.content, allowing attacker-controlled markup such as event handlers, JavaScript URLs, or scripts to survive and execute when an application cloned and inserted the sanitized template. This issue is fixed in version 3.4.7.
Insecure XML parser configuration in Apache CXF's WS-Transfer module may allow attackers to perform XXE attacks. Users are recommended to upgrade to versions 4.2.1, 4.1.6 or 3.6.11, which fix this issue.