Summary Enabled but unsecured management endpoints are susceptible to drive-by localhost attacks. While not typical of a production application, these attacks may have more impact on a development environment where such endpoints may be flipped on without much thought.

Details A malicious/compromised website can make HTTP requests to localhost. Normally, such requests would trigger a CORS preflight check which would prevent the request; however, some requests are "simple" and do not require a preflight check. These endpoints, if enabled and not secured, are vulnerable to being triggered.

Impact Production environments typically disable unused endpoints and secure/restrict access to needed endpoints. A more likely victim is the developer in their local development host, who has enabled endpoints without security for the sake of easing development.

OpenDDS is an open source C++ implementation of the Object Management Group (OMG) Data Distribution Service (DDS). OpenDDS crashes while parsing a malformed PIDPROPERTYLIST in a DATA submessage during participant discovery. Attackers can remotely crash OpenDDS processes by sending a DATA submessage containing the malformed parameter to the known multicast port. This issue has been addressed in version 3.25. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Vulnerability

Micronaut's HTTP client is vulnerable to "HTTP Request Header Injection" due to not validating request headers passed to the client.

Example of vulnerable code:

java @Controller("/hello") public class HelloController {

@Inject @Client("/") RxHttpClient client;

@Get("/external-exploit") @Produces(MediaType.TEXTPLAIN) public String externalExploit(@QueryValue("header-value") String headerValue) { return client.toBlocking().retrieve( HttpRequest.GET("/hello") .header("Test", headerValue) ); } }

In the above case a query value received from a user is passed as a header value to the client. Since the client doesn't validate the header value the request headers and body have the potential to be manipulated.

For example, a user that supplies the following payload, can force the client to make multiple attacker-controlled HTTP requests.

java List<String> headerData = List.of( "Connection: Keep-Alive", // This keeps the connection open so another request can be stuffed in. "", "", "POST /hello/super-secret HTTP/1.1", "Host: 127.0.0.1", "Content-Length: 31", "", "{\"new\":\"json\",\"content\":\"here\"}", "", "" ); String headerValue = "H\r\n" + String.join("\r\n", headerData);; URI theURI = UriBuilder .of("/hello/external-exploit") .queryParam("header-value", headerValue) // Automatically URL encodes data .build(); HttpRequest<String> request = HttpRequest.GET(theURI); String body = client.toBlocking().retrieve(request);

Note that using @HeaderValue instead of @QueryValue is not vulnerable since Micronaut's HTTP server does validate the headers passed to the server, so the exploit can only be triggered by using user data that is not an HTTP header (query values, form data etc.).

Impact

The attacker is able to control the entirety of the HTTP body for their custom requests. As such, this vulnerability enables attackers to perform a variant of Server Side Request Forgery.

Patches

The problem has been patched in the micronaut-http-client versions 1.2.11 and 1.3.2 and above.

Workarounds

Do not pass user data directly received from HTTP request parameters as headers in the HTTP client.

References

Fix commits - https://github.com/micronaut-projects/micronaut-core/commit/9d1eff5c8df1d6cda1fe00ef046729b2a6abe7f1 - https://github.com/micronaut-projects/micronaut-core/commit/6deb60b75517f80c57b42d935f07955c773b766d - https://github.com/micronaut-projects/micronaut-core/commit/bc855e439c4a5ced3d83195bb59d0679cbd95add

For more information

If you have any questions or comments about this advisory:

Open an issue in micronaut-core Email us at info@micronaut.io

Credit

Originally reported by @JLLeitschuh

In JsonBeanPropertyBinder::expandArrayToThreshold in io.micronaut:micronaut-json-core before Micronaut 4 4.10.16 and in Micronaut 3 before 3.10.5 does not correctly handle descending array index order during form-urlencoded body binding, which allows remote attackers to cause a denial of service (non-terminating loop, CPU exhaustion, and OutOfMemoryError) via crafted indexed form parameters (e.g., authors[1].name followed by authors[0].name).

Example

With such an application

java package dosform;

import io.micronaut.http.HttpResponse; import io.micronaut.http.MediaType; import io.micronaut.http.annotation.Body; import io.micronaut.http.annotation.Consumes; import io.micronaut.http.annotation.Controller; import io.micronaut.http.annotation.Get; import io.micronaut.http.annotation.Post; import io.micronaut.http.annotation.Produces;

import java.net.URI;

@Controller class HomeController {

@Produces(MediaType.TEXTHTML) @Get String index() { return """ <!DOCTYPE html> <html> <head> <title></title> </head> <body> <form action="/submit" method="post"> <label for="firstAuthor">Fist Author</label> <input id="firstAuthor" name="authors[0].name" type="text"/>

<label for="secondAuthor">Second Author</label> <input id="secondAuthor" name="authors[1].name" type="text"/> <label for="thirdAuthor">Third Author</label> <input id="thirdAuthor" name="authors[2].name" type="text"/>

<button type="submit">Submit</button> </form> </body> </html> """; }

@Consumes(MediaType.APPLICATIONFORMURLENCODED) @Post("/submit") HttpResponse<?> submit(@Body Book book) { return HttpResponse.seeOther(URI.create("/")); } } package dosform;

import io.micronaut.core.annotation.Introspected;

import java.util.Objects;

@Introspected public class Author { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; }

@Override public final boolean equals(Object o) { if (!(o instanceof Author)) return false;

Author author = (Author) o; return Objects.equals(name, author.name); }

@Override public int hashCode() { return Objects.hashCode(name); }

@Override public String toString() { return "Author{" + "name='" + name + '\'' + '}'; } } package dosform;

