2 added 231 characters in body
source | link

Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy)... similar to EFF's SSL observatory

I think you have to first decide what kind of attacks you want to protect against. Will the attacker only be able to replace content of third party sites included in the main site (i.e. jquery.org) or will (s)he be able to modify the main site too?

If the attacker is only able to compromise third party sides a strict CSP and something like a JavaScript observatory might work, because you either forbid inclusion of third party script at all or restrict it to known good script (see also hashes for script-src which are implemented in Chrome 46).

But if the attacker is also able to modify content of the main site then this approach will probably only help for the few sites which have no inline-script, no user-dependent script and where the script changes only rarely. In practice JavaScript gets far more often changed than a certificate and you often have cases where the JavaScript served to a user is tailored to the user, i.e. depends on the session, account etc. This is not only true for inline script but also for script included with the script tag. Also you have lots of small script fragments included with onXXX attibute (i.e. onclick="dothis();") where not only the script code itself is relevant but also where this code is used in the HTML. Thus an observatory would not help herefor all but a few mainly static sites. 

NoScript XSS filter is flawed.

All XSS filters are limited as are all antivirus solutions. It is impossible to reliably distinguish between good and bad with the limited information these filters have about what good and bad for a specific site might be. Either thethey block too much (false positives) or they miss something (false negatives). In the first case the user will switch ofoff the filter and in the latter case it will not offer full protection. 

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc.

Yes, I would not consider the current security architecture of Firefox optimal and I think Chrome provides a better protection against exploits which try to break out of the browser. On the other hand as far as I know Chrome does not provide the API you need for the full checks done by NoScript (i.e. XSS prevention, clickjacking detection...).

Another approach would be to run the OS with the browser itself inside some virtual machine so that itthe attacker would neednot only to break out of thisthe browser but also out of the VM too to gain the relevant information. Each level of sandboxingseparation makes it harder for the attacker.

Could someone explain parts of the FBI's Firefox 0-day?

From the public available information it looks like they used Javascript to trigger a bug in the browser to inject shell code which then could do anything with the permissions of the user, including accessing hostname and MAC and sending this information to the attackers server. I cannot see from the public information which site they compromised and if the site was depending on script, if it used inline script etc. Thus it is unknown if your approach with the observatory and CSP would have protected the user in this case.

Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy)... similar to EFF's SSL observatory

I think you have to first decide what kind of attacks you want to protect against. Will the attacker only be able to replace content of third party sites included in the main site (i.e. jquery.org) or will (s)he be able to modify the main site too?

If the attacker is only able to compromise third party sides a strict CSP and something like a JavaScript observatory might work, because you either forbid inclusion of third party script at all or restrict it to known good script (see also hashes for script-src which are implemented in Chrome 46).

But if the attacker is also able to modify content of the main site then this approach will probably only help for the few sites which have no inline-script, no user-dependent script and where the script changes only rarely. In practice JavaScript gets far more often changed than a certificate and you often have cases where the JavaScript served to a user is tailored to the user, i.e. depends on the session, account etc. This is not only true for inline script but also for script included with the script tag. Thus an observatory would not help here.

NoScript XSS filter is flawed.

All XSS filters are limited as are all antivirus solutions. It is impossible to reliably distinguish between good and bad with the limited information these filters have about what good and bad for a specific site might be. Either the block too much (false positives) or they miss (false negatives). In the first case the user will switch of the filter and in the latter case it will not offer full protection.

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc.

Yes, I would not consider the current security architecture of Firefox optimal and I think Chrome provides a better protection against exploits which try to break out of the browser. On the other hand as far as I know Chrome does not provide the API you need for the full checks done by NoScript (i.e. XSS prevention, clickjacking detection...).

Another approach would be to run the OS with the browser itself inside some virtual machine so that it would need to break out of this too to gain the relevant information. Each level of sandboxing makes it harder.

Could someone explain parts of the FBI's Firefox 0-day?

From the public available information it looks like they used Javascript to trigger a bug in the browser to inject shell code which then could do anything with the permissions of the user, including accessing hostname and MAC and sending this information to the attackers server. I cannot see from the public information which site they compromised and if the site was depending on script, if it used inline script etc. Thus it is unknown if your approach with the observatory and CSP would have protected the user in this case.

Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy)... similar to EFF's SSL observatory

