User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
Wim,
Comments below.
On 25.09.2020 10:50, Wim Jongman wrote:
> I'll not outline the possible ways that I can think
of... :-P
Well, I don't think that this is a good approach. Although
we might give some kids a good idea to do low-level hacking,
what /we know is also known to the bad tech people. They are
the experts. I think we should name all the possible threats
that we can think of and see how likely it is that this will
happen. Even if it is just for fun. An open-source foundation
should have some information about this part of the security.
For example, I could imagine modifying the p2 available update
site preferences to include a URI that will contact some arbitrary
site and then include information in that URI that is extracted
from the computer, thereby transmitting that information to that
arbitrary site when updates are checked. The preference to do
automatic update checking could also be set. Or change the
workbench.xmi to add an open editor/browser for such a URI.
But again, I think the fundamental point is that if you have a
rogue process modifying things on your computer, all bets are
off. I.e., what if anything prevents the rogue process from
directly transmitting files to some arbitrary site, or simply
destroying your entire file system?
For instance, I am worried about a "Gerrit/Jenkins
Bomb". Anyone can push a change to Gerrit. This will start
the Jenkins build. I imagine it is not hard to add some code
to the pom that's gets executed during the build. This is a
bit mitigated on Github because new contributors cannot
start a build before the admin gives the ok. However, we
tend to add frequent contributors to the whitelist.
On the other hand, the CI builds are properly sandboxed
by our relengs so it might not be an issue at all.
Yes, this issue has come up before. I think this destructive
behavior has actually happened. But I could be wrong in my
recollection.
After the reply of Ed and Thomas, I was thinking about
how a jar could be doped with tampered classes and be signed
again. Suppose I have access to the build infra. Would that
be enough to sign the jars of any project that I choose to
build and replace it in a mirror?
Well, downloading it via p2 would notice that the checksum is
different, so you would find out before installing it; I think
that would be handled the same way as if the artifact were
actually corruptly downloaded (transmission error) and a different
mirror would be tried before failing completely.
There was a period when the download.eclipse.org server did
"transparent" mirroring where the update site information itself
could come from a mirror; that would be more problematic, but
that's not the case anymore.
Getting access to a build is not that hard.
No, nothing prevents me or any other committer from putting evil
hooks in our code and then signing and distributing it. In that
regard, nothing from the markplace is intrinsically safe, even if
signed...
If one has a rogue running process that can write
arbitrarily to your file system (or parts thereof), it
could tamper anything, so it would seem that at
that point you would have arbitrary security risks even
without an Eclipse IDE. Even Windows doesn't prevent a
tampered or unsigned executable from running. I don't
think that Linux even has signed executables, given there
is no signing of such things in the Tycho builds.
suggests that it's not really so feasible to prevent Java
from running unsigned jars, though I expect from Thomas'
answer that OSGi can do verification with its specialized
class loader (though presumably that has a performance
impact).
Running Java with a security manager enabled for the
purpose of running an IDE I think makes zero sense, so
generally the IDE can do anything and can itself be a
rogue process (if and when the user installs arbitrary
things from the marketplace).
Even if the jars are verified, I can still personally
think of a number of ways that I could tamper data files
used by the IDE that would make the IDE "do bad things".
I'll not outline the possible ways that I can think of...
:-P
I think a fundamental aspect (assumption?) of security is
that the machine itself is secure, sufficiently so that a
process that does rogue things never runs in the first
place. Verifying signatures and checksums ensures that
only known content is downloaded and installed in order to
keep the machine secure.
Regards,
Ed
On 24.09.2020 19:53, Denis Roy wrote:
So it's possible for another
process to tamper with jars and have Eclipse run them
blindly.
Do we know if that is industry
practice?
On 2020-09-24 12:07 p.m., Thomas Watson wrote:
Yes, p2 verifies the signatures and
content of the JARs to confirm it hasn't been
tampered with before installing the JAR. At runtime
the verification of JARs is not enabled by default.
Otherwise what you did would have resulted in a
runtime exception for the class you changed.
This is probably a silly question but I was
wondering how we protect the content of jar
files as they are being pulled from mirrors all
over the world.
Due to a recent break in the Platform class,
I compiled my own version of the Platform class
where I re-added the removed method. Then I
replaced it in the plugins/o.e.c.runtime jar
using 7-zip.
This solved my issue but it also made me
wonder how this was protected if some
mirror-server user used the same hack to dope
our jars.
I assume this is being done by p2 when
downloading the jar files by comparing some MDA
hash?