Thursday, July 31, 2014

tldr; A long, passionate discussion about JS crypto. Use slides for an overview.

Javascript cryptography is on the rise. What used to be a rich source of vulnerabilities and regarded as "not a serious research area", suddenly becomes used by many. Over the last few years, there was a serious effort to develop libraries implementing cryptographic primitives and protocols in JS. So now we have at least:

On top of that, there's a lot of fresh, new user-facing applications (Whiteout.IO, Keybase.io, miniLock to name just the fancy ones on .io domains). JS crypto is used in websites, browser extensions, and server side-applications - whether we like it or not. It is time to look again at the challenges and limits of crunching secret numbers in Javascript.

Web is based on a client-server model. The server supplies the Javascript code, so it can backdoor it as well. You need to trust the server any time you visit a website. Plus, you need TLS to protect the code to from tampering by third parties. And, since you already have a secure channel, JS crypto is pointless.

XSSOMFG (and DOM is a mess). Code injections are common. JS crypto is as insecure as JS itself.

There's no CSPRNG, no bytes, no mlock(), no BigNums and no good libraries to use. JS crypto is hard, because the language does not help you.

For years, these two articles dominated the views on the subject. Meanwhile, the world evolved - we've seen browser extensions written in JS, nodejs came along, WebCrypto was born and CSP arrived. Some of the arguments got simply outdated. Someone was wrong on the internet.

Last year the discussion started again. Tony Arcieri noted that in-browser crypto is dangerous mostly because the code can be backdoored by the server/attacker at anytime. Web is an ephemeral environment. He noted that browser extensions can solve this problem, as these behave more like a installable, auditable desktop applications. Brendan McMillion made a great post, noticing that Thomas simplified his arguments and did not specify the threat model (in short - security is not a bit value. You're not secure period, you're secure against an attacker with certain capabilities).

Thai Duong admitted that JS crypto is hard, but doable. He provided some tips on how to overcome JS quirks, and noted examples when JS crypto is better than server-side approaches. He also dropped a super-cool vuln, but that went unnoticed.

Here's where I jump in.

Looking at the code

I have the unique opportunity to both participate in the (sometimes theoretical) discussions and deal with code of crypto applications written in JS. I took part in audits of several of them, and now I even develop one too. So I asked myself a few questions:

What are the real challenges of JS crypto applications?

What vulnerabilities are actually discovered, what are their root causes?

Should we really worry about the issues raised a few years ago?

What level of security can be achieved? Who can we be secure against?

Can the JS crypto be somehow compared to "native" crypto?

The answers to all these are in these slides, but let me expand a bit about some key points.

It's all the same

Vulnerabilities in cryptographic code written in Javascript occur because of two reasons:

Javascript as a language is weird sometimes

Web platform is really inconvenient for cryptographic operations

To give you an example of language quirks, you can still trigger weird behaviour in a lot of JS libraries by using Unicode characters, because JS developers use String.fromCharCode() assuming it returns 0-255. Weak typing often causes vulnerable code too.

XSS is an example of a web platform issue that breaks cryptographic code completely. Lack of good CSPRNG (and relying on Math.random() ) is a web platform issue as well.

Surprisingly, similar problems are present in native crypto applications, and these also result in spectacular vulnerabilities. For example, sometimes the language gives you poor support for reporting error conditions and you end up having a certificate validation bypass. Or out-of-bound read is possible and Heartbleed happens. You might also kill your entropy like Debian did years ago. Skilful attacker might upgrade a buffer overflow in your beloved crypto library into RCE vulnerability, which is an equivalent of XSS in web security.

On both sides of the fence we face all the same issues, we're just not used to look at them this way.

Use extensions only

In-website cryptography is doomed. Let me repeat - don't implement cryptography on any document which location starts with http. It's a trust problem, well understood and it's a dead end.

The only sane model for JS crypto is a server-side application or a browser extension. As a bonus, for these environments XSS is much easier to tackle as you can control your inputs more easily and sometimes the platform helps you as well (e.g. obligatory CSP for Chrome Extensions). In practice, XSS in your crypto application can be a marginal, manageable problem, and not a fundamental issue.

It's all fun and games...

Once we established a ground rule of only supplying code in an installable browser extension, it's time to dig deeper. Are browser extensions secure?

We can only be secure in a given threat model, so let's look at our potential adversaries. We solved XSS (which any kid could exploit) and we solved server trust issues. Unlike websites, extensions need to be installed, so you only need to trust the server once, not every time you run the code. By doing this we're secure against man-in-the-middle attackers backdooring the code (or the service owner being pressured to "enhance" the code later on). At a glance, it looks like we achieved the level of security of native crypto applications. Yay!

Until someone gets hurt.

Autoupdates

Not so fast. For once, browser extensions autoupdate. Silently. So the only way to trust the extension is to review it and install it manually (i.e. outside extension marketplace).

But - is this a problem unique to web? Most desktop systems autoupdate software packages nowadays, and the updates are being pushed aggressively (and for a good reason!). That includes your precious OpenSSL too.

Timing

Timing is another open problem. It's most likely impossible to guarantee constant-time execution in a modern JS compiler. Even when your code is a perfect port of a constant-time C routine, you'll have timing sidechannels in places you wouldn't ever expect, because your JS engine decided at some point it would be a good idea to optimize the loop. The timing difference will be probably non-exploitable, but I've heard that statement falsified so many times, I'd rather not rely on it.

Again, this is something native crypto applications struggle with as well. Timing issues were discovered in GnuTLS, Java SSE, and OpenSSL to name the few. When fixing timing leaks, you sometimes even need to worry about CPU microcode.

