Pages take +15 seconds to load, Mango was possibly serving malware through the polyfill.io supply chain attack between February and June of 2024

[KandyWrong]

Describe the bug
Emphasis on WAS. Mango WAS possibly serving malware through a supply chain attack, but no longer.

However there's still an issue with pages loading slowly since the polyfill dot io domain does not exist anymore.

This file: src\views\components\head.html.ecr

Contains a reference to the polyfill dot io min js script, on line 11:

...
<script src="https://polyfill.io/v3/polyfill.min.js?features=MutationObserver%2Cdefault%2CmatchMedia&flats=gated"></script>
...

The polyfill dot io domain and github repository were recently bought and intentionally compromised around February 2024:

• https://blog.qualys.com/vulnerabilities-threat-research/2024/06/28/polyfill-io-supply-chain-attack
• https://censys.com/july-2-polyfill-io-supply-chain-attack-digging-into-the-web-of-compromised-domains/
• https://blog.redsift.com/news/understanding-the-polyfill-io-domain-attack/
• https://support.algolia.com/hc/en-us/articles/26276225049873-Why-am-I-getting-a-security-warning-about-polyfill-io

The polyfill dot io domain was shutdown in June of 2024:

• https://www.securityweek.com/polyfill-domain-shut-down-as-owner-disputes-accusations-of-malicious-activity/

Mango 0.27.0 still tries to include the polyfill js library. Mango page loads are slow because the browser tries to load a js file from a domain that doesn't exist anymore.

To Reproduce
I'm not gonna explain how to infect a machine with a bogus polyfill library, but I will explain how I discovered this.

Recently I noticed that Mango 0.27.0 was serving pages slowly to my Android Pixel 4a. Pages were taking at least 15 seconds to load, usually longer, when the phone was connected directly to my LAN. Oddly enough, pages always loaded instantly when using desktop Chrome and Firefox under Windows 10. Even stranger, my Pixel 4a had no issues loading pages when I was connected to my Wireguard VPN over LTE.

Additional context: I run pfBlockerNG under pfsense which acts as a DNS sinkhole (very similar to pihole).

In summary:

Thing	Connected through	Result
Android 14 / Pixel 4a	WLAN	Pages load slowly
Android 14 / Pixel 4a	Wired Ethernet	Pages load slowly
Android 14 / Pixel 4a	LTE / VPN	Pages load instantly
Desktop Chrome / Firefox	WLAN	Pages load instantly
Desktop Chrome / Firefox	LTE / VPN	Pages load instantly

I sniffed packets between the Pixel 4a and the Mango server to see where the hang-up was.

• The Android phone was connected over wired Ethernet (yes, it really does support this with a USB-C adapter)
• Packet capture was made on the pfsense firewall
• The Android phone IP address is 10.20.7.30
• The Mango server IP address is 192.168.2.112

Here's the initial request. Nothing out of the ordinary here. Note the timestamp of around 3.2 seconds.

A couple more requests fly by, nothing wrong here:

This is where things start to go to hell. Notice how there's a failed DNS lookup for polyfill.io followed by about ~5 seconds of delay waiting on a query to the polyfill.io.lan.home domain. I don't know why Android tries looking for lan.home, I suspect this is some kind of DNS-related fallback behavior built into Android or pfBlockerNG.

More of the same, just waiting around for a polyfill dot io query response that will never come:

And then finally the PNG data starts flowing... 18 seconds later.

At this point I had no idea what polyfill was, but a quick Google search rectified that. It also made my hair stand on end, as apparently my Mango instance had been trying to include and serve a compromised, malware-infected Javascript library for several months!

To test my hypothesis that this was the source of my problem I removed line 11 from src\views\components\head.html.ecr, rebuilt using the Dockerfile, copied the newly built binary in place of the old, and now my pages load instantly on Android. Also packet capture does not report any more attempts to grab something from polyfill dot io.

As for why this affected my Android connected to my LAN and nothing else... here's my best guess. Remember how I said I run pfBlockerNG under pfsense, which acts as a DNS sinkhole (similar to pihole)?

Windows / Linux machines will blindly use whatever DNS the gateway gives them, which is usually the gateway itself. In my experience Android is notorious for playing tricks with DNS settings (like just straight up ignoring them). This causes weird issues like what I described above. Apparently the Wireguard client running on Android has the magical ability to override this behavior, which forced my Android instance to hit my local DNS and therefore run through the DNS sinkhole, which insta-killed the requests to polyfill.

Expected behavior
Mango should not attempt to include the (compromised) polyfill library from a domain that no longer exists.

Andrew Betts is the creator of poyfill, and has stated that no one should be using the polyfill dot io domain.

If you really want to keep polyfill then Cloudflare has their own (clean) version: https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk

I saw no ill effects from removing it entirely.

Environment:

• OS: Windows 10, Android 14
• Browser: Chrome for Android, Chrome for Windows, Firefox for Windows (any version)
• Mango Version: 0.27.0 (binary / bare-metal version, not Docker)

Docker
I do not run Mango in Docker. (Although the existing Dockerfile could use some love, but this is out of scope for the issue)

Additional context
If you came across this post from Google or wherever, you can fix this on your own instead of waiting for a new Mango release.

Simply clone the repo, remove the offending line from the src\views\components\head.html.ecr, and then rebuild using the Dockerfile.

If you're like me and don't use Docker then there are a few extra steps:

• Build the Docker image
• Run the Docker image (default settings are fine)

Then copy the binary out of the Docker container. Here's an example:

docker container cp mango:/usr/local/bin/mango /home/kandy/mango

For more info see: https://docs.docker.com/reference/cli/docker/container/cp/

If your Docker build blows up due to an issue with image_size.cr, then:

• Modify shard.lock, set the image_size: repo to git: https://github.com/AkkoYK/image_size.cr.git
• Modify shard.yml, set the image_size: shard to github: akkoyk/image_size.cr
  For more info see: [Bug Report] stb_image_resize.h 404 error #359

Recommendations
Given that Mango advertises itself as "a self-hosted manga server and reader" it might be worth looking into embedding all javascript dependencies into the application itself (i.e. jquery, alpinejs, etc). Otherwise this self-hosted app still requires an internet connection, and is dependent on things that are not self-hosted.