Apache Tomcat through versions 7.0.88, 8.0.52, 8.5.31 and 9.0.8 have defaults settings for the CORS filter that are insecure and enable 'supportsCredentials' for all origins.
Upstream announcement:
https://lists.apache.org/thread.html/fbfb713e4f8a4c0f81089b89450828011343593800cae3fb629192b1@%3Cannounce.tomcat.apache.org%3E
Upstream bug:
https://bz.apache.org/bugzilla/showbug.cgi?id=62343
Upstream Patches:
http://svn.apache.org/viewvc?view=rev&rev=1831726 / trunk/9.0 http://svn.apache.org/viewvc?view=rev&rev=1831728 / 8.5 http://svn.apache.org/viewvc?view=rev&rev=1831729 / 8.0 http://svn.apache.org/viewvc?view=rev&rev=1831730 / 7.0
External References:
http://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.9 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.32 http://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.0.53 http://tomcat.apache.org/security-7.html#FixedinApacheTomcat7.0.89
An issue was discovered in libjpeg 9a and 9d. The allocsarray function in jmemmgr.c allows remote attackers to cause a denial of service (divide-by-zero error) via a crafted file.
libexpat could allow a remote attacker to obtain sensitive information, caused by improper handling of XML external entity (XXE) declarations by the XMLExternalEntityParserCreate function. By using a specially crafted XML content, a remote attacker could exploit this vulnerability to obtain sensitive information, and use this information to launch further attacks against the affected system.
Accessibility. A privacy issue was addressed with improved private data redaction for log entries.
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 vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) .. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.
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 use of incorrectly resolved name vulnerability fixed in 7.83.1 might remove the wrong file when --no-clobber is used together with --remove-on-error.
Expat (aka libexpat) before 2.4.4 has a signed integer overflow in XMLGetBuffer, for configurations with a nonzero XMLCONTEXTBYTES.
A flaw was found in OpenSSL. The crehash script does not properly sanitize shell meta-characters to prevent command injection. Some operating systems distribute this script in a manner where it is automatically executed. This flaw allows an attacker to execute arbitrary commands with the privileges of the script on these operating systems.
expat (libexpat) is susceptible to a software flaw that causes process interruption. When processing a large number of prefixed XML attributes on a single tag can libexpat can terminate unexpectedly due to integer overflow. The highest threat from this vulnerability is to availability, confidentiality and integrity.
Expat (aka libexpat) is vulnerable to a denial of service, caused by a realloc misbehavior issue in the storeAtts function in xmlparse.c. By persuading a victim to open a specially-crafted XML content, a remote attacker could exploit this vulnerability to cause a the application to crash.
ecverify in kdc/kdcpreauthec.c in the Key Distribution Center (KDC) in MIT Kerberos 5 (aka krb5) before 1.18.4 and 1.19.x before 1.19.2 allows remote attackers to cause a NULL pointer dereference and daemon crash. This occurs because a return value is not properly managed in a certain situation.
A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.
libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the CURLOPTSSLCERT option (--cert with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like /tmp), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake.
A use-after-free flaw was found in the way curl handled TLS session data. The curl versions using the OpenSSL library as their TLS backend could use freed memory after TLS session renegotiation was performed by the OpenSSL library. A malicious TLS server could use this flaw to crash or, possibly, execute arbitrary code with the privileges of a client application using the curl library.
A heap-based buffer overflow was found in libxml2 when processing truncated UTF-8 input.
Reference: https://gitlab.gnome.org/GNOME/libxml2/-/issues/235
Upstream patch: https://gitlab.gnome.org/GNOME/libxml2/-/commit/bf22713507fe1fc3a2c4b525cf0a88c2dc87a3a2
A flaw was found in krb5. MIT Kerberos 5 allows unbounded recursion via an ASN.1-encoded Kerberos message because the lib/krb5/asn.1/asn1encode.c support for BER indefinite lengths lacks a recursion limit.
Perl. This issue was addressed with improved checks.
Perl before 5.30.3 has an integer overflow related to mishandling of a "PLregkind[OP(n)] == NOTHING" situation. A crafted regular expression could lead to malformed bytecode with a possibility of instruction injection.
cURL libcurl is vulnerable to a heap-based buffer overflow, caused by improper bounds checking by the tftpreceivepacket function. By sending specially-crafted request containing an OACK without the BLKSIZE option, a remote attacker could overflow a buffer and execute arbitrary code on the system.
A non-privileged user or program can put code and a config file in a known non-privileged path (under C:/usr/local/) that will make curl <= 7.65.1 automatically run the code (as an openssl "engine") on invocation. If that curl is invoked by a privileged user it can do anything it wants.
In SQLite through 3.29.0 whereLoopAddBtreeIndex in sqlite3.c can crash a browser or other application because of missing validation of a sqlitestat1 sz field aka a "severe division by zero in the query planner."
AMD. A buffer overflow issue was addressed with improved memory handling.
Impact
Netty currently just skips control chars when these are present at the beginning / end of the header name. We should better fail fast as these are not allowed by the spec and could lead to HTTP request smuggling.
Failing to do the validation might cause netty to "sanitize" header names before it forward these to another remote system when used as proxy. This remote system can't see the invalid usage anymore and so not do the validation itself.
An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signaturealgorithms extension (where it was present in the initial ClientHello), but includes a signaturealgorithmscert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).
Impact The content-length header is not correctly validated if the request only use a single Http2HeaderFrame with the endStream set to to true. This could lead to request smuggling if the request is proxied to a remote peer and translated to HTTP/1.1
This is a followup of https://github.com/netty/netty/security/advisories/GHSA-wm47-8v5p-wjpj which did miss to fix this one case.
Patches This was fixed as part of 4.1.61.Final
Workarounds Validation can be done by the user before proxy the request by validating the header.
Impact If a Content-Length header is present in the original HTTP/2 request, the field is not validated by Http2MultiplexHandler as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (HttpRequest, HttpContent, etc.) via Http2StreamFrameToHttpObjectCodec and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling.
In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked.
An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. A sample attack request looks like:
POST / HTTP/2 :authority:: externaldomain.com Content-Length: 4
asdfGET /evilRedirect HTTP/1.1 Host: internaldomain.com
Users are only affected if all of this is true: HTTP2MultiplexCodec or Http2FrameCodec is used Http2StreamFrameToHttpObjectCodec is used to convert to HTTP/1.1 objects These HTTP/1.1 objects are forwarded to another remote peer.
Patches This has been patched in 4.1.60.Final
Workarounds The user can do the validation by themselves by implementing a custom ChannelInboundHandler that is put in the ChannelPipeline behind Http2StreamFrameToHttpObjectCodec.
References Related change to workaround the problem: https://github.com/Netflix/zuul/pull/980
In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code.
An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.
External References:
https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7
Upstream patch:
https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb
CVE assignment:
http://seclists.org/oss-sec/2016/q4/602