This is a really good paper that reaches a bunch of fun conclusions, but to my eyes the practical findings are kind of marginal --- you can defeat an AV scanner, but you could already defeat AV scanners; you can defeat plagiarism-detectors, but you could already defeat plagiarism-detectors; you can package a malicious Java class in a benign-looking JAR, but that attack presumes you're convincing a target to load a JAR file you control.

The one legit-practical attack I see is the one where they trick the VS Code Extension marketplace into serving extensions with trusted publishers, but even there I'm struck by the fact that the security model for verifying extensions would depend on ZIP metadata.

I do not at all mean to talk this work down; this is my favorite species of vulnerability research, and I can see why it did well at Usenix Security.

It's a decent systematic look at something people have been doing ad hoc for a long time. In 2010 or so I realized:

1. Authenticode signatures have unauthenticated sections.

2. ZIP files don't require headers.

So you can shove a ZIP file (i.e. JAR, DOCM, APK, etc.) into a signed Windows executable without breaking its signature, and then depending on the extension it will do any number of things when clicked.

(The extent to which this works has changed a lot in the intervening years, but prior to a patch in 2013 it was especially bad, and the patches never made their way into the spec, so custom Authenticode validators like Wine's or, say, the one in Palo Alto Networks gear, were still vulnerable the last time I checked.)

Anyway, at the same time:

1. Cybersecurity products lean on Authenticode to keep false positives down for specific publishers.

2. Those same products cache everything by hash without regard for file type.

Put all of this together and you could, as of 2020 at least, not only execute whatever you wanted, you could also have it misreported by CrowdStrike or whoever as a signed Windows component.

Fun stuff, but I agree that it's kind of marginal.

The attack vector for publishing extensions existed for Firefox (and was fixed): https://bugzilla.mozilla.org/show_bug.cgi?id=1534483