import io.micronaut.core.annotation.Introspected;

import java.util.List; import java.util.Objects;

@Introspected public class Book { private List<Author> authors; public List<Author> getAuthors() { return authors; } public void setAuthors(List<Author> authors) { this.authors = authors; }

@Override public final boolean equals(Object o) { if (!(o instanceof Book)) return false;

Book book = (Book) o; return Objects.equals(authors, book.authors); }

@Override public int hashCode() { return Objects.hashCode(authors); }

@Override public String toString() { return "Book{" + "authors=" + authors + '}'; } }

Sending curl -v -X POST 'http://127.0.0.1:8080/submit' -H 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'authors[1].name=RobertGalbraith' --data-urlencode 'authors[0].name=JKRowling' causes sustained CPU usage and unbounded memory growth (eventually OutOfMemoryError).

Patches For Micronaut 4, the problem has been patched in micronaut-core, dependencies with group id io.micronaut, since 4.10.16.

For Micronaut 3, the problem has been patched since 3.10.5

Users upgrade to the latest version of the framework.

Workarounds There is no way for users to fix or remediate the vulnerability without upgrading.

References PR Fix: https://github.com/micronaut-projects/micronaut-core/pull/12410

DefaultHtmlErrorResponseBodyProvider in io.micronaut:micronaut-http-server since 4.7.0 and until 4.10.7 used an unbounded ConcurrentHashMap cache with no eviction policy. If the application throws an exception whose message may be influenced by an attacker, for example, including request query value parameters, this could be used by remote attackers to cause a denial of service (unbounded heap growth and OutOfMemoryError).

Fixed via: https://github.com/micronaut-projects/micronaut-core/commit/1e2ba2c14386af3d47751732d02053a72b0b49b3

An integer overflow in the RTPS protocol implementation of OpenDDS DDS before v3.33.0 allows attackers to cause a Denial of Service (DoS) via a crafted message.

An issue was discovered in OpenDDS commit b1c534032bb62ad4ae32609778de6b8d6c823a66, allows a local attacker to cause a denial of service and obtain sensitive information via the maxsamples parameter within the DataReaderQoS component.

Micronaut is a JVM-based, full stack Java framework designed for building JVM web applications with support for Java, Kotlin and the Groovy language. In affected versions sending an invalid Content Type header leads to memory leak in DefaultArgumentConversionContext as this type is erroneously used in static state. ### Impact Sending an invalid Content Type header leads to memory leak in DefaultArgumentConversionContext as this type is erroneously used in static state. ### Patches The problem is patched in Micronaut 3.2.7 and above. ### Workarounds The default content type binder can be replaced in an existing Micronaut application to mitigate the issue: java package example; import java.util.List; import io.micronaut.context.annotation.Replaces; import io.micronaut.core.convert.ConversionService; import io.micronaut.http.MediaType; import io.micronaut.http.bind.DefaultRequestBinderRegistry; import io.micronaut.http.bind.binders.RequestArgumentBinder; import jakarta.inject.Singleton; @Singleton @Replaces(DefaultRequestBinderRegistry.class) class FixedRequestBinderRegistry extends DefaultRequestBinderRegistry { public FixedRequestBinderRegistry(ConversionService conversionService, List<RequestArgumentBinder> binders) { super(conversionService, binders); } @Override protected void registerDefaultConverters(ConversionService<?> conversionService) { super.registerDefaultConverters(conversionService); conversionService.addConverter(CharSequence.class, MediaType.class, charSequence -> { try { return MediaType.of(charSequence); } catch (IllegalArgumentException e) { return null; } }); } } ### References Commit that introduced the vulnerability https://github.com/micronaut-projects/micronaut-core/commit/b8ec32c311689667c69ae7d9f9c3b3a8abc96fe3 ### For more information If you have any questions or comments about this advisory: Open an issue in Micronaut Core Email us at info@micronaut.io

