5

In 2011, Eli Fox-Epstein demonstrated a Rule 110 machine in HTML + CSS3.

This led some to say that the combination of HTML + CSS3 is Turing complete.

Regardless of whether HTML + CSS3 is technically Turing complete, do any known exploits (in the wild, or published as proof-of-concept) attack browsers (not plug-ins, add-ons, etc) purely using HTML + CSS?

If so, please summarise at least one such exploit.

Community
  • 1
sampablokuper
  • 1,961
  • 1
  • 19
  • 33
  • I don't fully understand the phrase `Turing Complete` here, but am I right in saying it's a bit of a curve ball for this question? Are you simply asking if HTML+CSS alone are enough for somebody to deliver a payload/attack? –  May 19 '16 at 15:17
  • @JᴀʏMᴇᴇ, fair point. *"Are you simply asking if HTML+CSS alone are enough for somebody to deliver a payload/attack?"* Yes. But one of the security concerns about JavaScript, historically, was that because it is Turing complete, it provides attackers with much more scope to be malicious than would otherwise be the case. So, I am especially curious about HTML+CSS attacks that rest upon having those sorts of computational capabilities available in the language(s). – sampablokuper May 19 '16 at 16:33
  • @sampablokuper I think Javascript's security concerns are from its access to browser and network access and not it being Turing complete. Turing completeness only describes computation, not access – Neil Smithline May 19 '16 at 17:25
  • @NeilSmithline, we're both right. I should perhaps have made clear that I was referring to the browser context. Within that context, JavaScript has been considered much riskier than HTML+CSS, because of its greater computational capabilities. – sampablokuper May 19 '16 at 17:50

1 Answers1

8

Yes, in the past there have been lots of exploits that only relied on malicious HTML and CSS code.

You are right in that parsing a complex, turing-complete language is potentially more error-prone, giving an attacker more tools to craft an exploit. Yet, there are many different ways in which the implementation of the used CSS parser or other modules involved in processing the code can be vulnerable.

As an example, take CVE-2010-2752 - Mozilla Firefox CSS font-face Remote Code Execution Vulnerability. This vulnerability could be triggered simply by creating a website with specially crafted CSS font-face rules and yet it had the potential to compromise the host.

The flawed code was located in Mozilla's CSS parser and had a trivial bug: When allocating memory to store the font-face references, a 16-bit integer was used for the index. However, when the actual values were filled in, a 32-bit integer was used instead. This inconsistency led to an integer overflow when a stylesheet supplied an exessive number of external font references. Consequently, an attacker could write to unexpected memory locations and turn the index overflow into an arbitrary code execution exploit.

Since most of the Mozilla core is written in C++, there is no built-in overflow protection and developers are in charge of dealing securely with the memory. A browser written in Python would likely face very different types of vulnerabilities (and also be painfully slow).

Arminius
  • 43,922
  • 13
  • 140
  • 136