I think you have to first decide what kind of attacks you want to protect against. Will the attacker only be able to replace content of third party sites included in the main site (i.e. jquery.org) or will (s)he be able to modify the main site too?

If the attacker is only able to compromise third party sides a strict CSP and something like a JavaScript observatory might work, because you either forbid inclusion of third party script at all or restrict it to known good script (see also hashes for script-src which are implemented in Chrome 46).

But if the attacker is also able to modify content of the main site then this approach will probably only help for the few sites which have no inline-script, no user-dependent script and where the script changes only rarely. In practice JavaScript gets far more often changed than a certificate and you often have cases where the JavaScript served to a user is tailored to the user, i.e. depends on the session, account etc. This is not only true for inline script but also for script included with the script tag. Also you have lots of small script fragments included with onXXX attibute (i.e. onclick="dothis();") where not only the script code itself is relevant but also where this code is used in the HTML. Thus an observatory would not help for all but a few mainly static sites. 

NoScript XSS filter is flawed.

All XSS filters are limited as are all antivirus solutions. It is impossible to reliably distinguish between good and bad with the limited information these filters have about what good and bad for a specific site might be. Either they block too much (false positives) or they miss something (false negatives). In the first case the user will switch off the filter and in the latter case it will not offer full protection. 

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc.

Yes, I would not consider the current security architecture of Firefox optimal and I think Chrome provides a better protection against exploits which try to break out of the browser. On the other hand as far as I know Chrome does not provide the API you need for the full checks done by NoScript (i.e. XSS prevention, clickjacking detection...).

Another approach would be to run the OS with the browser itself inside some virtual machine so that the attacker would not only to break out of the browser but also out of the VM too to gain the relevant information. Each level of separation makes it harder for the attacker.

Could someone explain parts of the FBI's Firefox 0-day?

From the public available information it looks like they used Javascript to trigger a bug in the browser to inject shell code which then could do anything with the permissions of the user, including accessing hostname and MAC and sending this information to the attackers server. I cannot see from the public information which site they compromised and if the site was depending on script, if it used inline script etc. Thus it is unknown if your approach with the observatory and CSP would have protected the user in this case.

1
source | link

Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy)... similar to EFF's SSL observatory

I think you have to first decide what kind of attacks you want to protect against. Will the attacker only be able to replace content of third party sites included in the main site (i.e. jquery.org) or will (s)he be able to modify the main site too?

If the attacker is only able to compromise third party sides a strict CSP and something like a JavaScript observatory might work, because you either forbid inclusion of third party script at all or restrict it to known good script (see also hashes for script-src which are implemented in Chrome 46).

But if the attacker is also able to modify content of the main site then this approach will probably only help for the few sites which have no inline-script, no user-dependent script and where the script changes only rarely. In practice JavaScript gets far more often changed than a certificate and you often have cases where the JavaScript served to a user is tailored to the user, i.e. depends on the session, account etc. This is not only true for inline script but also for script included with the script tag. Thus an observatory would not help here.

NoScript XSS filter is flawed.

All XSS filters are limited as are all antivirus solutions. It is impossible to reliably distinguish between good and bad with the limited information these filters have about what good and bad for a specific site might be. Either the block too much (false positives) or they miss (false negatives). In the first case the user will switch of the filter and in the latter case it will not offer full protection.

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc.

Yes, I would not consider the current security architecture of Firefox optimal and I think Chrome provides a better protection against exploits which try to break out of the browser. On the other hand as far as I know Chrome does not provide the API you need for the full checks done by NoScript (i.e. XSS prevention, clickjacking detection...).

Another approach would be to run the OS with the browser itself inside some virtual machine so that it would need to break out of this too to gain the relevant information. Each level of sandboxing makes it harder.

Could someone explain parts of the FBI's Firefox 0-day?

From the public available information it looks like they used Javascript to trigger a bug in the browser to inject shell code which then could do anything with the permissions of the user, including accessing hostname and MAC and sending this information to the attackers server. I cannot see from the public information which site they compromised and if the site was depending on script, if it used inline script etc. Thus it is unknown if your approach with the observatory and CSP would have protected the user in this case.