An origin is forever

This post is inspired chiefly by the work of Artur Janc.

The Internet is a pretty seedy place, yet we are quite willing to hand over our secrets to a small group or trusted web apps. Heck, in recent years, we also started giving them capabilities: social networking sites often get to see your geolocation, and your instant messenger may be able to access your microphone or webcam feeds. Some of this does not even require your initial consent: certain browsers and plugins come with hardcoded domains that are permitted to install software updates, or change system settings at a whim.

The push toward web application capabilities is somewhat frightening once you realize that the boundaries between web applications are very poorly defined, and that nobody is trying to solve that uncomfortable problem first. Look at the scoping rules for JavaScript DOM access, for HTTP cookies, and for auxiliary mechanisms such as password managers: they not only differ substantially, but routinely interfere with each other in destructive ways. Compartmentalizing complex web applications should be a breeze, but instead, it's an impenetrable form of art.

Worse, content isolation on the web is very superficial - so even if the boundaries can be drawn, most types of privileged contexts can't distance themselves from the rest of the world, and expose just a handful of well-defined APIs. Instead, every non-trivial web application needs to heavily compensate for the risk of clickjacking, cross-request forgery, reflected cross-site scripting, and dozens of other attacks of that sort. All the developers eventually fail, by the way: show me a domain with no history of XSS, and I will show you a web application nobody cares about.

Unlike some other tough challenges in browser engineering, the risks of living with privileged applications could mitigated fairly nicely simply by requiring some effort up front: even without inventing any new security mechanisms, you could require applications to use origin cookies, have a sensible CSP policy, and use HSTS, before being allowed to prompt for extra privileges. It's not impossible to do something meaningful - it's just unpopular with the creators of privileged APIs.

But the problems with the clarity of robustness of application boundaries aside, there is also a third, perhaps more fascinating issue: what do you do if your web application execution context becomes corrupted in some way? As it turns out, there is no mechanism for the server to say that from now on, it wants to have a clean slate, and that the browser should drop or at least isolate any already running code, or previously stored data.

This seemingly odd wish is actually critical to web application security. For example, let's assume there is an XSS vulnerability in a web mail system or a social networking application. Because of the convenient but unfortunate design of HTML, such vulnerabilities are unavoidable, but we seldom wonder if it's possible to cleanly and predictably recover from them. Intuitively, patching the underlying bug, invalidating session cookies, and perhaps forcing password change, is all it should take; in fact, applications using httponly cookies can often skip the last two steps.

Alas, an once-compromised web origin can stay tainted indefinitely. At the very minimum, the attacker is in full control for as long as the user keeps the once-affected website open in any browser window; with the advent of portable computers, it is not uncommon for users to keep a single commonly used website open for weeks. During that period, there is nothing the legitimate owner of the site can do - and in fact, there is no robust way to gauge if the infection is still going on. And hey, it gets better: if content from the compromised origin is commonly embedded on third-party pages (think syndicated "like" buttons or advertisements), with some luck, attacker's JavaScript may become practically invincible, surviving closing the original application and the deletion of browser cache. If that doesn't give you a pause, it should.

And let's not forget open wireless networks: the problem there is about as bad. It does not matter that you are not logged into anything sensitive while visiting Starbucks. An invisible frame, a strategic write to localStorage, or a bit of DNS or cache poisoning, is all it takes for the attacker to automatically elevate his privileges the moment you return to a safe environment and log back in.

With all that, and with the proliferation of mechanisms such as web workers and offline apps, we are rapidly approaching a point where recovering from a trivial XSS bug and other common web security lapses is getting almost as punishing as recovering from RCE - and for no good reason, too. Sure: today, it's so easy to phish users or exploit real RCE bugs, that backdooring web origins is not worth the effort. But in a not-too-distant future, that balance may shift.

Read More

Strukturerte produkter

Vi venter nå på dom fra lagmannsretten i saken mellom Ivar Petter Røeggen og DnB. I 2000 investerte Røeggen i et såkalt strukturert produkt. 73% av investeringen ble så satt på en høyrentekonto. De resterende 27% ble brukt til å kjøpe en opsjon som ville gi avkastning dersom markedet gikk opp. Om markedet gikk ned ville opsjonen være verdiløs.

