Any not totally insecure browser vulnerable to BEAST?

Question

People still worry about BEAST quite a lot when configuring web servers to the point of preferring RC4 over AES-CBC. But most browsers mitigate BEAST even while using TLS 1.0.

Is there a browser that:

1. Is vulnerable to BEAST or to Lucky Thirteen
2. Doesn't have known vulnerabilities which are much worse, such as remote code execution
3. Has a non negligible user base

Is BEAST still a reason to avoid CBC? What about Lucky Thirteen?

Answer 1

It should be noted that BEAST requires some hostile code which runs on the victim's browser, code which is able to send arbitrary requests to the target Web site, with enough "control" on the sent bytes to pull off the CBC-related calculations. In particular, this cannot be "just text". The BEAST authors had to find some sort of channel which would evade the Same-Origin Policy. They found two:

• one in Java, which has been fixed soon afterwards (and unfixed Java plugins have other, bigger holes);
• one in a draft version of WebSocket, which was never widespread (being draft) and has been fixed; actually, it was already fixed when the attack was published, although the fix was serendipitous (it was a change which was meant for protecting against something else).

Arguably, BEAST cannot be exploited nowadays unless another SOP hole is found. Moreover, even if such a SOP hole is found, current browsers to the 1/n-1 split which also prevents BEAST from being applicable. This method has been applied in major Web browsers more than one year ago (see this) and I don't believe that there was no remote-execution bug found in these browsers in the last year. This would mean that, indeed, there is no reason to worry about BEAST anymore. Switching to TLS 1.2 would still be good nonetheless.

The Lucky Thirteen attack is, arguably, not an attack on the browser but on the server. It requires the browser to engage in a lot of requests to the server (in a BEAST-similar setup), but the leak comes from the server: the server processes an incoming record, and the MAC verification will fail, but some subtle timing measure may reveal whether the PKCS#5-like padding was correct or not. It is claimed that almost all vendors (at least the open-source ones) fixed their code to avoid the leak that Lucky Thirteen relies on.

Web browser brand and version has little relevance to the Lucky Thirteen. Theoretically, one could reverse the setup and attack the processing of records sent by the server to the client, but it would require that the attacker has sufficient control over the server's responses to make the attack work, and that seems quite hard.