OCI OpenDDS versions prior to 3.18.1 do not handle a length parameter consistent with the actual length of the associated data, which may allow an attacker to remotely execute arbitrary code.

OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition.

OCI OpenDDS versions prior to 3.18.1 are vulnerable when an attacker sends a specially crafted packet to flood target devices with unwanted traffic, which may result in a denial-of-service condition and information exposure.

OpenDDS is an open source C++ implementation of the Object Management Group (OMG) Data Distribution Service (DDS). OpenDDS applications that are exposed to untrusted RTPS network traffic may crash when parsing badly-formed input. This issue has been patched in version 3.23.1.

Summary

IdTokenClaimsValidator skips aud claim validation if token is issued by same identity issuer/provider.

Details

See https://github.com/micronaut-projects/micronaut-security/blob/master/security-oauth2/src/main/java/io/micronaut/security/oauth2/client/IdTokenClaimsValidator.java#L202

This logic violates point 3 of https://openid.net/specs/openid-connect-core-10.html#IDTokenValidation.

Workaround exists by setting micronaut.security.token.jwt.claims-validators.audience with valid values. micronaut.security.token.jwt.claims-validators.openid-idtoken can be kept as default on.

PoC

Should probably be:

java return issuer.equalsIgnoreCase(iss) && audiences.contains(clientId) && validateAzp(claims, clientId, audiences);

Impact

Any OIDC setup using Micronaut where multiple OIDC applications exists for the same issuer but token auth are not meant to be shared.

Mitigation

Please upgrade to a patched micronaut-security-oauth2 release as soon as possible.

If you cannot upgrade, for example, if you are still using Micronaut Framework 2, you can patch your application by creating a replacement of IdTokenClaimsValidatorReplacement

java package cve;

import io.micronaut.context.annotation.Replaces; import io.micronaut.context.annotation.Requires; import io.micronaut.core.annotation.NonNull; import io.micronaut.core.util.StringUtils; import io.micronaut.security.config.SecurityConfigurationProperties; import io.micronaut.security.oauth2.client.IdTokenClaimsValidator; import io.micronaut.security.oauth2.configuration.OauthClientConfiguration; import io.micronaut.security.oauth2.configuration.OpenIdClientConfiguration; import io.micronaut.security.token.jwt.generator.claims.JwtClaims; import io.micronaut.security.token.jwt.validator.JwtClaimsValidatorConfigurationProperties;

import javax.inject.Singleton; import java.net.URL; import java.util.Collection; import java.util.List; import java.util.Optional;

@Requires(property = SecurityConfigurationProperties.PREFIX + ".authentication", value = "idtoken") @Requires(property = JwtClaimsValidatorConfigurationProperties.PREFIX + ".openid-idtoken", notEquals = StringUtils.FALSE) @Singleton @Replaces(IdTokenClaimsValidator.class) public class IdTokenClaimsValidatorReplacement extends IdTokenClaimsValidator { public IdTokenClaimsValidatorReplacement(Collection<OauthClientConfiguration> oauthClientConfigurations) { super(oauthClientConfigurations); }

@Override protected boolean validateIssuerAudienceAndAzp(@NonNull JwtClaims claims, @NonNull String iss, @NonNull List<String> audiences, @NonNull String clientId, @NonNull OpenIdClientConfiguration openIdClientConfiguration) { if (openIdClientConfiguration.getIssuer().isPresent()) { Optional<URL> issuerOptional = openIdClientConfiguration.getIssuer(); if (issuerOptional.isPresent()) { String issuer = issuerOptional.get().toString(); return issuer.equalsIgnoreCase(iss) && audiences.contains(clientId) && validateAzp(claims, clientId, audiences); } } return false; } }

Micronaut is a JVM-based, full stack Java framework designed for building JVM applications. A path traversal vulnerability exists in versions prior to 2.5.9. With a basic configuration, it is possible to access any file from a filesystem, using "/../../" in the URL. This occurs because Micronaut does not restrict file access to configured paths. The vulnerability is patched in version 2.5.9. As a workaround, do not use in mapping, use only , which exposes only flat structure of a directory not allowing traversal. If using Linux, another workaround is to run micronaut in chroot.

In OpenDDS through 3.27, there is a segmentation fault for a DataWriter with a large value of resourcelimits.maxsamples. NOTE: the vendor's position is that the product is not designed to handle a maxsamples value that is too large for the amount of memory on the system.