Curious Case of Embedded Executable in a Newly Introduced Transitive Dependency

TL;DR

This is a story of a new open source package introduced as a transitive dependency during a regular dependency upgrade. The package was flagged as suspicious due to an embedded executable. However, manual analysis confirmed that it is not malicious. This incident highlights the fact that significant volume of code, in any software, is introduced through the open source software supply chain, especially through transitive dependencies that are outside practical control of downstream software consumers. The question remains:

How to trust code from open sources that are a major part of any software

Discovery

At SafeDep we dogfood our own products. More recently, the GitHub App for protecting against malicious open source packages. While performing a regular dependency upgrade chore, we came across a very interesting real life gotcha in a pull request xbom/51. The GitHub App flagged a suspicious package.

Analysis

On inspecting further, github.com/clipperhouse/stringish @ v0.1.1 Go module was flagged as suspicious. The pull request in question was raised with following intentional changes:

• Go dependency upgrades using go get -u
• Dockerfile base image update for Go 1.25.2 builder image

Note: The pull request in question is available at xbom/51

Surely no new dependency was intentionally added. When an unknown dependency was flagged as suspicious, we almost certainly assumed it to be in a transitive dependency. The immediate response was to identify the package relationships through which this particular Go module was introduced.

1
go mod why github.com/clipperhouse/stringish

The output shows the path in the dependency graph through which github.com/clipperhouse/stringish was introduced

1
github.com/safedep/xbom/pkg/reporter
2
github.com/jedib0t/go-pretty/v6/text
3
github.com/mattn/go-runewidth
4
github.com/clipperhouse/uax29/v2/graphemes
5
github.com/clipperhouse/stringish

A quick git diff confirmed that the last 2 dependencies are newly introduced:

1
git diff main | grep -i clipperhouse

1
+       github.com/clipperhouse/stringish v0.1.1 // indirect
2
+       github.com/clipperhouse/uax29/v2 v2.3.0 // indirect

But the version of github.com/mattn/go-runewidth was updated

1
-       github.com/mattn/go-runewidth v0.0.16 // indirect
2
+       github.com/mattn/go-runewidth v0.0.19 // indirect

At this point, it was pretty clear that the dependency change was introduced between v0.0.16 and v0.0.19 of github.com/mattn/go-runewidth package. We confirmed this:

1
git clone https://github.com/mattn/go-runewidth /tmp/go-runewidth && \
2
cd /tmp/go-runewidth && \
3
git diff v0.0.16...v0.0.19 -- go.mod

1
diff --git a/go.mod b/go.mod
2
index 62dba1b..7dae1f3 100644
3
--- a/go.mod
4
+++ b/go.mod
5
@@ -1,5 +1,5 @@
6
 module github.com/mattn/go-runewidth
7

8
-go 1.9
9
+go 1.20
10

11
-require github.com/rivo/uniseg v0.2.0
12
+require github.com/clipperhouse/uax29/v2 v2.2.0

github.com/rivo/uniseg, a project with 600+ stars and 8 contributors was replaced with github.com/clipperhouse/uax29 which is built and maintained by an individual developer. github.com/clipperhouse/uax29@v2 in turn depends on github.com/clipperhouse/stringish, a package that was published only two weeks back.

While single developer projects are not a vulnerability in itself, but recently published package with very few published versions included in transitive dependency matches common attacker TTPs that we have seen in various open source software supply chain attacks in the recent past.

The following diagram describe the path through which the suspicious package was introduced.

Why Flagged?

The automated analysis report is available here. The key reason due to which the package was flagged as suspicious:

1. Recently released package with fewer versions
2. Embedded executable github.com/clipperhouse/[email protected]/utf8/utf8.test

1
stringish/utf8 on  HEAD (068e024) via 🐹 v1.24.3
2
❯ file utf8.test
3
utf8.test: Mach-O 64-bit executable arm64

Is it a malware?

No. github.com/clipperhouse/[email protected] is not a malware. We confirm this in following ways:

1. Using xbom to scan for program capabilities
2. Manual source code review

Firstly, xbom, a tool that checks for code capabilities (such as process execution) through static code analysis, did not find any risky code capabilities. Manual analysis also did not find any reference to the utf8.test file. In fact, there was no reference found for the utf8.test file at all due to which stringish/issues/1 was raised to discuss possibility of removing binary executable from Go module repository.

Conclusion

This is not a case of malicious package. But this incident resembles multiple malicious packages that we have analysed in the past such as llm-oracle malicious npm package. In fact, introducing unused binary packages or executables resembles the maintainer led attack pattern in xz incident.

While there is no evidence of malicious intent in this specific case, the fact remains, open source code is adopted with implicit trust today. This behavior is exploited by introducing malicious code through the open source software supply chain. While code analysis remains one of the reliable methods of protecting against such attacks, such analysis has its limits. Software development teams need to be aware of this risk and take appropriate measures to protect themselves.

Reference

• https://github.com/clipperhouse/stringish/issues/1
• https://github.com/safedep/xbom/pull/51