Memory safety

Memory safety issues can bite you as well. Whaaat? We don't have buffer overflows in JS, right? Well, your Javascript code cannot introduce a buffer overflow, but the underlying JS engine implementation, and the browser with its HTML parser do have vulnerabilities too. Browsers get pwnd, you know, and your precious crypto extension can be pwned with them. All you need is to do is visit a website that triggers the exploit code. Luckily, here we assume a much more skilful (or rich) attacker, so you might just get away with claiming it's outside your threat model.

Host security

Arguing that implementing crypto in a browser extension is insecure because a browser might get pwned, is similar to pointing out the insecurity of OpenSSL because kernel exploits exist. Host security is still essential. Any binary you run can just read your precious ~./ssh/id_rsa and it's working-as-intended. What changed with JS is that now the attack surface is much greater, because:

The browser is now your OS, and origins are just different users in this OS.

Everyone in the world can execute a program on your OS. To put it boldly, web platform is just a gigantic drive-by-download marketplace. Visiting a page is equivalent towget http://kittenz; tar; ./configure; make; ./dist/kittenz

Assuming the adversaries are powerful enough, some of those kittenz might bite your code badly.

But then again, are browser exploits that much easier to buy/develop than any other popular software and/or kernel exploits? Because these would have no problems with circumventing native crypto applications. After all, GnuPG was thwarted by a simple keylogger.

JS crypto is not doomed. We made some real progress in the last few years, and will continue to do so. It's just that when facing some classes of attackers you're defenceless and we all need to understand that.

33 comments:

Paul Laroquod
said...

If you're going to make it a separately installable tool, why even write in JavaScript? The reasons are a lot less compelling to even use JS in that case. Basically, as JavaScript migrates away from the HTTP protocol, the security issues that made it notorious disappear, which should be no surprise to anyone, since it was never the language itself that was really the problem.

Because currently, at least for desktops, the browser engine is the most popular code and execution platform. You're no longer running code in a JVM (via Java applets), you don't install applications. You just click and just have a browser extension.

Also, e.g. when crypto primitive libraries are written in JS, you get portability pretty cheaply. You can easily launch an application for mobile platforms, browsers, smart TVs and whatnot. JS becomes the new C.

It's great to see how these last months people seem to evolve and leave behind the idea that JS crypto is a waste of time. I think that JS crypto is key for the future.

I don't buy the idea that server-side crypto is to be equally trusted that JS crypto in websites. I mean, of course JS crypto can be tampered, being that because of a XSS or because the server is modifying the code. But, eventually, with JS crypto you will have access to that code, tampered or not!! I can't believe that people put that situation in the same level as not having a fucking clue about what crypto code is doing in server-side (or if it even exists...). ¿Hello...?

On the other hand, what about creating a browser extension that tracks JS crypto modifications for each website you visit. In which you can set what code is trusted and what code is not. We can argue that only a few people would be able to check if modifications are malicious, but at least web programmers will have to justify their changes in cryto libraries and you'll be notified if some kind of tampering/modification is done.

It's been years since I see that JS crypto is a key concept, but during all this time people more knowledgeable than me have stated that it is (and will be) completely broken. I've never fully understood it. Yes if there's a XSS in the website you are screwed, but man... you are supposing that the website has already been hacked! Do we stop trusting server-side crypto because the server might be hacked?

Welcome to a company Corner creativity we best pesticide spraying company in Khamis Mushayt of the most dangerous tasks in any house, is spraying task as the spraying process that requires time and effort and high-quality technology and labor trained so this addition to pesticides that are sprayed may be toxic or harmful must be sprayed at the hands of professionals, there must be a great company, specialized and high quality in the spraying of pesticides, and that of the best companies in the Kingdom of Saudi Arabia is sprayed pesticides Khamis Msheet.omn company what distinguishes this company from other companies that they provide to customers excellent services شركة رش مبيدات بخميس مشيطThe company offers cleaning services by high quality, and services that meet all your expectations with workers dedicated team motivated and that will suit your needs for the sole purpose is to satisfy yourself in the most urgent requests and specific.شركة تنظيف بخميس مشيطIn addition to his professional cleaning and seeks corner creative integration in all the services to maintain sustainable clean rooms and impeccable hygiene to promote a sense of well-being among employees who spend most of their time, and thus better business productivity.

cleaning is something important in the life of every human being, it is something essential in our lives and we can not live without them even live safely without the disease nor any pandemic interest in them something necessary and important, the clean types in terms of roads and style and how to implement the outcome and the reasons that lead to it and other .....شركة تنظيف بالطائفشركة تنظيف منازل بالطائفشركة تنظيف خزانات بالطائفTo learn about some of the tasks in which we perform the task to get rid of any distress and any pollutant that can harm us in general. We talk first about hygiene cleaning anything roads is important and necessary, we always go out on the streets and wander so that we can spend a purpose and also the exiCleanliness of the houses is the most important things for us Each of us can not live in a house with distress or pollution, because this causes damage to us you will be always puzzled inselecting a company Cleaning company in Khamis Mushayt, we are located in the city of Khamis and get to you upon request has good reputation in this place, as well as our people carried out many acts of home maintenance and the result was good and the work to be thankful for. We put all our efforts for the benefit of our company and maintain its work and make plans in various fields, and when we talk Ali equipment ubiquitous in the company, we always we update any renewal of our equipment at different intervals to keep on our work and give a good result and also always look forward to modern methods of doing our work to connect us, you will just have to click on the link below to get the most information about us:شركة تنظيف بالقطيفشركة تنظيف منازل بالقطيف