4 ms·

What's the "good faith" reason for this stuff? Is it that the code itself gets manually reviewed and so you're not supposed to be hiding behind obfuscation?

by rtpg 6y ago

AaronFriel 6y ago
There has been a rash of scurrilous people buying popular Chrome extensions and or paying owners to add malicious code. The malicious code can add third party script references which then behave differently depending on target user or time of access, and these can be credential thefts/keylogging, (very inefficient) cryptocurrency miners, ad injection or participation in click farms, or just general connivery. I'm very glad Google is starting to do source code review on extensions, it's long overdue given the access they have.
gkoberger 6y ago
At Mozilla (and this was 10 years ago), you couldn't minify or modify any library. (There were ways to include binaries, but it was complicated.) In this case, they flagged a pattern of unicode that Google felt nobody with good intentions would be using. Turns out, Lodash used that string for something, hence the blocking. It had nothing to do with obfuscation, but rather a good-faith attempt to block bad things. Similar to how you might trigger heavy ratelimits on a request like `wp-admin/index.php`, since it's clearly a bot trying to find vulnerabilities.
- Dylan16807 6y ago
  > a string that Google felt nobody with good intentions would be using It looks like it triggered on text having too much entropy, which is really reckless on such short sequences. If there's no specific thing it's trying to block, there's less good faith to give credit for.
  - gkoberger 6y ago
    Well, we don't know what happened behind the scenes. Based on the fact that they took down an extension that hadn't been updated in a month, it makes me think a serious vulnerability was discovered behind the scenes in other extensions.
    - Dylan16807 6y ago
      Keep in mind that it triggered on three separate strings. The chance of them all being malware/vulnerability signatures seems pretty low, unless their method for generating those is particularly reckless.
ajross 6y ago
Yeah, pretty much. Extensions shouldn't be obfuscated. Would you choose to run code in a privileged context (and "the whole browser" is awfully privileged!) if you suspected the author was hiding something? Same principle. In this case, the review was pretty much correct. The code absolutely looked obfuscated, forcing the author to dig through a bunch of dependencies just to figure out where the offending strings (in HIS OWN EXTENSION!) were coming from. And the answer turned out to be benign. But it sure didn't look benign until a relatively deep analysis was done. Extension reviews aren't supposed to be for deep analysis.

What's the "good faith" reason for this stuff? Is it that the code itself gets manually reviewed and so you're not supposed to be hiding behind obfuscation?

by rtpg 6y ago

What's the "good faith" reason for this stuff? Is it that the code itself gets manually reviewed and so you're not supposed to be hiding behind obfuscation?

AaronFriel 6y ago

There has been a rash of scurrilous people buying popular Chrome extensions and or paying owners to add malicious code. The malicious code can add third party script references which then behave differently depending on target user or time of access, and these can be credential thefts/keylogging, (very inefficient) cryptocurrency miners, ad injection or participation in click farms, or just general connivery. I'm very glad Google is starting to do source code review on extensions, it's long overdue given the access they have.

gkoberger 6y ago

At Mozilla (and this was 10 years ago), you couldn't minify or modify any library. (There were ways to include binaries, but it was complicated.) In this case, they flagged a pattern of unicode that Google felt nobody with good intentions would be using. Turns out, Lodash used that string for something, hence the blocking. It had nothing to do with obfuscation, but rather a good-faith attempt to block bad things. Similar to how you might trigger heavy ratelimits on a request like `wp-admin/index.php`, since it's clearly a bot trying to find vulnerabilities.

Dylan16807 6y ago
> a string that Google felt nobody with good intentions would be using It looks like it triggered on text having too much entropy, which is really reckless on such short sequences. If there's no specific thing it's trying to block, there's less good faith to give credit for.
- gkoberger 6y ago
  Well, we don't know what happened behind the scenes. Based on the fact that they took down an extension that hadn't been updated in a month, it makes me think a serious vulnerability was discovered behind the scenes in other extensions.
  - Dylan16807 6y ago
    Keep in mind that it triggered on three separate strings. The chance of them all being malware/vulnerability signatures seems pretty low, unless their method for generating those is particularly reckless.

ajross 6y ago

Yeah, pretty much. Extensions shouldn't be obfuscated. Would you choose to run code in a privileged context (and "the whole browser" is awfully privileged!) if you suspected the author was hiding something? Same principle. In this case, the review was pretty much correct. The code absolutely looked obfuscated, forcing the author to dig through a bunch of dependencies just to figure out where the offending strings (in HIS OWN EXTENSION!) were coming from. And the answer turned out to be benign. But it sure didn't look benign until a relatively deep analysis was done. Extension reviews aren't supposed to be for deep analysis.