Råvarefesten

Oljeprisen er nå over 110 dollar fatet. De fleste vil peke på uroen i Midtøsten og Nord-Afrika som hovedårsak. Mye tyder imidlertid på at det er helt andre mekanismer som ligger bak.

  

Kilde: http://www.indexmundi.com/commodities/

Opptøyene i Midtøsten startet for alvor på nyåret. Prisen på råolje lå imidlertid tett oppunder 100 dollar fatet allerede i desember i fjor. Det er derfor grunn til å tro at toppnoteringen har andre forklaringer.

En indikasjon på hva som er i ferd med å skje kan vi få ved å sammenligne med en mer generell råvareindeks. I figuren ser vi råoljeprisen plottet sammen med prisutviklingen på råvarer uten energi. Likheten mellom utviklingen i råoljeprisen og andre råvarer er slående. Siden april i fjor har faktisk andre råvarer steget mer enn oljeprisen.

Til tross for disse relativt entydige signalene på en generell råvarefest, ser vi stadig forsøk på bortforklaringer. Høy oljepris skyldes Gadaffi, høye hvetepriser skyldes feilslått innhøsting og stadig stigende byggpriser er kanskje spekulantenes feil.

Naturligvis vil både dårlig innhøsting og gale diktatorer kunne ha innvirkning på enkelte råvarer. Når vi ser en generell prisøkning slik som nå virker det imidlertid mer sannsynlig at det finnes mer grunnleggende årsaker. Prisoppgangen gjelder nemlig både kobber, kaffe, svin, storfekjøtt, sukker, soyaolje, aluminium og nær sagt alt annet. Det er usannsynlig at en slik bred oppgang skyldes annet enn en generell økning i etterspørsel.

Spekulanter ble tidlig beskyldt for å drive prisene på råvarer i taket. Forskning, blant annet fra finanskrisen, viser imidlertid at det ikke finnes grunnlag for slike påstander. Det virker også usannsynlig at spekulanter alene skulle kunne presse prisene opp på nær sagt alle råvarer. Å manipulere priser ved å trenge hele verdens råvaremarked inn i et hjørne er en særdeles risikabel strategi og ville krever enorme mengder kapital. En kan kanskje tenke seg at spekulanter kunne manipulere én råvare over en tidsbegrenset periode. At hedgefond og andre høyrisikoinvestorer skulle kunne manipulere den totale verdensetterspørselen etter råvarer i over ett år er imidlertid lite sannsynlig.

Prisene på råvarer er nå på god vei opp til toppen under finanskrisen. Det er særdeles gode nyheter. Enkelte har uttrykt bekymring for at de høye råoljeprisene vil knekke oppgangen i verdensøkonomien. Siden alt tyder på at oppgangen skyldes en generell økning i etterspørselen blir dette å sette saken på hodet. Prisene vi ser i dag er et tegn på at økonomien er i god bedring. En prisøkning er nødvendig for å ballansere den økende etterspørselen med det eksisterende tilbudet. Dette må til for å gi incentiver til å øke produksjonen ytterligere.
Litt mer interessant er det kanskje å se fremover. I figuren er også den amerikanske konsumprisindeksen tegnet inn. Det er relativt lett å se at det er en solid sammenheng mellom prisen på råvarer og konsumprisen. Det skulle naturligvis bare mangle. Konsumprisene er et resultat av bedriftenes kostnader, som i stor grad bestemmes av råvareprisene. Endring i råvarepriser er også et mer generelt tegn på økt etterspørsel, og økt etterspørsel fører normalt til økte konsumpriser.

Sist vi hadde en sterk økning i etterspørselen var frem mot finanskrisen. I ettertid kan det se ut som om sentralbankene da kom bakpå og satte opp rentene for sent og for mye. Det blir derfor interessant å se hva som kommer til å skje denne gangen. Når det gjelder råvarepriser ligner bildet mye på perioden før finanskrisen.

