Dear Emmanuel Lecharny, Congratulations on the release.
Thank you for following the ASF announcement release requirements. This announcement does not contain a link where readers can download the release. I assume these would include e.g. https://mina.apache.org/mina-project/downloads_2_2.html The download pages need a bit of work. The artifacts must use the closer.lua script or use https://dlcdn.apache.org links. The KEYS link is correct, but the checksums and signatures must also use https://downloads.apache.org links and not dist/mina links. Warm regards, Craig > On Dec 24, 2024, at 11:39, Emmanuel Lecharny <elecha...@apache.org> wrote: > > The MINA project is pleased to announce the MINA 2.2.4, 2.1.10 and > 2.0.27 release. > > > **MINA** applications using unbounded deserialization may allow > **RCE** (see https://www.cve.org/CVERecord?id=CVE-2024-52046). > > Affected versions: > > - Apache MINA 2.0 through 2.0.26 > - Apache MINA 2.1 through 2.1.9 > - Apache MINA 2.2 through 2.2.3 > > Description: > > The *ObjectSerializationDecoder* in Apache **MINA** uses Java’s native > deserialization protocol to process > incoming serialized data but lacks the necessary security checks and > defenses. This vulnerability allows > attackers to exploit the deserialization process by sending specially > crafted malicious serialized data, > potentially leading to remote code execution (**RCE**) attacks. > > This issue affects **MINA** core versions 2.0.X, 2.1.X and 2.2.X, and > is fixed by the releases 2.0.27, 2.1.10 and 2.2.4. > > It's also important to note that an application using **MINA** core > library will only be affected if the *IoBuffer#getObject()* method is > called, and this specific method is potentially called when adding a > *ProtocolCodecFilter* instance using the > *ObjectSerializationCodecFactory* class in the filter chain. If your > application is specifically using those classes, you have to upgrade > to the latest version of **MINA** core library. > > **Upgrading will not be enough: you also need to explicitly allow the > classes the decoder will accept in the *ObjectSerializationDecoder* > instance, using one of the three new methods:** > > > > /** > * Accept class names where the supplied ClassNameMatcher matches for > * deserialization, unless they are otherwise rejected. > * > * @param classNameMatcher the matcher to use > */ > public void accept(ClassNameMatcher classNameMatcher) > > /** > * Accept class names that match the supplied pattern for > * deserialization, unless they are otherwise rejected. > * > * @param pattern standard Java regexp > */ > public void accept(Pattern pattern) > > /** > * Accept the wildcard specified classes for deserialization, > * unless they are otherwise rejected. > * > * @param patterns Wildcard file name patterns as defined by > * org.apache.commons.io.FilenameUtils#wildcardMatch(String, String) > */ > public void accept(String... patterns) > > > By default, the decoder will reject *all* classes that will be present > in the incoming data. > > > Note: The **FtpServer**, **SSHd** and **Vysper** sub-project are not > affected by this issue. > > -- > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 > elecha...@apache.org > > -- > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61 > elecha...@apache.org > > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com Craig L Russell c...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