I løpet av tegningsperioden ville så bankinnskuddet forrente seg slik at det til slutt ville tilsvare nøyaktig det investerte beløpet. På denne måten var Røeggen garantert det opprinnelige innskuddet dersom opsjonen skulle vise seg å bli verdiløs.

Allerede her hadde imidlertid produktet en katastrofal svakhet. Renten som banken måtte betale for å sikre minimumsbeløpet lå nesten halvannen prosent under fastrenten som banken garantert kunne oppnå i rentemarkedet. Hvert år tok altså DnB betalt 1,4% bare for å ha penger stående på en høyrentekonto. Når vi i tillegg vet at Røeggen og mange andre belånte mye av investeringen, blir regnestykket enda verre. Differansen mellom innskuddsrenten og lånerenten var på hele 2,5%. I og med at låne ble satt rett inn på konto i samme bank foregikk det ingen reelle transaksjoner mellom kunde og bank. Hvert år mottok altså DnB 2,5% bare for å føre pluss på én konto og minus på en annen. Dette må ha vært et fantastisk produkt for DnB.

Norsk Regnesentral fant riktig nok at en lang rekke slike produkt ikke kom så galt ut sammenlignet med aksjeindeksen og bankinnskudd når man så på realisert avkastning i ettertid. Beregninger gjort i ettertid har imidlertid begrenset verdi. For å kunne si noe om investeringene i strukturerte produkter var hensiktsmessige da de ble gjort, må man regne ut forventet avkastning på investeringstidspunktet og renten en bør sammenligne med er fastrenten i investeringsperioden. For produktet i denne saken kan man regne ut at forventet avkastning var 7,7% per år basert på avkastningen til Dow Jones EURO STOXX 50 (den største investeringen til fondet) siden 1987. Hadde man heller investert opsjonsdelen direkte i indeksen og resten i et fastrenteprodukt ville forventet avkastning blitt 8,6%.

I tillegg til dårlig rente var også opsjonsdelen av produktet et problem. Investerer man i opsjoner, bullfond eller tilsvarende derivater må man hvert år betale en ikke ubetydelig sum i noe som best kan sammenlignes med en forsikringspremie. En opsjon vil nemlig reduseres i verdi hvert eneste år selv når aksjekursene ikke faller.

Vi vet at fasiten var at børsindeksen falt og at Røeggen dermed fikk bruk for den forsikringen han hadde betalt premie for. Man skulle derfor tro at produktet i alle fall hadde klart seg bedre enn en investering i indeksfond i dette konkrete tilfellet, når tapet tross alt ble begrenset av nedsidegarantien slik intensjonen var?

Svaret er imidlertid nei. Røeggen tapte selv når produktets garanti kom til anvendelse på grunn av høye rentekostnader. Om han hadde investert direkte i indeksen hadde han oppnådd en avkastning på 27% før omkostninger på investeringen. Det er mindre enn hva et fastrenteprodukt ville gitt på den tiden, men betydelig mer enn sluttresultatet som ble 0.

Opsjoner generelt har blitt oversolgt av banker og finansinstitusjoner. Det er usikkert hvorfor det har skjedd, men det kan ha med utviklingen av finansfaget. I 1973 ble artikkelen som beskriver hvordan man prissetter opsjoner publisert. Formlene slo umiddelbart an på Wall Street og bruk av opsjoner og andre derivater i finansverden eksploderte.

Siden hele hensikten med å investere i aksjer er å ta risiko og få betalt for det over tid, virker imidlertid ideen om å kjøpe forsikring for investeringsbeløpet litt pussig. Om man ikke er beredt til å tape bør man ikke forsikre seg, men heller investere et mindre beløp.

Read More

Critical (of) severity

You can tell when a person is desperate to appear authoritative: they often litter their speech with unnecessary, roundabout verbiage. To some listeners, this sounds smart. To many others, it's obtuse and pompous.

