Unexplained binary change in Jetbrain official plugin (potential supply chain attack?)

JetBrains Marketplace
1

I have brought up a topic on the Kotlin Slack and want to bring some attention to it here as well. Please excuse the layout of the post, it is mostly what I wrote on Slack where it follows my train of thoughts as I discover things.

There is this plugin to integrate a serial console into IDEA: (Discourse does not let me post link, search for plugin: 8031-serial-port-monitor)

It is one of the several plugins that is published under the Jetbrains branding that does not publish any change-logs, which I had brought up two or three years ago, but still Jetbrains seems to publish different plugins without changelogs. Whelp.

The actual issue I want to raise: This plugin is receiving multiple updates per month, per week and in the recent days even sometimes per day. And even worse: The associated git repository does not have any commits since over a month: ‘https (discourse does not allow me to use many links) ://github.com/JetBrains/intellij-plugins/tree/master/serial-monitor’

This does ring quiet a few security-related bells for me. Before I start bin-diffing and analyzing, does anyone know any possible explanation for this?

I compared the last two versions. Both do not have any notable changes to the plugin itself. But both ship with jssc-2.9.5.jar which does have changes:
(Screenshot showing an added plist to the macosx 64 binary library including ‘video’ and ‘audio’ security roles in the metadata.)

The included osx_64 library does not seem to raise any flags with virustotal: VirusTotal
It is also signed by Jetbrains.

Still, this all raises a lot of flags for me.

The included jssc has the META-INF with pom.xml for version 2.9.5 - which is two years old. Why the dynamic link libraries are changing between updates, is unclear. The java library does ship the dynamic link libraries and those in particular did not change over the last year, even in the master branch.

How is Jetbrains releasing this plugin? Is the stable jssc release re-bundled with updates of the native library constantly and somehow the signing is changed at the same time?
I’d really like some insights to this, this also feels like a security issue.

(the plist might be just a deafult permission list for the apple sandboxing for a more recent build - not nessecarily means that the application gets these permissions. But I am not too familiar with the apple permission system)

2

The mentioned screenshot:

grafik
grafik1889×782 129 KB

5

The plugin goes trough our normal release cycles. It is not our flagship product, sometimes it gets a bunch of updates, sometimes it does not.

jscc library is taken from GitHub - java-native/jssc: Java library for talking to serial ports (with added build support for maven, cmake, MSVC)
It was updated to support Apple M CPUs, and since then we had no problems with the library, and we did not upgrade it.

7

To elaborate on what @Ilia.Motornyi has written:

The code on intellij-plugins GitHub is the read-only snapshot of a part of our monorepo. While it’s technically possible to build the plugin from the intellij-plugin sources, it’s not used like that in production.

The actual build happens on the (unfortunately, not public) build infrastructure and involves a step where native binaries are signed. The binary itself indeed originates from Maven, from a known version, verified by a checksum.

I’ll double-check if that’s necessary or required for this specific library, however, the mere fact that it’s signed is expected.

In general, JetBrains’ build infrastructure and the plugins’ build process are carefully inspected by both internal and external security teams. To the best of my knowledge, this change is normal and not a sign of any supply chain attack.

8

Thank you for the explanation.

Since jssc comes with precompiled binaries (jssc/src/main/resources-precompiled/natives at master · java-native/jssc · GitHub), if I understand you correctly, this means the libraries shipped with the 2.9.5 release are actively being replaced by newer versions?
Do these builds happen automatically? So the native libraries are injected into the existing (older) dependency automatically?

This is a somewhat unusual approach. Maybe it is worth trying to upstream such changes instead? And if it is done manually, a changelog entry of ‘Update included native apple libraries for better Apple-M support’ would have also helped me to understand the change.

You have to excuse my suspicion. While I do not work on some infrastructure-critical embedded code, it is not exactly an implausible attack vector.

Thank you for cleaning it up.

9

Just to clarify - the binaries come not from github, they come from from Maven Central repo by automatic build scripts https://mvnrepository.com/artifact/io.github.java-native/jssc/2.9.5

10

Something like this, indeed. Note that no other changes (except sign/notarization stuff) are expected with these kinds of updates.

Personally, I share your view (the binary should be either explicitly updated with the version change, or left as-is). We’re working with our build infrastructure team on this.

1 Like