You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The mvnd daemon utilizes a custom binary protocol on this socket to receive commands like executing Maven builds with a POM file or executing arbitrary Maven plugins.
An authentication mechanism to verify that the user, which started the mvnd daemon, executes these commands is not available.
Attack Scenarios
These scenarios are based on the guessability / determinability of the TCP port the mvnd daemon is running on. Due to the limited range of port numbers It is feasible to determine the actual port through port scanning or other means.
Attack Scenario 1 (Local)
In multi-user environments it is possible for a third-party with a separate user account on the same system to connect to a running mvnd daemon of a victim and to execute arbitrary commands via Maven plugins.
These arbitrary Maven commands a executed with the user permissions of the victim.
Limitations
The attacker must have access to the same system as the victim
The victim must be logged in on the system
The victim must have executed mvnd recently (within 3 hours by default)
Attack Scenario 2 (Web Browser)
The attacker is leading on the victim to visit a malicious website (e.g. through social engineering).
Web Browsers do not allow the usage of TCP sockets via JavaScript or WebAssembly, but restrict requests to the HTTP and WebSocket application protocols.
Because the mvnd daemon uses a custom binary protocol, a website is therefore not able to directly interact with the mvnd daemon.
If the victims web browser supports plugins like Java Applet, Flash, Silverlight or similar the website is able to to connect to a running mvnd daemon on the victims system and to execute arbitrary commands via Maven plugins.
These web browsers and web browser plugins usually regard high range ports (49152 - 65535) as secure and therefore do not limit access to them.
These arbitrary Maven commands a executed with the user permissions of the victim on the victims system, which might transcend network boundaries.
Limitations
The victim must use a vulnerable web browser, which supports Flash, Silverlight or similar
Modern / up-to-date web browsers usually do not support these plugins anymore and Windows disabled Flash on 27.10.2020
Further Notes
The mvnd daemon is not prone to HTML form protocol attacks, because it terminates the connection if an invalid data format is received
JavaScript / WebAssembly in web browser might gain the ability in the future to communicate via TCP sockets
Chromium already announced plans 08/2020 to introduce this as an experimental feature
Mitigation
The mvnd daemon should restrict the usage of the communication channel to the user, who started it.
Unix Domain Sockets (*nix / Windows 10 1909+)
By utilizing a Unix Domain Socket instead of a TCP socket the usage of the socket is restricted by file system permissions.
Cygwin / MSys Sockets (all systems)
These sockets emulate Unix Domain Sockets by storing a secret token along side the TCP port in a file on the file system.
The client must have file system access to this file to gain knowledge of this token and send it directly after connecting to the TCP socket of the server.
If the token is not sent or does not match the one known by the server, the server must terminate the connection.
Further Notes
Gradle mitigated this issue in a similar way to Cygwin / MSys sockets.
The text was updated successfully, but these errors were encountered:
Attack Vector
mvnd starts a daemon, which listens on a random TCP port
in the port range 49152 - 65535 (IANA Service Name and Transport Protocol Port Number Registry)1025 - 65535.The TCP socket is bound to localhost / 127.0.0.1 .
The mvnd daemon utilizes a custom binary protocol on this socket to receive commands like executing Maven builds with a POM file or executing arbitrary Maven plugins.
An authentication mechanism to verify that the user, which started the mvnd daemon, executes these commands is not available.
Attack Scenarios
These scenarios are based on the guessability / determinability of the TCP port the mvnd daemon is running on.
Due to the limited range of port numbersIt is feasible to determine the actual port through port scanning or other means.Attack Scenario 1 (Local)
In multi-user environments it is possible for a third-party with a separate user account on the same system to connect to a running mvnd daemon of a victim and to execute arbitrary commands via Maven plugins.
These arbitrary Maven commands a executed with the user permissions of the victim.
Limitations
Attack Scenario 2 (Web Browser)
The attacker is leading on the victim to visit a malicious website (e.g. through social engineering).
Web Browsers do not allow the usage of TCP sockets via JavaScript or WebAssembly, but restrict requests to the HTTP and WebSocket application protocols.
Because the mvnd daemon uses a custom binary protocol, a website is therefore not able to directly interact with the mvnd daemon.
If the victims web browser supports plugins like Java Applet, Flash, Silverlight or similar the website is able to to connect to a running mvnd daemon on the victims system and to execute arbitrary commands via Maven plugins.
These web browsers and web browser plugins usually regard high range ports (49152 - 65535) as secure and therefore do not limit access to them.
These arbitrary Maven commands a executed with the user permissions of the victim on the victims system, which might transcend network boundaries.
Limitations
Further Notes
Mitigation
The mvnd daemon should restrict the usage of the communication channel to the user, who started it.
Unix Domain Sockets (*nix / Windows 10 1909+)
By utilizing a Unix Domain Socket instead of a TCP socket the usage of the socket is restricted by file system permissions.
Cygwin / MSys Sockets (all systems)
These sockets emulate Unix Domain Sockets by storing a secret token along side the TCP port in a file on the file system.
The client must have file system access to this file to gain knowledge of this token and send it directly after connecting to the TCP socket of the server.
If the token is not sent or does not match the one known by the server, the server must terminate the connection.
Further Notes
Gradle mitigated this issue in a similar way to Cygwin / MSys sockets.
The text was updated successfully, but these errors were encountered: