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...
Cheers,
Wim
On Fri, Sep 25, 2020 at 10:10 AM Ed Merks <[email protected]
<mailto:[email protected]>> wrote:
Denis,
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.
Looking at this search:
https://www.google.com/search?q=java+run+only+signed+jars
and at answers like these:
https://stackoverflow.com/questions/54011270/allow-a-jar-to-run-only-if-it-is-signed
https://stackoverflow.com/questions/34641305/is-it-possible-to-force-jvm-to-check-that-every-jar-must-be-signed
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.
Tom
----- Original message -----
From: Wim Jongman <[email protected]>
<mailto:[email protected]>
Sent by: [email protected]
<mailto:[email protected]>
To: Cross project issues
<[email protected]>
<mailto:[email protected]>
Cc:
Subject: [EXTERNAL] [cross-project-issues-dev] (Mirror) security
Date: Thu, Sep 24, 2020 10:18 AM
Hi,
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?
Please enlighten me.
Cheers,
Wim
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
*Denis Roy*
*Director, IT Services | **Eclipse Foundation, Inc.*
/Eclipse Foundation/ <http://www.eclipse.org/>/: The Platform for
Open Innovation and Collaboration/
Twitter: @droy_eclipse
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
