Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

arstechnica.com

Post reply on HN
Print view View original

101–110 of 111 posts

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#101

Post by [deleted] »

aboodman wrote: post #100
hackinthebochs wrote: post #99

Earlier quoted context omitted.

We should be asking ourselves why we allow extensions with so much power and no meaningful security model. Auto update is a misfeature if I've ever seen one (again for anything but the most critical pieces of software).

Autoupdate is not a "feature", it's a consequence of Turing completeness combined with network access. Any platform that has these two properties has autoupdate, and there's no technical way to prevent it. The autoupdate feature exposed to Chrome extensions is not there to make autoupdate possible, it's there to prevent developers from shooting themselves in the foot by implementing their own autoupdate insecurely. I…

[deleted]

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#102

Post by hackinthebochs »

aboodman wrote: post #100
hackinthebochs wrote: post #99

Earlier quoted context omitted.

We should be asking ourselves why we allow extensions with so much power and no meaningful security model. Auto update is a misfeature if I've ever seen one (again for anything but the most critical pieces of software).

Autoupdate is not a "feature", it's a consequence of Turing completeness combined with network access. Any platform that has these two properties has autoupdate, and there's no technical way to prevent it. The autoupdate feature exposed to Chrome extensions is not there to make autoupdate possible, it's there to prevent developers from shooting themselves in the foot by implementing their own autoupdate insecurely. I…

I can't help but roll my eyes at these "turing completeness" arguments. The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download. We don't operate on abstract turing machines, we can impose whatever limits we want on the code we allow to run. Now, I'm not saying this is easy to accomplish, but impossible it is not. If Google can manage to allow machine code downloaded over the internet to run securely like it claims, I'm sure it can handle a little javascript.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#103

Post by aboodman »

hackinthebochs wrote: post #102
aboodman wrote: post #100

Earlier quoted context omitted.

Autoupdate is not a "feature", it's a consequence of Turing completeness combined with network access. Any platform that has these two properties has autoupdate, and there's no technical way to prevent it. The autoupdate feature exposed to Chrome extensions is not there to make autoupdate possible, it's there to prevent developers from shooting themselves in the foot by implementing their own autoupdate insecurely. I…

I can't help but roll my eyes at these "turing completeness" arguments. The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download. We don't operate on abstract turing machines, we can impose whatever limits we want on the code we allow to run. Now, I'm not saying this is easy to accomplish, but impossible i…

"The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download."

You can remove eval() (In fact eval() is disallowed in Chrome extensions, for different reasons).

But how do you prevent an extension from including an interpreter for some other language and simply downloading and interpreting code in that language? This isn't crazy. It's common for games to include interpreters, for example.

Including an interpreter for a simple language is just one step in complexity beyond downloading configuration files. Is downloading configuration files that change the behavior of the code forbidden in your proposed system too? How is that accomplished?

"If Google can manage to allow machine code downloaded over the internet to run securely like it claims, I'm sure it can handle a little javascript."

NaCL has the same properties I'm describing. NaCL enforces a sandbox on what a hunk of code has access to; it doesn't enforce that that code won't change its behavior over time, possibly in response to data from the network. That is not possible to do.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#104

Post by hackinthebochs »

aboodman wrote: post #103
hackinthebochs wrote: post #102

Earlier quoted context omitted.

I can't help but roll my eyes at these "turing completeness" arguments. The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download. We don't operate on abstract turing machines, we can impose whatever limits we want on the code we allow to run. Now, I'm not saying this is easy to accomplish, but impossible i…

"The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download." You can remove eval() (In fact eval() is disallowed in Chrome extensions, for different reasons). But how do you prevent an extension from including an interpreter for some other language and simply downloading and interpreting code in that langua…

What you say is certainly true in general, but it doesn't take into account the threat model of a supposed malicious extension. The threat model here is that someone decides to significantly alter the behavior of an extension after it gains traction and a certain level of trust. For this to work would require the extension to include an interpreter or some other mechanism from the start. They would essentially have to think "if this gains traction I may want to start silently injecting ads/stealing information, so why don't I include this interpreter in it now just in case". While possible, it isn't very likely.

The other problem with the security model is that all extensions are seemingly created equal. I would think that a large majority of extensions do not require access to any external resources besides the ones downloaded from the webpage itself. Think of a youtube downloader, flashblock, etc. These types of extensions should have a different security model that is constrained to restrict any web request calls besides to the domain of the page and perhaps any domains that page calls (to take into account cdns). These types of extensions shouldn't need any consideration of security implications to install. There's no reason why a youtube downloader should have the potential to steal my passwords down the line. More involved extensions that would require generic http requests could have the warning about data access.

I see in your profile that you know a thing or two about chrome extensions, so I will defer to your expertise on whats possible. It just seems like with the proper constraints for different levels of access one can have much greater security than we have now just treating all extensions the same.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#105

Post by aboodman »

hackinthebochs wrote: post #104
aboodman wrote: post #103

Earlier quoted context omitted.

"The obvious way to prevent auto updating is to simply disallow an extension from modifying its own storage and to prevent it from running any code it manages to download." You can remove eval() (In fact eval() is disallowed in Chrome extensions, for different reasons). But how do you prevent an extension from including an interpreter for some other language and simply downloading and interpreting code in that langua…

What you say is certainly true in general, but it doesn't take into account the threat model of a supposed malicious extension. The threat model here is that someone decides to significantly alter the behavior of an extension after it gains traction and a certain level of trust . For this to work would require the extension to include an interpreter or some other mechanism from the start. They would essentially have…

