Warning: OBJECT and EMBED are inherently unsafe

Let's say that you maintain an online discussion forum. Assuming that you explicitly specify the type= parameter in your <object> or <embed> markup, what are the security consequences of allowing users to embed third-party Flash movies in their posts when you enforce the appropriate security restrictions on your end (allowScriptAccess, allowNetworking, allowFullScreen all set to none)? Or, to make things simpler, how about permitting a straightforward video file, with type=video/x-ms-wmv?

If you think this is safe, you may want to know that the HTML5 spec has a different view. The specification effectively takes away the ability for any single party to decide how a particular plugin document should be handled by the browser. Under the new algorithm, instead of your funny cat video, you may accidentally end up embedding Java, which has unconditional access to the DOM of the embedding page through DOMService. Whoops, looks like you are owned now.

According to the spec, if your visitor's browser has, say, a Windows Media Player plugin that recognizes the type=video/x-ms-wmv value on your webpage, that plugin will be used regardless of Content-Type. This part is intuitive. Alas, if the plugin is not found, the specification compels the software to look at Content-Type next, giving the hosting party an opportunity to override the intent specified on your end.

To further complicate the picture, in some circumstances, browsers may also ignore both type= and Content-Type values: for example, Internet Explorer and WebKit browsers will play Flash videos served with Content-Type: pants/whatever and loaded with type=certainly/not-flash just because a stray .swf file extension is spotted somewhere in the URL. The file name signal is problematic, as it can usually be tampered with by whoever provides the URL. This strategy brings a yet another player into the picture, and each party can sabotage the security assurances sought by the rest.

It would be more reasonable to keep the behavior of <object> and <embed> consistent with that of other type-specific subresource tags (e.g., <applet>, <img>, or <script>), and give control over how the document is rendered to whoever authored the markup. This approach is still not without peril, because it makes it impossible for some sites to indicate that a particular text/plain or image/jpeg response is not meant to be interpreted as a malicious applet. But that last problem can be fixed by requiring Content-Type and type= to match, perhaps through an opt-in mechanism controlled with a new HTTP header. And in any case, the proposed logic does not help.

In the end, the currently specified behavior seems highly counterintuitive, and undoes all the work plugin that vendors such as Adobe or Microsoft put into adding security controls to ensure that their plugin content is reasonably safe to embed across domains that do not fully trust each other.

Test cases here. Joshua Stein also reports that they confuse Flash-blocking tools.

Read More

Possibly the most fascinating HTML parser behavior ever

I learned about this tidbit from sirdarckcat. It is in no way new, but the trick is so cute that I just could not resist sharing.

When parsing HTML documents, browsers recognize two methods of specifying tag parameter values: a "bare" form (such as <img src=image.jpg>), which is terminated by angle brackets, whitespaces, and so on; and a quoted form (<img src="image.jpg">) which is terminated only by a matching quote.