I think that one of the cornerstones of vulnerability management is just an example of that. I am talking about the concept of vulnerability severities: I believe that they serve no real purpose, other than obfuscating the true intent of speech.

It's not that we don't need a codified taxonomy; but the term "severity" and the abstract levels attached to it ("critical", "high", "medium", "low") are a remarkably poor proxy for what we actually want to say.

The notion of severity is used in two distinct settings:

• In a position of authority: For example, when an internal security team is communicating with developers. In this case, the intent of assigning severity is to instruct the developer to do one of the following:

  
  

  
  
  • Drop all other work and fix the bug now.
    
  • Fix the issue in a couple of days.
    
  • Fix at own leisure, or not at all.

    
    

  
  
• In an advisory position: Say, when a vendor is notifying end users about the availability of a fix. In this case, the actual message usually is any of the following:

  
  

  
  
  • You are in imminent danger. Patch now.
    
  • You are at a limited risk, but prompt action is advisable.
    
  • We don't think there is a substantial risk.
    
  
  

Every time, the messages are very simple. Yet, instead of just saying them out loud, we create one set of guidelines for the security team to map their assessments to ambiguous codewords; and then furnish another, lengthy phrasebook for the final recipient of a message, to map the codeword back to something they can act upon.

Only we're not running a numbers station: we're trying to tell people something very important, and we need all of them to understand us right away. There is no way around the fact that terms such as "critical" or "high" intuitively mean different things to different people, and almost certainly do not map precisely to the thing you actually wanted to say. If the severity needs to be accompanied with several pages of organization-specific explanatory text, something is horribly wrong.

Instead of "highly critical", start telling your users "patch right away".

Read More

So you want to write a security book?

Now that I am done with my side project, I wanted to post a note about something that my colleagues frequently ask about: the reality of publishing a security-themed book.