Spørsmålet er derfor hvor hardt sentralbankene denne gang vil bekjempe inflasjonen. I Storbritannia er allerede inflasjonen oppe i 4%. Produsentprisene stiger nå med over 5% i året. Det er langt over målet på 2%. Likevel holder sentralbanken fast på en rente på en halv prosent.

Det er fortsatt mye gjeld i både EU og USA. Mye av dette er statsgjeld. Fristelsen til å oppgi inflasjonsmålet må være stor. Det er i dag ustedet kolossale mengder statsobligasjoner. Inflasjon vil effektivt redusere denne gjelden. Dette vil redusere behovet for økte skatter samtidig som man slipper å ramme boligeiere med høy gjeld. Politisk kan det rett og slett bli en meget behagelig løsning å løsne litt på den rigide inflasjonsstyringen man har fulgt til nå.

Read More

Pwn2own considered (somewhat) harmful

I think that hacking challenges and bug bounty programs can be extremely valuable. This is true when they involve transparent, sustained efforts to evaluate the security of a particular platform. For example, I believe that there is a substantial value in Mozilla bug bounties, or in the Chrome reward program. These programs greatly improve the security of the browsers in question, occasionally advance our understanding of web security, and provide tons of statistical data about vendor response processes and attitudes toward security flaws. That last part is arguably the most important metric when dealing with code so complex that for better or worse, it is unlikely to ever be perfectly safe.

I also think that Pwn2own, an annual browser hacking contest run by TippingPoint, does not deliver the same value. The formula of the contest boils down to this: once a year, a single, secretly developed exploit is exchanged for a substantial amount of money. No information about the flaw or its back story is revealed in the process, and given that this trade is negligible in comparison to the annual volume of browser vulnerabilities, there is absolutely no intrinsic value in observing it.

That, alone, is not a compelling criticism; at best, it's a reason not to watch. But then, there are some negative consequences, too: it is in the interest of the conference and contest organizers, and the participating researchers, to get publicity for their findings - and journalists, who do not necessarily have a holistic view of the day-to-day browser security research, embrace such high-profile developments with disproportionate enthusiasm. The resulting ecstatic press coverage ultimately undermines any attempt to have a meaningful and reasonable discussion about the state of browser security.

Take this quote, which likely will be repeated in every Safari-related story for the next twelve months:

"A team was able to exploit Safari to exploit a MacBook Air in five seconds. Yes, five seconds - less time than it takes most people just to type 'Safari got hacked in less than five seconds'."

That's remarkable, but also completely wrong. It takes days or weeks to find and exploit a vulnerability, and Pwn2own is no exception: the actual exploits are prepared months or weeks in advance, and simply executed on the day the contest takes place. I do not think there is a single person in the information security industry who would say that the discovery of a normal browser vulnerability is a notable event: several hundred such flaws are discovered and resolved every year in every browser, as evidenced by release notes maintained by the vendors with varying degrees of accuracy. Neither the fact that somebody discovered a vulnerability before Pwn2own, nor that this person needed needed five seconds to execute that pre-made code, is a useful measure of anything.

Similarly, the survival of Firefox and Chrome intuitively makes me happy, because I know that these browsers give a lot of thought to security - but I do not think that Pwn2own is a meaningful testament to this. Perhaps these two vendors merely patched up the vulnerability somebody wanted to use, and there was not enough time to find a new one. Or perhaps nobody attending the event (which brings together only a tiny fraction of the infosec community) had the expertise and the inclination to target this particular browser.

Yes, there are vendors who lag behind the rest when it comes to vulnerability response and proactive security work; and there are some hard problems we still have to solve to make the web a safer environment. But the headlines inspired by Pwn2own (and probably encouraged by the organizers) are very unfair, and unnecessarily alienate the parties who should be paying attention to their security posture. Investigating real data, and asking some hard-hitting questions, can make more of a difference... and if done right, it can be more fun.

Read More

A note on an MHTML vulnerability

There is an ongoing discussion about a recently disclosed, public vulnerability in Microsoft Internet Explorer, and its significance to web application developers. Several of my colleagues investigated this problem in the past few weeks, and so, I wanted to share our findings.

