Bugzilla

(mostly gone) XtC4UaLL [:xtc4uall]

Comment 2

•

14 years ago

No, it's not.

Status: RESOLVED → REOPENED

Resolution: DUPLICATE → ---

Updated

•

14 years ago

OS: Mac OS X → All

Hardware: x86 → All

Comment 3

•

14 years ago

It will be hard to do this in a way that doesn't turn an https://addons.mozilla.org/ XSS or clickjacking or SSL-compromise into a full compromise of the user's machine. See bug 561177 comment 5 and my other comments in that bug. Just tossing some ideas out there: * Reducing the likelihood of a web-security-model failure ** Mitigate XSS with CSP. ** Mitigate universal-XSS bugs in Firefox by requiring https://addons.mozilla.org/ tabs to be loaded in a separate process. ** Mitigate clickjacking with X-Frame-Options ** Mitigate PKI weaknesses by shipping special SSL settings for AMO with Firefox (STS, CA lock, OCSP hard fail). * Reducing the likelihood of an AMO backend compromise ** Split the public-facing site for installing addons from the developer-facing site. * Reducing the impact of an AMO website compromise ** Require extensions installed in this manner to be signed with a specific key held by Mozilla. ** Require extensions installed in this manner to be loaded from a specific hostname, such as https://current-versions-of-approved-addons.mozilla.org/. ** Require extensions installed in this manner to be low-privilege extensions. * Make Firefox UI that feels smooth when intentionally installing an extension from AMO, but feels like a security roadblock when being drive-byed ** Use in-app UI to display the extension description instead of displaying a web page with an "Add to Firefox" button. (Like iTunes / iOS app store.) ** Require one click on a web page button and one click on an in-app button, but make the designs very similar, so it looks like a fade-out rather than a context switch. Bail if the mouse cursor is unexpectedly over the in-app button when the in-app button appears.

Updated

•

14 years ago

Blocks: cuts-addons

Comment 4

•

14 years ago

It seems like the argument here is that we should delay every add-on download in the event that AMO gets not only hacked, but specifically compromised with a click-jacking exploit. Considering this is an inconvenience that currently hits every user with every add-on download and it's entirely unlikely that AMO gets hacked, can we not remove the modal wait-screen entirely on AMO? If there's a vulnerability in AMO that makes it a candidate for various hackery, that should be handled separately.

Comment 5

•

14 years ago

To clarify comment 3, I think we should try to remove the prompt for AMO. But it will need to be a large effort involving security+infrasec+AMO+UX teams, not a 2-line patch to land this weekend. As part of that effort, we should consider alternatives that involve some kind of in-product UI but don't "feel like a security prompt".

Comment 6

•

14 years ago