The most important advice I can give is to start with a reality check: writing for technical audiences will probably not make you rich. You will invest somewhere between 200 and 1,000 hours of work over the course of several months. In the next two years, you will likely sell from 1,000 to 50,000 copies (10,000 is pretty good already). Your cut is between $2 and $5 per copy (that's 10-20% of the actual sale price, which in turn is usually around 50% of the cover price); proportionally less if there are multiple authors involved.

The bottom line is that your motivation needs to be something other than money. If there are no quality, up-to-date reference materials in your field of expertise, or if you just have something interesting to share, go for it. If you just want to earn some cash, random consulting gigs would net you more.

If you are still serious about the plan, the next step is choosing between a traditional publisher, and doing all the work yourself. I recommend the former. There are some reputable self-published security books (say, Fyodor's), and if you pursue this route, you will be able to get a slightly larger slice of the revenue pie. That said, you lose some important benefits:

• You will not get professional editorial feedback. Having an independent sanity check from a person who publishes books for a living helps you set the style and flow of the chapters, and arrange them reasonably. This is harder than it seems. Even the best ideas look bad when presented poorly.
  

  
  

• You will have to take care of technical illustrations, page layout, indexes, and so on - requiring some talent, and easily adding 50-100 hours of work into the mix.
  

  
  

• You will have to pay for technical editing and proofreading - or ship the book with typos and grammar errors, which never helps.
  

  
  

• You will have to invest some effort into marketing, accounting, etc.
  
  

If you have a decent proposal, you can approach publishers out of the blue, and pick the one you want to work with; for time being, the demand for infosec authors seems to be higher than the supply. All the publishers will all offer you roughly the same financial terms, but there are some interesting differences in what you will get in return. I know quite a few authors signed up with one of the major publishing houses, and very unhappy about not receiving any editorial attention past the first chapter or two; or not being able to get an illustrator assigned to the project, and having to do the work themselves. In these cases, one has to wonder what the publisher is doing to earn its fees.

So, ask around. For example, in comparison to said publisher, my experiences with
No Starch Press have been very good.

Read More

The subtle / deadly problem with CSP

Content Security Policy is a promising new security mechanism deployed in Firefox, and on its way to WebKit. It aims to be many things - but its most important aspect is the ability to restrict the permissible sources of JavaScript code in the policed HTML document. In this capacity, CSP is hoped to greatly mitigate the impact of cross-site scripting flaws: the attacker will need to find not only a markup injection vulnerability, but also gain the ability to host a snippet of malicious JavaScript in one of of the whitelisted locations. Intuitively, that second part is a much more difficult task.

Content Security Policy is sometimes criticized on the grounds of its complexity, potential performance impact, or its somewhat ill-specified scope - but I suspect that its most significant weakness lies elsewhere. The key issue is that the granularity of CSP is limited to SOP origins: that is, you can permit scripts from http://www1.mysite.com:1234/, or perhaps from a wildcard such as *.mysite.com - but you can't be any more precise. I am fairly certain that in a majority of real-world cases, this will undo many of the apparent benefits of the scheme.

To understand the problem, it is important to note that in modern times, almost every single domain (be it mozilla.org or microsoft.com) hosts dozens of largely separate web applications consisting of hundreds of unrelated scripts - quite often including normally inactive components used for testing and debugging needs. In this setting, CSP will prevent the attacker from directly injecting his own code on the vulnerable page - but will still allow him to put the targeted web application in a dangerously inconsistent state, simply by loading select existing scripts in the incorrect context or in an unusual sequence. The history of vulnerabilities in non-web software strongly implies that program state corruption flaws will be exploitable more often than we may be inclined to suspect.

If that possibility is unconvincing, consider another risk: the attacker loading a subresource that is not a genuine script, but could be plausibly mistaken for one. Examples of this include an user-supplied text file, an image with a particular plain-text string inside, or even a seemingly benign XHTML document (thanks to E4X). The authors of CSP eventually noticed this unexpected weakness, and decided to plug the hole by requiring a whitelisted Content-Type for any CSP-controlled scripts - but even this approach may be insufficient. That's because of the exceedingly common practice of offering publicly-reachable JSONP interfaces for which the caller has the ability to specify the name of the callback function, e.g.:

GET /store_locator_api.cgi?zip=90210&callback=myResultParser HTTP/1.0
...

HTTP/1.0 200 OK
Content-Type: application/x-javascript
...
myResultParser({ "store_name": "Spacely Space Sprockets",
                 "street": ... });

Having such an API anywhere within a CSP-permitted origin is a sudden risk, and may be trivially leveraged by the attacker to call arbitrary functions in the code (perhaps with attacker-dependent parameters, too). Worse yet, if the callback string is not constrained to alphanumerics – after all, until now, there was no compelling reason to do so – specifying callback=alert(1);// will simply bypass CSP right away.

The bottom line is that CSP will require web masters not only to create a sensible policy, but also thoroughly comb every inch of the whitelisted domains for a number of highly counterintuitive but potentially deadly irregularities like this. And that's the tragedy of origin scoping: if people were good at reviewing their sites for subtle issues, we would not be needing XSS defenses to begin with.

Read More

Spekulanter som saboterer

Finansmarkedet er som kjent svært effektivt i den forstand at det er ekstremt vanskelig å tjene penger i markedet uten å ta risiko. Det er godt dokumentert at aktiv forvaltning ikke lønner seg. Vår forståelse for hvordan markedet fungerer har imidlertid utviklet seg betydelig siden den banebrytende kapitalverdimodellen (CAPM) kom på begynnelsen av 60-tallet.

CAPM sier at en aksjes avkastning kun avhenger av markedsavkastningen over tid. Vi vet imidlertid at ting som selskapsstørrelse, bokverdi i forhold til markedspris, selskapets investeringer, fjorårets avkastning etc. påvirker gjennomsnittlig avkastning. I det hele tatt øker bare antallet bevis mot kapitalverdimodellene for hvert år som går. 

Når det er vist at en med relativt enkle strategier kan slå indeksen så burde etterspørselen etter for eksempel småselskapene øke inntil prisen er så høy i forhold til utbyttet at fortjenesten forsvinner. Enhver feilprising burde derfor fordunste så snart den blir offentlig kjent, og kapitalverdimodellen fra 60-tallet burde holde.

Akademia er derfor litt i villrede om hva disse avvikene fra standardmodellen skyldes. Det må imidlertid i hovedsak være ett av to: Enten kan det være at mange aksjer rett og slett er feilpriset eller så er meravkastningen kompensasjon for ukjent risiko.  

Dersom bruddene på kapitalverdimodellen rett og slett skyldes feilprising i markedet, så er det dårlig nytt for investorer som ønsker å utnytte det. Man kan rett og slett ikke stole på at markedet skal fortsette å gjøre elementære feil over tid. Det finnes i dag et børshandlet fond for hvert slikt avvik, så det mangler ikke på muligheter til å utnytte dem. Figuren viser da også hvor ustabile et par velkjente strategier kan være. SML-strategien har sågar gitt negativ avkastning i en lengre periode på 90-tallet.

Kilde: Kenneth Frenchs hjemmeside og egne beregninger. Data fra det amerikanske aksjemarkedet (CRSP)

• SMB viser hvor mye man kan tjene på å vekte seg opp i små selskaper og vekte seg ned i store selskaper.
• HML viser hvor mye man kan tjene på å vekte seg opp i “undervurderte” selskaper med høy bokverdi i forhold til aksjekurs, og vekte seg ned i “overvurderte” selskaper.
• Figuren viser ti års glidende gjennomsnitt. 
• I grafikken i DN ble dessverre HML og SMB byttet om i figuren.

Alternativt er meravkastningen en kompensasjon for en eller annen type risiko. Det kan hende investorer forsøker å holde seg unna små aksjer fordi de anses som mer risikable. Paradokset er at vi ikke finner igjen denne risikoen når vi analyserer aksjene over mange år. 

Det finnes imidlertid en plausibel forklaring på det vi observerer. I 2007 foreslo to av de mest kjente finansøkonomene, Eugene Fama og Kenneth French at feilene med CAPM rett og slett kunne skyldes uenighet mellom investorer. 

La oss tenke oss at det er to grupper investorer. Den ene gruppen består av rasjonelle langsiktige investorer med full informasjon og kompetanse til å prise alle selskapene i økonomien. Den andre gruppen består av spekulanter som ikke vet sitt eget beste og kjøper og selger aksjer i hytt og pine. Prisene på aksjene i en slik økonomi vil da være et vektet gjennomsnitt av hva hver av disse to gruppene verdsetter dem til.  Desto flere utilregnelige spekulanter, desto mer feilprising. 

De som kjenner til spillet “Vil du bli millionær” vet at ett av hjelpemidlene er å spørre publikum. Det viser seg imidlertid at dersom deltakeren eksplisitt ber alle som ikke har peiling om ikke å stemme, så blir publikums svar langt mer presis. Slik fungerer også markedet. Dersom disse investorene innså sin egen begrensning og heller investerte i indeksfond så ville gruppen av forstyrrende spekulanter bli mindre, og markedet ville blitt mer effektivt.

For den store majoriteten av investorer ville det betydd et mer velfungerende marked med mindre feilprising og risiko. En slik verden ville imidlertid vært kjedelig for oss som driver forskning innen dette området, så forhåpentligvis vil utilregnelige spekulanter fortsette å gi oss noe å fylle dagene med også i fremtiden.

Kapitalverdimodellen

(Capital Asset Pricing Model, CAPM)

• Standardmodellen innen finans utviklet av blant andre Jan Mossin ved NHH.
• Forteller at avkastning er bestemt av hvor tett aksjen følger markedsindeksen, og bare det.
• Dersom en aksje for eksempel i gjennomsnitt beveger seg med 2% når indeksen endrer seg med 1% bør avkastningen utover bankrente over tid være dobbelt så stor som markedsavkastningen

Read More

Å eie og å leie

Før finanskrisen var det mange som mente eiendom var en sikker investering med lav risiko. Selv om finanskrisen ikke rammet Norge særlig hardt, viser imidlertid erfaringene fra andre land at det ikke finnes noe slik som høy avkastning med lav risiko. Det finnes imidlertid ett unntak; investering i egen bolig.

En profesjonell utleier må betale 28% skatt på leieinntekter utover rentekostnadene. En som eier sin egen bolig trenger ikke betale denne skatten. Den profesjonelle utleieren må også betale 28% skatt på verdistigningen. Også denne skatten er vanlige huseiere unntatt fra.

Det er dermed nokså opplagt at kjøp av egen bolig er mye mer lønnsomt enn eiendomsinvesteringer i boligmarkedet generelt. Normalt vil slike åpenbare investeringsmuligheter tiltrekke seg nye investorer inntil forventet avkastning tilsvarer markedsavkastningen – altså den en får på børsen. Hver husstand kan imidlertid bare få skattefritak for én bolig, og man kan bare leie ut mindre enn halvparten av boligen for å få skattefritak på leieinntektene. Dette begrenser muligheten til å investere i dette markedet slik at den ekstraordinære avkastningen kan vedvare.

Det er imidlertid ikke bare skattefordelen som gjør det lite attraktivt å kjøpe for å leie ut. Utleie er også en svært risikabel aktivitet. For det første er lovgivingen rettett inn mot å beskytte leietaker. Det er for eksempel i praksis ingen begrensning i hvem eller hvor mange personer en leietaker kan ta inn i sin husstand, med mindre det finnes branntekniske begrensninger. Utleier må godkjenne de som ønsker å flytte inn. Dersom leietakeren misligholder leien, så er prosedyrene for utkastelse så omstendelige at det skal mye til å få namsmann til å effektuere en utkastelse før depositumet er spist opp. Det er også kun svært alvorlige brudd på kontrakten som gir hjemmel for utkastelse. Problemer med husleien er utbredt, ettersom årsaken til at mange leier er at de ikke har en tilstrekkelig ordnet økonomi til å kjøpe.

Det kan godt hende at det er riktig å beskytte leietaker slik som i dag. Resultatet er imidlertid at utleiere må legge inn en betydelig margin for å dekke potensielle kostnader. For profesjonelle er det derfor vanskelig å få lønnsomhet i konkurranse med private utleiere med en store skattemessig fordel. Som figuren viser vil en utleier i dag tjene snaut 600 kroner per måned på å leie ut en leilighet på 40 kvadratmeter, før administrasjon og vedlikehold. Det er dermed vanskelig å se for seg at man kan tjene penger på dette.

Utleiemarkedet preges av den grunn av private utleiere og mindre eiendomsselskap med dårlig lønnsomhet. Leier man ut fra egen bolig gjør imidlertid skattefordelen at man får et overskudd på ca. 2400. Selv dette kan imidlertid være snaut om en tar med alle kostnadene. Om rente øker til 6% vil også overskuddet falle til 400 kroner. Det er også antatt i beregningen at utleie fra egen bolig gir samme inntekt som utleie av blokkleilighet. Sannsynligvis får man imidlertid mindre for leiligheter i bolighus, noe som ytterligere reduserer lønnsomheten. For boligeiere er det derfor også lite å tjene på utleie. Å kjøpe bolig med utleiemuligheter er derfor ikke nødvendigvis en god idé.

Investering i egen bolig i stedet for å leie er imidlertid en meget fornuftig investering på grunn av skattefordelen. Investering i boligmarkedet generelt er som nevnt ikke hensiktsmessig om man ser bort fra fremtidig verdistigning. Kostnadene i forbindelse med utleie og skatteulempen sørger for at en over tid vil tape på profesjonell investering i boligmarkedet. Det er derfor ikke overraskende at det stort sett alltid er trangt i leiemarkedet. Investorer kan selvsagt spekulere i at man får 20 nye år med nær sammenhengende verdistigning, men historien fra andre land under finanskrisen forteller oss at det slett ikke er sikkert at historien gjentar seg her.

Figuren viser gjennomsnittlig overskudd på utleie etter skatt og kapitalkostnader for en leilighet i Oslo med 4% rente. Administrasjon og vedlikehold er ikke tatt med. (kilde: Egne beregninger, SSB, EFF, NEF, Finn.no og Econ Pöyry). Desverre er søylene byttet om i artikkelen i DN. Utregningen finner du her.

Read More