Bugzilla

Essentially the principle here is that the `<select>` menu-popup's content is controlled by an untrusted web page -- so out of an abundance of caution, it's best to constrain it to the rendering area of the web page.  Otherwise, attackers can craft sneaky attacks that use a <select> to cover up a piece of the browser UI and confuse the user.

The attack scenario in bug 1276976 involved a <select> that was crafted to pop upwards and cover up Firefox's URLbar, with the menu containing a menu-option that might confuse a user into thinking it's an actual website URL -- e.g. let's say it has an option whose text is `🔒 https://bankofamerica.com`.

With that sort of setup, and with a spoofed web page that looks convincingly like the actual Bank of America front-page with a username/password field, an attacker could potentially convince some users that they really were looking at their bank's website and they might feel safe entering their username and password.  The user would have to click the select button in order to trigger the attack, so it requires some additional effort on the part of the attacker.  But in any case: select-popups-that-potentially-escape-the-content-area-and-cover-up-browser-UI give the attacker a very important tool that they can use to build an attack like this.

Given all that, I think this is WONTFIX since this is in fact things working-as-intended per bug 1276976.

Essentially the principle here is that the `<select>` menu-popup's content is controlled by an untrusted web page -- so out of an abundance of caution, it's best to constrain it to the rendering area of the web page.  Otherwise, attackers can craft sneaky attacks that use a <select> to cover up a piece of the browser UI and confuse the user.

The attack scenario in bug 1276976 involved a <select> that was crafted to pop upwards and cover up Firefox's URLbar, with the menu containing a menu-option that might confuse a user into thinking it's an actual website URL -- e.g. let's say it has a menu-option whose text is `🔒 https://bankofamerica.com`, which exactly covers up the area where the browser's URL bar would normally be.

With that sort of setup, and with a spoofed web page that looks convincingly like the actual Bank of America front-page with a username/password field, an attacker could potentially convince some users that they really were looking at their bank's website and they might feel safe entering their username and password.  The user would have to click the select button in order to trigger the attack, so it requires some additional effort on the part of the attacker.  But in any case: select-popups-that-potentially-escape-the-content-area-and-cover-up-browser-UI give the attacker a very important tool that they can use to build an attack like this.

Given all that, I think this is WONTFIX since this is in fact things working-as-intended per bug 1276976.

Essentially the principle here is that the `<select>` menu-popup's content is controlled by an untrusted web page -- so out of an abundance of caution, it's best to constrain it to the rendering area of the web page.  Otherwise, attackers can craft sneaky attacks that use a <select> to cover up a piece of the browser UI and confuse the user, with potentially security-critical results.

The attack scenario in bug 1276976 involved a <select> that was crafted to pop upwards and cover up Firefox's URLbar, with the menu containing a menu-option that might confuse a user into thinking it's an actual website URL -- e.g. let's say it has a menu-option whose text is `🔒 https://bankofamerica.com`, which exactly covers up the area where the browser's URL bar would normally be.

With that sort of setup, and with a spoofed web page that looks convincingly like the actual Bank of America front-page with a username/password field, an attacker could potentially convince some users that they really were looking at their bank's website and they might feel safe entering their username and password.  The user would have to click the select button in order to trigger the attack, so it requires some additional effort on the part of the attacker.  But in any case: select-popups-that-potentially-escape-the-content-area-and-cover-up-browser-UI give the attacker a very important tool that they can use to build an attack like this.

Given all that, I think this is WONTFIX since this is in fact things working-as-intended per bug 1276976.

Essentially the principle here is that the `<select>` menu-popup's content is controlled by an untrusted web page -- so out of an abundance of caution, it's best to constrain it to the rendering area of the web page.  Otherwise, attackers can craft sneaky attacks that use a <select> to cover up a piece of the browser UI and confuse the user, with potentially security-critical results.

The attack scenario in bug 1276976 involved a web page with a `<select>` that was crafted to pop upwards and cover up Firefox's URLbar, with the `<select>` menu containing a menu-option that might confuse a user into thinking it's an actual website URL -- e.g. let's say it has a menu-option whose text is `🔒 https://bankofamerica.com`, which exactly covers up the area where the browser's URL bar would normally be.

With that sort of setup, and with a spoofed web page that looks convincingly like the actual Bank of America front-page with a username/password field, an attacker could potentially convince some users that they really were looking at their bank's website and they might feel safe entering their username and password.  The user would have to click the select button in order to trigger the attack, so it requires some additional effort on the part of the attacker.  But in any case: select-popups-that-potentially-escape-the-content-area-and-cover-up-browser-UI give the attacker a very important tool that they can use to build an attack like this.

Given all that, I think this is WONTFIX since this is in fact things working-as-intended per bug 1276976.