Down go all the major browsers at Pwn2Own
zdnet.com
zdnet.com
EMET is a free application published by Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=3927...) that enable advanced protections for many applications, such as DEP and ASRL. It comes out of the box with rules that cover many popular applications, so it's an "install and forget" solution for many users.
If anyone is interested, this is the article that made me aware of EMET: http://rationallyparanoid.com/articles/microsoft-emet-3.html (slightly outdates as Microsoft has released EMET 4, but it's still an interesting read, especially the "Does EMET make a difference?" part), and there is also an interesting user guide here: http://download.microsoft.com/download/4/E/9/4E9A5137-F73D-4...
I suggest to everyone to gave it a try, it's very lightweight and it has yet to cause a single problem on my system.
Adding an application to EMET is simple for a user with some amount of Windows knowledge. Its main window has a list of running processes. Just right-click the one you want to protect and choose "configure process."
Some of these techniques are enabled by default or on an opt-in basis in recent versions of Windows, and EMET can be used to enable them on older Windows systems. Other techniques would be too easily triggered by the normal operation of badly-written software, making the software unusably crashy.
But it doesn't make you bulletproof. http://labs.bromium.com/2014/02/24/bypassing-emet-4-1/
There are other languages that could be used to write very secure browsers, but using them wouldn't necessarily be straightforward.
They do have a few practical advantages over C++. For one, they don't allow dangerous things like pointer manipulation. They both support garbage collection. Go has some nice built-in support for multithreading. Both have some nice iteration features. Useful syntactic sugar. Stuff like that.
Where C++ is basically just C with random features shoddily spot-welded on in different places, Go and Rust were designed from the ground up to be relatively very simple and straightforward. Like I said, they're not amazing; they're just better than C++.
Modula-2 was created in 1978! Just to cite one memory safe systems programming language.
For as fast and as furious a pace as the world of computer programming likes to think it runs at, there is an unbelievably long line to get something from research to common practice. It's literally decades long.
Though there are some reasons for this; there's a difference between doing a research compiler and doing something that can actually be deployed in the harsh environment of the real world. Still, the world of computer programming does not advance anywhere near as quickly as it fancies itself doing.
Rust actually uses new stuff; the borrow checker builds on old ideas from Cyclone and others from the 90s, but it mixes it with some interesting research ideas of its own (using C++ destructors to get region typing at the level of individual values, not of regions) to come up with something that's actually fairly novel.
Modula-2, Turbo Pascal and Ada weren't research languages, rather well known languages, while C was mainly UNIX only one, slowly spreading alongside UNIX into the enterprise.
I think the problem is that many young developers never experienced those days and think C and C++ are the only game in town for systems programming languages.
If you opt into garbage collection for the whole program. That's not the same overhead as C++. (I know you believe that GC is faster than manual memory management, but let's sidestep that debate by defining "the same overhead" as "the same memory management practices that C++ uses, with the same tradeoffs".)
Modula-2 also uses manual memory management just like C.
So by using it, there is a whole class of C errors that are not exploitable:
- Buffer overflows
- Pointers that go astray, injure some critical data structure, only to die minutes later in another totaly unrelated place.
- Strings without null terminator
- No implicit conversions between types
- Proper enumerations
- Arrays are properly bound checked by default (unless explicitly disabled)
Still problems like memory leaks and double free exploits do prevail. However the set of possible exploits is surely smaller than C and C++ offer to hackers.
I have high hopes for Rust in the future, but Go just does not seem like a replacement for C++ in the places where it excels (although many people do use C++ in places where they could probably have used say python, and Go is a reasonable alternative to Python).
Instead, I think, you'd write a bunch of fast browser component libraries in C (which is what already happens now), and then glue them together in Go to produce a nice, static, easily-deployed binary for each platform.
You know how in, say, games, you see people writing (needs-to-be-performant) mechanism in C, and then scripting (can-be-slower) policy in Lua? Go excels in this same niche[1] and the results from Go, unlike from Lua, can be treated (and debugged!) as native linked-in code.
I'd still rather the whole browser was written in Rust, though; those libraries that are right now written in C for performance could do with fewer crashes.
---
[1] ...if-and-when it's the policy-writer who compiles and links the binary. If FooCorp ships a game engine as a complete executable binary, and you're expected to just write policy hooks in Lua against the FooCorp's "framework", then there is an equivalent workflow for Go--you'd produce a dynamic library that the executable dlopen()s--but the result doesn't have the same sort of elegance. (You don't get to code-sign the resulting complete executable yourself, for example.)
Why not? AOS has one written in Active Oberon, which is quite similar to Go feature wise.
The main differences is that Active Oberon's SYSTEM package is more powerful than Go's unsafe and support for untraced pointers. The later can also be achieved in Go via a mix of syscalls and unsafe.
Go is just another language that ignored the last 50 years of programming language advances in order to not scare C programmers who are afraid of learning anything new.
Sadly UNIX spread into the enterprise and with it brought C to the masses and spread the doom of security we still enjoy.
C++ is way safer than C, if one use modern C++ instead of C underpinning that allowed the language to become mainstream.
Now, we have to hope languages like Rust and D might recover what Ada, Modula-2 did not managed to become.
Compared to what? C++? You're joking right??
> Well, I'm not sure it's better than C++.
I disagree, Ada is complex ok, but its default behaviour is much better for security than C++.
Not at all. Well, maybe not compared to C++, but still, it doesn't seem like really plausible alternative, that can be recommended and seriously used in a complex application. Dijkstra agrees. ;)
> but its default behaviour is much better for security than C++
Oh, sure. But that could be said about pretty much every language out there. Somebody recommends Haskell. Haskell's default behavior is way better than C++. It's not enough.
Actually, I never saw big projects in Ada, so I can be wrong, but it seems to me that for typical more or less sane programmer might be even easier to write hard-to-understand code in Ada than in C++, even though Ada is much better designed. The reason is that C++ complexity is well known, many of it's features considered dangerous and most of people seem to avoid them. That's not true for Ada, and it's also very feature-rich.
If anything: there are many things about Ada I like. Its data type system, for example. It's really a shame that after C many programmers somehow "forgot" that all that stuff exists.
I think they were born after many of us had the pleasure of using alternative languages.
> few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
I can't tell if this is a joke. You know practically website is constantly running the shittiest JS you can imagine (and sometimes Actionscript), right?
Even if the language somehow can't handle implementing a certain task efficiently, you could still make a separate OS process for say, decoding the video stream, and passing it back to the safe code.
If you think there is a technical reason that browsers/OS today are written in C/C++ you are wrong. The reasons are purely circumstantial. Also note that most C/C++ coders aren't aware that other languages even exist or are practical, so good luck getting them to switch.
So, the essential. If Haskell is "better" than someting else, then, by definition, it's easier to write good software in it. I wrote about my personal experience in the lost reply, but it doesn't really matter. The question is, why people who believe that Haskell is better for writing browsers won't prove it themself? By doing, I mean. I haven't seen a popular (lets take it as quality measure) browser, P2P client, feature-full messaging client/service or image editing app written in Haskell. Only pandoc, Xmonad, Yi and countless links to haskell.org success-story page, which isn't working app. Actually, it's true for any language, but nothing is mentioned as often as Haskell.
Heh, I use tor, and it just took me over 10 tries to login to reply to you (changing exit nodes to find one that isn't blocked, etc).
If you don't like Haskell for some reason, replace it with something else. Heck, a browser in pure JS would be preferable to a browser in C (note: it doesn't count if you have 50 libraries implementing audio/visual/crypto/compression written in C and linked into the same address space as the JS).
But it takes huge capital to implement a browser, and you'll still have the other issues like CSRF, clickjacking, phishing (each of which have been solved ages ago by waterken btw: http://waterken.sourceforge.net/web-key/), X.509 (which has been solved by tor hidden addresses and other systems like it), and other mystical issues that arise because of how incoherently-designed the web is.
Anyways, why do you think C would be any better for implementing a browser than any of these languages?
Yes, I know that writing a browser or anything serious is a lot of work. But it's productive, right? And quite many people do that in their free time… well, maybe not a browser (at least I haven't heard about that), but at least bittorrent clients, p2p network layers, feature-full messaging clients, firewalls, anything. Their authors started them alone in their spare time, for free. And they are written in C, C++, Python, sometimes Java. Why? Obviously, because their authors for some reason chose that language. They decided it's better. And nothing is written in Haskell. It was like that 5 years ago, Haskell evolved, became much more popular (actually I even do know a company that uses it in production, but it's not the point) and that statement is still true. So every time somebody starts bragging about how all-powerfull Haskell is and how stupid are people that actually write something to choose C++ instead, I can help but ask: so why won't you prove on practice that Haskell is better? Because, once again, for PL "to be better" is to make its user more productive and more able to write quality software. So, it seems to me that this "why won't you…" argument (which is pretty ugly in many cases) is fair enough in this case.
Now, I don't want to rewrite what I said about languages you mentioned, because it was pretty long. So, in short. ML — dead. Python — way too slow (if "browser" is everything including engine, not some shell around webkit). Erlang — just isn't built for that purpose (it's dynamic, highly concurrent "built to fail" language — are you even serious?!). Java — well, maybe, but it's not the perfection itself.
I can't even be bothered to look at what who is using what language for, so I'm not going to debate this... I use Haskell every day, as well as a bunch of other languages, some of which nobody heard of, and they all work fine.
> so why won't you prove on practice that Haskell is better?
Because I don't care?
> Because, once again, for PL "to be better" is to make its user more productive and more able to write quality software.
Which you can easily do in Standard ML with no surprises, because it's a straightforward simplistic language and it's been like that since the 70's. But you dismiss it because it's not popular or something (despite being used by hundreds of thousands of people).
> Python — way too slow
Do you have any results to show this? I already pointed out, even if the language is too slow, you can just run C or assembly or whatever in a separate address space for each CPU intensive process. Your claim implies that the latency of passing the output of the worker in C/assembly back to Python (and passing new input from Python to the worker) would be too high.
> Java — well, maybe, but it's not the perfection itself.
So... you agree?
> I wonder if it is worth it to learn
Well, you may try anyway. It's pretty interesting experience. Many people claim that after you are "enlightened" you'll hate other languages. Seems that I'm still not enlightened. It's nice to write parsers and similar stuff in it, but I couldn't find an area where it would be clearly better to use Haskell than some alternative I'd normally choose. If you don't need hight performance and your product is, say website, than some Python/Ruby seems more convenient (mostly because of many good libraries and instruments for them). Writing GUI app? GUI bindings for Haskell are pretty awful and unnatural. Real time? Sorry, optimizing Haskell is so unintuitive that I can't consider it. Plus it has big runtime and is lazy. Something hightly concurrent? Not better than Erlang. So, I came up with that it only suites well for writing Haskell compiler and there already is a couple of them.
Did you venture into web dev a bit? I find the 'once it compiles it usually is correct' bit tempting, as I have a hunch that this might be more efficient that writing tons of unit tests in a language like Ruby.
I've never had a problem with GUI coding in Haskell... Here's a few lines of some WX code I wrote:
p <- panel f []
startButton <- button p [text := "start"]
stopButton <- button p [text := "stop"]
set p [layout := row 5 [widget startButton, widget stopButton]
> Real time?
what.
> Sorry, optimizing Haskell is so unintuitive that I can't consider it.
I agree that space leaks are hard to fix / prevent, but meh, other mainstream languages have other problems that sum up to the same amount of pain.
> Plus it has big runtime and is lazy.
Big runtime? I'm not sure what you mean by this... In contrast, my web browser usually occupies a few hundred megabytes for trivial tasks.
> Something hightly concurrent? Not better than Erlang.
I'm not sure about that. Erlang has some very weird stuff going on (http://stackoverflow.com/search?q=user%3A2213023+[erlang]), and in Haskell you can program actor style pretty easily with channels/pattern matching, and then there's CSP, STM, Data Parallel Haskell, etc.
"sensible" is all in the eye of the beholder, once you have your computer hacked your priorities may change..
> but few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
And THAT is the issue, security CANNOT be an afterthought.. Note that significantly slower doesn't mean slow, PC's CPUs are very, very fast.
If you're really really careful, it can work fine, and your trip will be efficient and productive. But it's really hard to do it properly -- you could hit a car (buffer overflow), you could get hit by someone (heap overflow), or your brakes might give out (input sanitization fail).
It's not that it's impossible or that it's a "bad idea", it's just that it'd be a lot safer to spend the extra resources on a motorcycle (Python) or an SUV (Rust).
And of course there are security bugs (eg, goto fail) that would affect any language.
But given they are the current mainstream options for the time of applications they are used to, better use modern C++ like you are advocating and stay as far as possible from any pure C constructs.
Additionally use static analyser, enable all warnings as errors and turn on pedantic mode.
this is not really true, you can have temporal memory safety issues using STL and boost.
...
One example I can think of immediately is Grail, which was implemented in Python: https://en.wikipedia.org/wiki/Grail_%28web_browser%29
Another is HotJava, which was implemented in Java by Sun: https://en.wikipedia.org/wiki/HotJava
The results were less than stellar. Neither browser was really comparable to contemporary browsers written in C or C++ in terms of features and performance. Those factors are just too important to overlook, even in the name of security.
Do they release the exploits after patching? I want to run unpatched versions on said above configurations or at least be able to read the code to see if it's yet another javascript problem.
Right now I'm using NoScript and I have exactly 10 sites whitelisted. That list doesn't include common sites such as Google or Yahoo.
IMO Google search is eminently usable w/o JavaScript, as is Gmail. But I don't really care about frills like search suggestions.
Oh, and get off my lawn.
It's not unheard of, of course. A bug in the CSS, HTML, or image parsing/rendering libraries can be exploited in this way.
I kid, of course. Last I heard they don't even target it in the competition. But maybe neither do hackers ;)
For example setting up different profiles for social networks / banking / random browsing / ... and protecting them externally to the browser using selinux/tomoyo/apparmor/whatever-you-prefer (or even go full virt with qubes!) will give you much more security - no breakout on a random page will be able to touch your sensitive data. And it doesn't even matter what the browser exploit does.
(I realise cold storage exists, but most people won't bother...)
The currencies are continuously inflated, not deflated.
But either way, do you seriously think that governments won't simply use cryptocurrencies to fund both war and oppression if those cryptocurrencies ever become popular? Can you possibly be that naïve?
At best you'd decouple currency from government to make the concepts orthogonal, but Bitcoin won't get rid of oppression or war, let alone crime like theft and murder-for-hire.
You might lose $100 out of your smartphone wallet every now and then. But that will hopefully be rare.
It's one of the reasons computer security is so hard. What in the real world would be a minor weakness that really is unlikely to ever be exploited is in the computer world an invitation for a bad actor to "SELECT * FROM private_customer_data" and be walking away with everything you own before the alerting system you probably don't have and probably aren't paying attention to can even go off.
https://plus.google.com/+GoogleChromeDevelopers/posts/QbtZ7A...
Looks like one full-blown exploit (of an unknown nature but serious enough to get the $150,000 award), but maybe specific to a single device (HP Chromebook 11), and one partial exploit on the same device. Unclear from the blog post if the issue is something very specific to that one HP device or if it is ARM-platform related and impacts the Samsung ARM Chromebook as well since AFAIK Pwnium was just focusing specifically on a couple of newer ChromeOS devices.
At the same time it just reinforces the point that if you are targeted by an entity with enough resources there is pretty much nothing you can do to prevent exploitation. I am pretty sure all browsers get "pwned" at nearly all of these competitions.