(In reply to comment #5) > To clarify comment 3, I think we should try to remove the prompt for AMO. But > it will need to be a large effort involving security+infrasec+AMO+UX teams, not > a 2-line patch to land this weekend. As part of that effort, we should > consider alternatives that involve some kind of in-product UI but don't "feel > like a security prompt". The large effort you describe would *only* be as a security response to potential AMO-hacking-and-clicking-jacking attempts, correct? Nothing else about removing this dialog on AMO would require much substantial effort?

Comment 7

•

14 years ago

Btw, even harder than iframe-based clickjacking will be UI-timing attacks (along the lines of bug 162020) against the web site. And bugs that keep Firefox from painting might become security holes :(

Comment 8

•

14 years ago

(In reply to comment #7) > Btw, even harder than iframe-based clickjacking will be UI-timing attacks > (along the lines of bug 162020) against the web site. And bugs that keep > Firefox from painting might become security holes :( That stills requires an XSS vulnerability or timing attack in AMO itself, though. How likely is that, and if the chance is exceedingly slow, is it really worth keeping this timing problem through yet another release? We could address add-ons registering for broadcast intent later (ala http://thomascannon.net/blog/2011/02/android-lock-screen-bypass/)

Comment 9

•

14 years ago

The UI-timing attack I'm talking about doesn't require a flaw in the web site: 1. Convince the user to click a certain location on the page. 2. Navigate to https://addons.mozilla.org/en-US/firefox/addon/adblock-plus/ 3. "Add to Firefox" button lands under the mouse cursor. 4. "Add to Firefox" button gets clicked.

(no longer active)

Reporter

Comment 10

•

14 years ago

(In reply to comment #3) > * Reducing the likelihood of a web-security-model failure > ** Mitigate XSS with CSP. Amen to that! > ** Mitigate universal-XSS bugs in Firefox by requiring > https://addons.mozilla.org/ tabs to be loaded in a separate process. Could such bugs also affect privileged pages, like about:config? > ** Mitigate clickjacking with X-Frame-Options Amen to that! > ** Mitigate PKI weaknesses by shipping special SSL settings for AMO with > Firefox (STS, CA lock, OCSP hard fail). Amen to that! > * Reducing the likelihood of an AMO backend compromise > ** Split the public-facing site for installing addons from the developer-facing > site. This would reduce the attack surface, but I don't know if the gain is worth the investment. > * Reducing the impact of an AMO website compromise > ** Require extensions installed in this manner to be signed with a specific key > held by Mozilla. > ** Require extensions installed in this manner to be loaded from a specific > hostname, such as https://current-versions-of-approved-addons.mozilla.org/. > ** Require extensions installed in this manner to be low-privilege extensions. Isn't the first item in this list alone to address the concerns in this section? > * Make Firefox UI that feels smooth when intentionally installing an extension > from AMO, but feels like a security roadblock when being drive-byed > ** Use in-app UI to display the extension description instead of displaying a > web page with an "Add to Firefox" button. (Like iTunes / iOS app store.) I'm not sure how practical that is, given that AMO is intended to serve all versions of Firefox (and potentially all Mozilla-based applications). > ** Require one click on a web page button and one click on an in-app button, > but make the designs very similar, so it looks like a fade-out rather than a > context switch. Bail if the mouse cursor is unexpectedly over the in-app > button when the in-app button appears. I think users will find this also irritating. Maybe not as bad as the current situation though.

Daniel Veditz [:dveditz]

Comment 11

•

14 years ago

> Could such bugs also affect privileged pages, like about:config? Yes, which is why we don't let web content load privileged about: pages. We have never been able to completely eliminate all the ways framed/moved/shadowed/suddenly-revealed content can be used to hack users (design of HTML/DOM doesn't allow it) so we keep privileged pages out of web content hands. Doing something like this bug (or embedding AMO in the about:addons page) effectively turns AMO into (semi-)privileged content and we need to be damn careful about it. Note that the add-on dialog delay was added to address bug 162020 attacks specifically for AMO; other sites couldn't create those dialogs without going through a separate whitelisting click. It's not like we invented it and then forgot to remove it when we decided AMO (or update.mozilla.org back then) was special. The attacks were demonstrated by security researchers independently of Jesse's bug, they're not just theoretical and unlikely. Any such change is going to need a security design review so if you're trying to get this into Firefox 5 we need to get a look at the designs pretty soon. > If there's a vulnerability in AMO that makes it a candidate for various > hackery, that should be handled separately. AMO is a website created by humans. I guarantee there is and will always be at least one unknown security bug. The idea is to design robust systems that don't require perfection. Some failures are harder to back-stop than others but that doesn't mean you don't try.

Comment 12

•

14 years ago

We should try to get back to first principals here. ** installing software is a dangerous activity ** We should be making design choices that are appropriate for that kind of activity. When your driving a car and get into a dangerous situation the design goal is to try and slow things down, add extra reaction time for the driver, and where possible automatically kick in breaking, and early warning defense systems, and deploy airbags and escape systems if a crash happens. The goal is not to try and make the hot rod go faster and depress the accelerator. Comment 9 mentions: > That stills requires an XSS vulnerability or timing attack in AMO itself, > though. How likely is that, and if the chance is exceedingly slow, is it > really worth keeping this timing problem through yet another release? Jesse and others have been demonstrating kickjacking techniques for close to a decade now. Since we started the web bounty program late last year we are running at about 1-2 XSS bugs discovered per month on AMO. We are continually removing addons from AMO that contain malware and annoyances for our users. Unintentionally installed addons and plugins result in most of our top crash problems in Firefox 4. The problems that are created from unintended installation of software are visible and widespread and a variety of organizations and individuals are actively working against us to get ownership of Firefox users. So the trade off is not: "a real performance issue affecting users" v. "a theoretical security concern" ...its a real security problem that will take form as soon as we remove the current breaks that are in place. Lets make sure we are making design choice that are appropriate for the situation.

Comment 13

•

14 years ago

Attached image Mockup: Arrow panel styled verification screens instead of window-modal countdown — Details

Since there are multiple user experience issues and multiple security issues at play here, many parts of which can be improved separately, maybe it would make sense to list the specific user experience issues and then the security issues. Here's the main user experience issue with AMO installation: - Before every add-on download on AMO, the permission dialog which reads "Firefox has prevented this site from asking you to install software on your computer" appears. While it's annoying to have one extra step on our official add-on page, a larger problem is that Mozilla appears in this dialog to be at war with itself. "Firefox" should never tell the user it's blocked a mozilla.org site. Ideally, this dialog would never appear on AMO at all. - The "Install add-ons only from authors you trust" dialog has a few issues: * While it's window modal rather than application modal, it's in a very different style than the arrow panel notifications that Firefox is moving to * The window is heavy, disabling all items on the page and Firefox menu and blocking content underneath it * The window is inconsistent even within the installation process, surrounded on both sides by notifications in the arrow-panel style * The countdown time is an annoying delay that, to the user, seems to serve no purpose * The window marks add-on authors we clearly trust (such as ourselves) as "not verified" Ignoring the security problems, the middle step of confirmation would ideally not exist on AMO. Users would click an install button on AMO and, after downloading that add-on, simply have it on their system (with the option to undo the installation or to restart if needed). Clearly we have some security issues to resolve, but the thrust of this bug really is to streamline installation and not force the user to make decisions they don't care about. If there were a way to combine the verification dialog with install confirmation while still being secure, maybe we could combine some of these steps. I'm attaching an old mockup that was intended to appear after the add-on downloads.

Comment 14

•

14 years ago

(In reply to comment #13) > > Since there are multiple user experience issues and multiple security issues at > play here, many parts of which can be improved separately, maybe it would make > sense to list the specific user experience issues and then the security issues. > yeah, we all agree that this area needs work, but I think it will be hard to address some of the user experience needs without looking at the security needs. Also, I'm not sure it is correct to classify the "security issues" as something that is off on another tangent. We really are trying to solve two problems for the user. 1) Help them get addons they want installed easily and quickly 2) Help them prevent drive-by installation of malware. The things you are calling "security issues" are mostly related the later item. They need as much, or more, help with UI design and User Experience as just working to get addons installed quickly. > Here's the main user experience issue with AMO installation: > > - Before every add-on download on AMO, the permission dialog which reads > "Firefox has prevented this site from asking you to install software on your > computer" appears. While it's annoying to have one extra step on our official > add-on page, a larger problem is that Mozilla appears in this dialog to be at > war with itself. "Firefox" should never tell the user it's blocked a > mozilla.org site. Ideally, this dialog would never appear on AMO at all. I'm not sure this is correct. don't we still have amo on the default allow list? No user should ever see amo as preventing addon installs unless somehow they have removed amo from the trusted addon install list. > > - The "Install add-ons only from authors you trust" dialog has a few issues: > * While it's window modal rather than application modal, it's in a very > different style than the arrow panel notifications that Firefox is moving to yeah, its rather jarring. seems to make sense to get rid of the old style dialog and do everything that's needed in the much nicer looking single Arrow pannel. > * The window is heavy, disabling all items on the page and Firefox menu and > blocking content underneath it yeah, we don't need a "heavy window" but we may need to block content from underneath to help prevent click-jacking? > * The window is inconsistent even within the installation process, surrounded > on both sides by notifications in the arrow-panel style yeah, the old style window should go... > * The countdown time is an annoying delay that, to the user, seems to serve no > purpose the countdown timer is also needed to help prevent clickjacking, but as stated in a few places, the duration that was originally implemented was excessive. It can be reduced and still provide adequate defense. > * The window marks add-on authors we clearly trust (such as ourselves) as "not > verified" > the "not verfied" here means that the addon install package has not been signed by the addon author. this also needs some work to make more sense to users. Some tough details to sort out about Mozilla and AMO as a provider of addons developed by third parties, and signing as a way of authenticating the person that wrote the code for the addon. we have been holding out hope that one day most, or all, addon packages would be signed and thus allow the contents to look more reasonable. If many addons were signed that dialog wouldn't look like: Firebug (Author not verified) but rather it might look something like Firebug (addon provided by Jennifer Boriss is now ready for installation) signing of addons is a technical response to the problem of drive-by-installation problems so getting rid of this entirely increases exposure to some kind of security problems. But you're correct in finding that its not providing the value to users that it should. Some historical perspective on the rational for signing and what it is trying to accomplish is here http://en.wikipedia.org/wiki/ActiveX#History , but this is an area worth a lot of study and discussion of how it can be made better. > Ignoring the security problems, the middle step of confirmation would ideally > not exist on AMO. Users would click an install button on AMO and, after > downloading that add-on, simply have it on their system (with the option to > undo the installation or to restart if needed). that activeX article on wikipedia tells about the historical problems of getting to close to zero user interaction and "install from the web." yeah, it sounds great to have zero, or low, interaction came at a huge cost to web security. IE has been trying to recover from earlier attempts that ingnored projection against drive-by-install attacks for several years now. > Clearly we have some security > issues to resolve, but the thrust of this bug really is to streamline > installation and not force the user to make decisions they don't care about. > or understand... Yeah, we agree. The key to the drive-by-protections are to allow user to see, and understand, whats going on, and intervene if we can detect or they determine that the wheels are coming off the track. This part is hard, but can't be ignored. > If there were a way to combine the verification dialog with install > confirmation while still being secure, maybe we could combine some of these > steps. Yeah, I think it makes a lot of sense to combine all the actions into a single dialog. The dialog could contain all the steps, and all the security checks needed in a streamlined way. The key is to get a common understanding of all of the steps in the workflow, then come up with terminology and a progression of events that's needed to explain whats going on in a better way. Maybe its better to sit a whiteboard and map out the workflow needed to get addons downloaded, checked, and installed, in the fastest possible way that also helps to prevent drive by installs.

Dave Townsend [:mossop]

Comment 15

•

14 years ago

Note that faaborg has been saying we should stop using doorhangers for add-on installs and has, I guess separately, been thinking about a tab-modal install UI instead. Perhaps you guys should chat rather than working at odds

Comment 16

•

14 years ago

Attached image screenshot of current addon install conflicting identity choice info — Details

here is a great example for the first whiteboard discussion. at the highest level there are two pieces of identity info that are important to helping users avoid drive-by installs and a poor experience with addons. 1) who is hosting the addon install package amo (or some other trusted source) some other unverfified or unknown site 2) who created the addon the screenshot shows just how conflicted we are about this and how poorly we care communicating to users. In the case of addons provided off amo we actually know quite a bit. though update pings and crowd-sourced information we know that: -millions of people use firebug every day, -they have a glowing opinion of it as one of the best web developer tools. -we also know that they didn't sign the install package so we can't be completely certain the package that will be installed is coming from the authors listed on the amo page. overall the user is probably in pretty good shape baring some bug XXS or click jacking bug in amo, or some addon author compomised account and installtion package injection attack. we could be telling the person installing that we have a 90-99% confidence that things are working smoothly in this addon install. But in the screen shot, at a key installation decision moment, we aren't telling the user any of this good information that helps them to understand and learn more about the risks. only some cryptic "author not verfied" The firebug addon install process in fact looks just like the install process for an addon created by a new addon author, used by hardly anyone, has poor user ratings, and in fact may have several pending notices in the amo-abuse queue. The chances of a user getting into a risky situation and trashing their system are much higher. this is one of the parts of the workflow that could really use a lot of discussion, understanding, and UX work. it would be a great design challenge to solve this problem.

Alex Faaborg [:faaborg] (Firefox UX)

Comment 17

•

14 years ago

Attached image current dialog where the addon is signed. — Details

attachment shows where the state were the addon *is* signed using adblock plus as the example. It really doesn't provide much useful information to the user either, just showing the author's name where usually they see "author is unknow". We should put this information into better context an help users to understand what the name in the dialog means.

Comment 18

•

14 years ago

Quick note that for the case of servers that are not AMO mossop has some work in progress on having a stronger security dialog than the current window modal countdown one over in bug 643020

Terrell Kelley

Comment 19

•

14 years ago

Now that I know where this bug is, I can comment here. How does Chrome do this? Addons from their main website only bring up prompts if they request certain features. Low-risk addons (those that don't apply to every page, for example) just immediately tell you that they are active. I know Mozilla's extension model is much more robust that Chromium, but is it possible to make the same type of distinction on AMO? Since most addons require restarting Firefox, you could just rely on the cancel restart button.

Mike Kaply [:mkaply]

Comment 20

•

14 years ago

What about non AMO addons? Will signing still be important for them? Will signing an addon get you anything in this new model?