Every browser makes the decision by looking at the first non-whitespace character after the name=value separator. If this happens to be a single or a double quotation mark, the second parsing strategy is used; otherwise, the first method is a go. Internet Explorer also recognizes backticks (`) as a faux quote, leading to security flaws in a fair number of HTML filters - but even with this quirk, the behavior is still pretty straightforward. In particular, in the following example, stray quotes will not have any effect on how the tag is interpreted:

<a href=http://www.example.com/?">This text is not a tag parameter anymore.">Click me</a>

But here's the thing: Internet Explorer seems to be doing a substring search for an equals sign followed by a quote anywhere in the parameter name=value pair. Therefore, the following syntax will be parsed in a very different way:

<a href=http://www.example.com/?=">This is still a part of markup indeed!">Click me</a>

It's one of the most unique and surreal HTML parser quirks I am aware of (and it survives to this day in Internet Explorer 9). In principle, it allows any server-side HTML filter to get out of sync with the browser, leading to parameter splitting and tag consumption. In reality, it has a limited practical significance: if your HTML filter is relaxed enough to allow this syntax to go through, it is probably already vulnerable to the abuse of other syntax tricks.

Read More

The dreaded curse of openness

Several weeks ago, the chairman of Trend Micro had this to say:

"Android is open-source, which means the hacker can also understand the underlying architecture and source code. We have to give credit to Apple, because they are very careful about it. It's impossible for certain types of viruses to operate on the iPhone."

Now that Kaspersky has, ahem, joined the open source crowd - I worry that hackers may soon be able to understand the operation of anti-virus software as well. And beyond that unthinkable point, only darkness looms.

Read More

Dobbel Kina-gevinst

Det ser ut til at Elkem blir solgt til kinesere. Når en virksomhet selges skjer det fordi den har større verdi for kjøperen enn for eieren. I dette tilfellet ser kan det være muligheten til å ”stjele” teknologi til Kina som gjør denne handelen fordelaktig for både kjøper og selger.

Kina har til nå i hovedsak fått overført teknologi gjennom utenlandske investeringer i Kina. Resultatet har vært en enorm velstandsutvikling. Minst like viktig er imidlertid Kinas bidrag til verdensøkonomien. Kinas voldsomme vekst har gitt seg utslag i billigere varer, og har sannsynligvis bidratt betydelig til den økonomiske veksten som vesten har hatt det siste tiåret, finanskrisen til tross.

Miraklet Kina illustrer det enorme potensialet i internasjonalt krysseierskap. Direkte utenlandske investeringer medfører overføring av teknologi og kompetanse mellom land. Land med liten teknologisk utvikling tjener på det ved at man kan produsere mer og billigere med samme arbeidskraft. Landene som eksporterer teknologien tjener på det i form av velferdsøkning ved at varer blir billigere. Dette gir ikke bare rom for økt privat forbruk, men også økt offentlig forbruk dersom myndighetene ønsker å prioritere det.

Teknologi er i det hele tatt et gode som ikke forringes av at man deler på det. Tvert i mot øker verdien av teknolog med utbredelse. De som utvikler teknologi må imidlertid ha betalt for arbeidet, hvis ikke vil utvikling stoppe opp. Derfor er det viktig at oppfinnerne får sin betaling. Når utviklingskostnadene er betalt er det imidlertid ingenting som er bedre enn at teknologien spres så vidt som mulig.

Det er derfor usedvanlig sneversynt å frykte kinesisk plyndring av Elkems teknologi. Det beste som kan skje er at denne teknologien tas med til kina og benyttes til å effektivisere silisiumproduksjonen der. Dette kan vi få tilbake mange ganger i form av lavere priser på elektrovarer.
Det er jo heller ikke slik at kineserne kan stjele teknologien. Teknologien er en del av prisen som betales. Om salget går igjennom vil altså kineserne eie teknologien, og det er som kjent vanskelig å stjele noe du selv eier.

Det er også naivt å tro at nasjonalt eierskap har avgjørende betydning for lokalisering av virksomhet. Når kostnadsforskjellene er små vil man kanskje foretrekke å ha produksjonen hjemme. Aksjonærene ville nok likevel ha protestert kraftig dersom styret hadde sløst bort halvparten av utbyttet på et prinsipp om nasjonal lokalisering. Kineserne har sag at de vil beholde eksisterende norsk industri så lenge det er lønnsomt og legge ny industri til Asia, hvilket vel er omtrent det samme som de nåværende eierne hadde tenkt.

Enkelte har likevel tatt til orde for et statlig næringsfond som kunne sørget for norsk eierskap i norske industribedrifter. Et slikt næringsfond vil riktig nok kunne hindret utflytting av industriarbeidsplasser, men det spørs om skattebetalerne vil være villige til å ta den regningen. Det har trolig aldri eksistert et statlig næringsfond i Norge som har gitt meravkastning, og det er vel ingen grunn til å tro at et fond med en filosofi om å stoppe utviklingen vil være noe unntak her.

Staten har en viktig rolle i utviklingen av næringslivet, men man bør kanskje flytte fokus fra arbeidsplassbevaring til jobbskaping. Den kanskje viktigste rollen er å legge til rette for kompetanse i norske bedrifter. Slik kompetanse kommer imidlertid ikke i form av patenter eller industrihemmeligheter, men i form av utdannelse.

Det er et faktum at norske lønninger er for høye for en del industrivirksomhet, selv om ikke alle norske arbeidsplasser kan klassifiseres som kunnskapsintensive. Dette bør vi være glad for, og det er kun mulig fordi vi er mer produktive enn andre land. Det skyldes i stor grad høyt utdannelsesnivå. Om man ønsker lav ledighet og økonomisk vekst må man derfor utdanne kandidater der utdannelsen kaster best av seg. Det vil si der produktiviteten og lønningene er høyest.

Read More

Announcing cross_fuzz, a potential 0-day in circulation, and more

I am happy to announce the availability of cross_fuzz - a surprisingly
effective but notoriously annoying cross-document DOM binding fuzzer that
helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more.

The fuzzer owes much of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection mechanisms.

Detailed cross_fuzz fuzzing algorithm:

1. Open two windows with documents of any (DOM-enabled) type. Simple HTML, XHTML, and SVG documents are randomly selected as targets by default - although any other, possibly plugin-supported formats could be targeted instead.
   

   
   

2. Crawl DOM hierarchy of the first document, collecting encountered object references for later reuse. Visited objects and collected references are tagged using an injected property to avoid infinite recursion; a secondary blacklist is used to prevent navigating away or descending into the master window. Critically, random shuffling and recursion fanout control are used to ensure good coverage.
   

   
   

3. Repeat DOM crawl, randomly tweaking encountered object properties by setting them to a one of the previously recorded references (or, with some probability, to one of a handful of hardcoded "interesting" values).
   

   
   

4. Repeat DOM crawl, randomly calling encountered object methods. Call parameters are synthesized using collected references and "interesting" values, as noted above. If a method returns an object, its output is subsequently crawled and tweaked in a similar manner.
   

   
   

5. Randomly destroy first document using one of the several possible methods, toggle garbage collection.
   

   
   

6. Perform the same set of crawl & tweak operations for the second document, but use references collected from the first document for overwriting properties and calling methods in the second one.
   

   
   

7. Randomly destroy document windows, carry over a percentage of collected references to the next fuzzing cycle.
   

This design can make it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs.

I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority.

The following summarizes notification and patch status for all the affected vendors:

• Internet Explorer: MSRC notified in July 2010. Fuzzer known to trigger several clearly exploitable crashes (example stack trace for CVE-2011-0346) and security-relevant GUI corruption issues (XP-only, example, CVE-2011-0347). >Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties.
  

  Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided a compelling explanation as to why these issues could not have been investigated earlier, I refused; see this timeline for more.
  

  
  

• All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk.
  

  
  

• Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, 50 additional bugs identified (generally with no specific attribution at patch time). Several elusive crashes still occurring on trunk. Bad read / write offset crashes in npswf32.dll can also be observed if the plugin is installed.
  

  
  

• Opera: vendor notified in July 2010. Update provided in December states that Opera 11 fixed all the frequent crashes, and that a proper security advisory will be released at a later date (release notes list a placeholder statement: "fixed a high severity issue"). Several tricky crashes reportedly still waiting to be resolved.

  Note that with Opera, the fuzzer needs to be restarted frequently.
  

Well, that's it. To download the tool or see it in action, you can follow this link. The fuzzer may be trivially extended to work with any other DOM-compliant documents, plugin bindings, and so forth.

Read More

Firefox 3.6.13: damn you, corner cases

Today's release of Firefox 3.6.13 fixes bug 602780 (CVE-2010-3774) - an interesting problem I originally reported to Mozilla in October. It's a fun one, so here's a quick recap of what it is about.

As you may recall, one of the more significant shortcomings of the same-origin policy is that it does not give any guidance on handling documents with no inherent origin associated - that is, it fails to account for all the content coming from about:, data:, file:, and similar pseudo-URLs. Consequently, early implementations of this security model simply allowed all origin-less frames or windows created by one site to be accessed freely across domains - an empty host name string equals any other empty host name string, after all. As can be expected, this approach proved to be a bad idea - and since then, quite a few necessary improvements have been made. Today, every pseudo-URL should either inherit its origin from the parent document, or be assigned a completely unique one.

Alas, in Firefox, some of this logic would not work as expected in a handful of corner cases; this problem probably traced back to a minor code refactoring somewhere in 2008. The vulnerability would not trigger with about: or data: subframes on legitimate sites - and therefore, would not affect normal browsing - but with some minimal effort, it could be leveraged by malicious sites to access and modify the contents of internal browser pages, such as about:config, about:neterror, and so forth.

The consequences of access to about:config can be disastrous, but in this case, are somewhat mitigated by the fact that under standard operating conditions, random Internet-originating content can't open that location directly. In other words, the vulnerability could not be exploited without soliciting a degree of user interaction.

The story with pages such as about:neterror is a bit more interesting, though: in modern versions of Firefox, these documents are shown in place of the old-fashioned modal dialogs to indicate navigation errors. Crucially, when this happens, the content is displayed with the intended destination URL, rather than the true origin (about:...), shown in the address bar. With this simple trick in mind, the attacker can inject his spoofed content into a window where the address bar incorrectly points to an unrelated domain of his choice. Whoops!

If you haven't upgraded to 3.6.13 yet, check out this bombastic demo to see the attack in action.

Read More

Weekend distractions: DHS threat level indicator

Cool vulnerability in Firefox coming up next week. In the meantime, enjoy this project of mine:

• DHS tribute threat level indicator
  

Yup. The name says it all.

Read More