Confirmed users
1,041
edits
Talk:Extension Blocklisting: Difference between revisions
no edit summary
No edit summary |
|||
| Line 26: | Line 26: | ||
** '''A:''' We are looking at ways of making it less easy for a malicious extension to disable blacklisting. Keep in mind that there are several security measures prior to installing an extension and that is where malicious extensions have to be stopped... before they are installed. [[User:Robert Strong|Robert Strong]] | ** '''A:''' We are looking at ways of making it less easy for a malicious extension to disable blacklisting. Keep in mind that there are several security measures prior to installing an extension and that is where malicious extensions have to be stopped... before they are installed. [[User:Robert Strong|Robert Strong]] | ||
* '''Q:''' Will users be able to get a notification about blacklisted extensions/plugins but still further use them - i.e. when they've got no admin privileges right away and still ''need'' the Java-plugin, but don't want to do without the additional help by Mozilla.org? It currently seems to be an all-or-nothing: either you trust us and let us manage everything - or you're on your own. Would be nice if there were two choices to be made here. -- [[User:Zeniko|zeniko]] 10:44, 1 Mar 2006 (PST) | * '''Q:''' Will users be able to get a notification about blacklisted extensions/plugins but still further use them - i.e. when they've got no admin privileges right away and still ''need'' the Java-plugin, but don't want to do without the additional help by Mozilla.org? It currently seems to be an all-or-nothing: either you trust us and let us manage everything - or you're on your own. Would be nice if there were two choices to be made here. -- [[User:Zeniko|zeniko]] 10:44, 1 Mar 2006 (PST) | ||
** '''A:''' Plugins aren't implemented yet and extension blocklisting can be disabled in the same manner as the nightly channel can be changed. Further though needs to be put into how this is managed and whether it makes sense to allow an about:config to over-ride the enabling / disabling. -- [[User: | ** '''A:''' Plugins aren't implemented yet and extension blocklisting can be disabled in the same manner as the nightly channel can be changed. Further though needs to be put into how this is managed and whether it makes sense to allow an about:config to over-ride the enabling / disabling. -- [[User:Robert_Strong|Robert Strong]] 13:39, 2 Mar 2006 (PST) | ||
* '''Q:''' What if a poison-XPI vendor just cycles the GUID with each served XPI? Spammers don't care for rules or standards and it only needs to be installed once. [[User:Kroc|Kroc]] 01:42, 15 Feb 2006 (PST) | * '''Q:''' What if a poison-XPI vendor just cycles the GUID with each served XPI? Spammers don't care for rules or standards and it only needs to be installed once. [[User:Kroc|Kroc]] 01:42, 15 Feb 2006 (PST) | ||
** '''A:''' Extension Manager blacklisting isn't a magic pill for all possible problems though it does solve the problem with a malicious XPI if the ID isn't changed. It also solves the problem for extensions that have an ID that doesn't change and have security vulnerabilities, memory leaks that harm the user experience, break the app (especially extensions that have a <tt>targetApplication</tt> <tt>maxVersion</tt> that is in the future), and other cases as well. You may be interested in [https://bugzilla.mozilla.org/show_bug.cgi?id=250854 Bug 250854] which can prevent installation from a site that is in a blacklist though this obviously is also not a complete solution to the potential problem that you brought up. User education to not install extensions from sources they are unfamiliar with also goes a long way to solving the problem you brought up. -- [[User: | ** '''A:''' Extension Manager blacklisting isn't a magic pill for all possible problems though it does solve the problem with a malicious XPI if the ID isn't changed. It also solves the problem for extensions that have an ID that doesn't change and have security vulnerabilities, memory leaks that harm the user experience, break the app (especially extensions that have a <tt>targetApplication</tt> <tt>maxVersion</tt> that is in the future), and other cases as well. You may be interested in [https://bugzilla.mozilla.org/show_bug.cgi?id=250854 Bug 250854] which can prevent installation from a site that is in a blacklist though this obviously is also not a complete solution to the potential problem that you brought up. User education to not install extensions from sources they are unfamiliar with also goes a long way to solving the problem you brought up. -- [[User:Robert_Strong|Robert Strong]] 21:52, 15 Feb 2006 (PST) | ||
---- | ---- | ||
| Line 38: | Line 38: | ||
Thoughts on these: | Thoughts on these: | ||
# Use a hash algorithm and '''not''' an extension ID to query any black or whitelist, since that way if we say an extension is good on the basis of a hash, we *known* what it is we're looking at (if found) and that it's unmodified. ID's can be trivially spoofed, hashes are designed to be extremely hard to spoof. | # Use a hash algorithm and '''not''' an extension ID to query any black or whitelist, since that way if we say an extension is good on the basis of a hash, we *known* what it is we're looking at (if found) and that it's unmodified. ID's can be trivially spoofed, hashes are designed to be extremely hard to spoof. | ||
* How would you suggest accomplishing this in a way where the has would still identify the extension if the malware author makes a change in the same manner as they can change the id?[[User:Robert_Strong|Robert Strong]] | |||
# When it comes to malware, unless it's very simple, you're immediately into signature detection. Signature analysis is a whole area all by itself, and usually the territory of A/V software. Do we have to reinvent the wheel? Is there some way to get A/V software to identify mal-extension sigs before install? | # When it comes to malware, unless it's very simple, you're immediately into signature detection. Signature analysis is a whole area all by itself, and usually the territory of A/V software. Do we have to reinvent the wheel? Is there some way to get A/V software to identify mal-extension sigs before install? | ||
* it should b e possible to hook into the download so av vendors can detect before install... keep in mind that malware is not what blocklisting is focused on and for the types of extensions it is focused on it would be inappropriate for av vendors to identify them as malware. [[User:Robert_Strong|Robert Strong]] | |||
# Since most if not all extensions are basically zipped scripts, can a mal-script detector be borrowed from some other o/s project and detection of script functions that are typical of malware be added to FF, so unknown extensions are background-checked for script function concerns upon install? | # Since most if not all extensions are basically zipped scripts, can a mal-script detector be borrowed from some other o/s project and detection of script functions that are typical of malware be added to FF, so unknown extensions are background-checked for script function concerns upon install? | ||