If we didn't provide an autoupdate mechanism, then developers would just implement their own. Frequently, these handrolled systems would have security flaws. We have an existence proof of this: it happened in the Greasemonkey ecosystem.

We might propose that we could prevent these hand-rolled systems by restricting eval(). Well, we already restrict eval for different reasons. What we see is a lot of people working around the restriction by injecting code into websites (!!).

My bet is that basically any significantly sized extension would implement a workaround for any autoupdate restriction we tried to employ. Developers really like the ability to update their product, and the workarounds are not that hard. And these workarounds would be worse than the original problem - that sometimes good people turn bad.

It would also destroy the value that autoupdate provides which you are forgetting about: most of the time it is used by good people to do good things. We frequently find extensions with security problems, tell the author, and then they fix and push them to users. Without autoupdate this wouldn't be possible.

===

As for your proposal for how to restrict the levels of access extensions have... As I said above, we do this kind of thing already. You can read all about it here: http://developer.chrome.com/extensions/permission_warnings.h.... We have a very granular security system.

For example, it has been always been possible to write a youtube downloader Chrome extension that only has access to youtube.com.

Flashblock would theoretically be possible with the upcoming declarativeWebRequest API (http://developer.chrome.com/extensions/declarativeWebRequest...).

However designing the right APIs that have narrow risk, yet are flexible enough for developers to want to use remains a difficult problem that is unsolved except in specific cases.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#106

Post by hackinthebochs »

aboodman wrote: post #105
hackinthebochs wrote: post #104

Earlier quoted context omitted.

What you say is certainly true in general, but it doesn't take into account the threat model of a supposed malicious extension. The threat model here is that someone decides to significantly alter the behavior of an extension after it gains traction and a certain level of trust . For this to work would require the extension to include an interpreter or some other mechanism from the start. They would essentially have…

If we didn't provide an autoupdate mechanism, then developers would just implement their own. Frequently, these handrolled systems would have security flaws. We have an existence proof of this: it happened in the Greasemonkey ecosystem. We might propose that we could prevent these hand-rolled systems by restricting eval(). Well, we already restrict eval for different reasons. What we see is a lot of people working ar…

Thanks for the info. I had no idea chrome had that, I don't think I recall installing an extension that DIDNT give me a warning about access. It seems like developers just stick to the more unrestricted system out of convenience or narcissism ("must phone home my youtube downloader, for science!"). There's definitely something out of whack here if developers won't use the restricted access when their extension fits nicely within that model. It would be nice if it could be shown that extensions are penalized in terms of downloads by requiring unnecessary access. As it is I've stopped using all extensions in chrome except adblock.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#107

Post by quadrangle »

nl wrote: post #81
quadrangle wrote: post #6

Obligatory note: Another example of why we should only run Free Software and only from trusted sources. Users of Trisquel or gNewSense never have problems like this.

All Chrome Extensions are completely opensource (lowercase - in the sense you can unzip them and inspect the source). The evidence seems to be that this does actually work - people do look, and find out suspicious looking issues. However, that is insufficient to protect users of extensions that were previously trustworthy and then become malicious.

I think real capital Open Source is what matters here. In that case, anyone can fork and redistribute the good parts of any plugin. In the case here, someone owns the code and reserves exclusive monopoly and that's what gets bought out and that's harder to revert or fork.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#108

Post by nl »

quadrangle wrote: post #107
nl wrote: post #81

Earlier quoted context omitted.

All Chrome Extensions are completely opensource (lowercase - in the sense you can unzip them and inspect the source). The evidence seems to be that this does actually work - people do look, and find out suspicious looking issues. However, that is insufficient to protect users of extensions that were previously trustworthy and then become malicious.

I think real capital Open Source is what matters here. In that case, anyone can fork and redistribute the good parts of any plugin. In the case here, someone owns the code and reserves exclusive monopoly and that's what gets bought out and that's harder to revert or fork.

That is true, but the OP was referring to the ability to inspect code for security and/or privacy problems, so you can decide if you want to run it. Just getting the source code is adequate for that.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#109

Post by esrauch »

hackinthebochs wrote: post #98
esrauch wrote: post #97

Earlier quoted context omitted.

Every piece of software I use is broken in some way. Auto updates allow me to hope that they are a little less broken each day.

My philosophy is it's not broken if I don't notice it.

My point was that I notice broken things roughly every day.

Re: Adware vendors buy Chrome Extensions to send ad- and malware-filled updates

#110

Post by kzahel »

hayfield wrote: post #35
kzahel wrote: post #31

Earlier quoted context omitted.

The problem is with users. They ignore the scary "access to all websites" dialogs and install extensions. Sites like pinterest have extensions that request these permissions, when they don't even need them. There's a way to have the extension only have access to the site you're on when you CLICK somewhere in your toolbar. There are fine grained permissions and optional permissions to specific hosts and ports and URL…

Depending on how the extension developer feels future development may pan out, requesting access to all websites is the only reasonable way to do it. With how the update system works[1], when requesting new permissions the extension is disabled until manually reenabled. If there's even a slight possibility you may want to request access to additional sites in the future, you basically have to request "all websites" t…

You are right that adding new permissions will disable the extension until it is re-enabled. But android has a very similar behavior.

Still, I feel that using optional permissions and pointing out to the user why they would want enable the new permissions is the best option. Yes, it's more work for the developer.

I just released an extension to help identify high risk installed extensions: https://chrome.google.com/webstore/detail/privacy-guard/edca...

Post reply on HN