As some of you may be aware, Microsoft Internet Explorer supports MHTML, a simple container format that uses MIME encapsulation (nominally multipart/related) to combine several documents into a single file. Each container may consist of a number of possibly base64-encoded documents, with their content type determined solely by the inline MIME data.

Perhaps by the virtue of not having cross-browser support, the MHTML format is not commonly used on the web - but it is employed by Internet Explorer itself to save downloaded pages to disk; and embraced by some third-party applications to deliver HTML-based documentation and help files.

To facilitate access to MHTML containers, the browser also supports a special mhtml: URL scheme, followed by a fully-qualified URL from which the document is to be retrieved; a "!" delimiter; and the name of the target resource inside the container. Unfortunately, when MHTML containers are accessed over protocols that provide other, normally authoritative means for specifying document type (e.g. Content-Type in HTTP traffic), this protocol-level information is ignored, and a very lax MIME envelope parser is invoked on the retrieved document, instead. The behavior of this parser is not documented, but it appears that in many cases, adequately sanitized user input appearing on HTML pages, in JSON responses, CSV exports, image metadata, and so forth, is sufficient to trick it into treating the underlying document as valid MHTML. All that is needed to keep this parser happy is the ability to place several alphanumeric and punctuation characters on the target page, in several separate lines.

The payload inside such an unintentionally served "MHTML container" is able to execute JavaScript, and has same-origin DOM access to the originating domain; with some minimal effort, it is also able to access to domain-specific cookies. Therefore, this behavior essentially represents a universal cross-site scripting flaw that affects a significant proportion of all sensitive web applications on the Internet.

Based on this 2007 advisory, it appears that a variant of this issue first appeared in 2004, and has been independently re-discovered several times in that timeframe. In 2006, the vendor reportedly acknowledged the behavior as "by design"; but in 2007, partial mitigations against the attack were rolled out as a part of MS07-034 (CVE-2007-2225). Unfortunately, these mitigations did not extend to a slightly modified attack published in the January 2011 post to the full-disclosure@ mailing list.

It appears that the affected sites generally have very little recourse to stop the attack: it is very difficult to block the offending input patterns perfectly, and there may be no reliable way to distinguish between MHTML-related requests and certain other types of navigation (e.g., <embed> loads). A highly experimental server-side workaround devised by Robert Swiecki may involve returning HTTP code 201 Created rather than 200 OK when encountering vulnerable User-Agent strings - as these codes are recognized by most browsers, but seem to confuse the MHTML fetcher itself.

Until the problem is addressed by the vendor through Windows Update, I would urge users to consider installing a FixIt tool released by Microsoft as an interim workaround.

Update: see this announcement for more.

Read More

The other reason to beware ExternalInterface.call()

Adobe Flash has a function called ExternalInterface.call(...), which implements a JavaScript bridge to the hosting page. It takes two parameters: the first one is the name of the JavaScript function to call. The second one is a string to pass to this function.

It is understood that the first parameter should not be attacker-controlled (of course, mistakes happen :-). It is also understood that there is no inherent harm in putting user input in the second parameter, if the callback function itself is not behaving stupidly; in fact, Adobe documentation gives an example that follows this very pattern:


  ...

  ExternalInterface.call("sendToJavaScript", input.text);

  ...


Such a call would be translated to an eval(...) statement injected on the embedding page. This statement looks roughly the following way:


  try {

    __flash__toXML(sendToJavaScript, "value of input.text"));

  } catch (e) {

    "<undefined/>";

  }


When writing the supporting code behind this call, the authors remembered to use backslash escaping when outputting the second parameter: hello"world becomes hello\"world. Unfortunately, they overlooked the need to escape any stray backslash characters, too.

So, try to figure out what happens if the value of input.text is set to the following string:


  Hello world!\"+alert(1)); } catch(e) {} //


I reported this problem to Adobe in March 2010. In March 2011, after following up, I received the following response:

"We have not made any change to this behavior for backwards compatibility reasons."

Caveat emptor :-)

Read More

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