>
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 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.
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? Getting access to a build is not that hard.
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?