Since the article cite it, I guess I can make a comment too and raise awareness regarding EMET.
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.
I'd suggest that EMET users should add the Flash plugin to EMET's list, as it's a common target that isn't protected by default. Unfortunately the Flash exe's name changes with every version, so it's not set-and-forget.
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.
What do you think a sensible alternative is? I have serious problems with C++, but few people (including me) would accept a "security upgrade" which made my browser significantly slower and memory hungry.
Modula-2 was a possible alternative around the early 80's, back when C compilers were still slower than dumb written Assembly language on micro-computers.
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.
Ada is too complex. It might be acceptable if you are talking about small group of specialists that always produce nice code, but large open-source project in Ada… Well, I'm not sure it's better 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.
Rust or Go would be pretty straightforward replacements for C++. Mozilla is actively using Rust to make Servo. I think both Rust and Go are less conducive to bugs than C++.
There are other languages that could be used to write very secure browsers, but using them wouldn't necessarily be straightforward.
Certainly Rust is aimed in that direction. I'm unconvinced one could (for example) write a high-performance javascript JIT in Go. Also, neither of those languages has been around anywhere near long enough for a browser to be written in this (Rust still isn't finished!), so insulting people for writing browsers in C++ without suggesting a useful alternative doesn't seem very sensible.
Mind if I ask, what's up with these languages, showing up everywhere on (Rust/Go)? Are they that useful? Can you summarize for me what are they good at?
The purpose of Rust is to be as efficient and deterministic as C++ while being as memory-safe as high-level languages, and while also being designed from the ground-up to support concurrency in a way that is lightweight and safe (i.e. guarantees that you cannot race on data).
They're relatively straightforward procedural object-oriented languages. They're not amazing. They won't make you say "Wow, that's awesome!" when you use them.
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++.
Saying that Rust and Go are better than C++ seems like an extreme stretch, when Rust isn't even finished yet and is changing significantly on a week-by-week basis and the go compiler is still written in C and every benchmark I have seen puts Go at 2x to 5x slower than C++.
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).
Go isn't a replacement for C++. You wouldn't write an entire browser in Go.
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.
Here's a Go rewrite that excels in safety over it's C++ original especially when working with the raw bitcoin protocol for multi sig transactions https://github.com/conformal/btcd
Common practice programming languages like Go are getting into the 1980s or so, research-wise. The Haskell community is into the 90s, along with some genuinely new stuff. Both have a long way to go before they're accepted common practice.
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.
> Common practice programming languages like Go are getting into the 1980s or so, research-wise. The Haskell community is into the 90s, along with some genuinely new stuff. Both have a long way to go before they're accepted common practice.
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.
Well, I hardly set out to show the entire range of new stuff in two paragraphs... :) But I'd also observe that Rust has a ways to go before being common practice, too. More power to you, for the love of all that's holy please put a bullet in C and C++, but even in the best case scenario you're still at least three or four years away from even being solid B-list (Perl, Python, etc... Go isn't there yet either, FWIW).
Getting from a research compiler to "something that can actually be deployed in the harsh environment of the real world" seems to be an order of magnitude simpler and quicker than gaining a critical amount of developers and a competitive ecosystem of libraries, tools, tutorials, mindshare and ubiquitous (commoditized?) hireable employees for that language.
Except for those of us that were already coding in the 80s.
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.
> Modula-2 was created in 1978! Just to cite one memory safe systems programming language.
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.
Rust is a brilliant idea. Apply some of the last 50 years of programming languages advances to a low-level language. And they're enthusiastic about incorporating more of them, as they have time to implement them.
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.
Off the top of my head, any of these would have been a much more sane choice: Standard ML, Ada, Java, concatenative languages, E, Lisp, Haskell, Erlang, Python.
> 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.
God, I hate that "link expired" stuff. I wrote you a pretty long response and failed to save it in exchange buffer. It was covering every language you mentioned (except Java, which also is pretty horrible), but as I'm not willing to reproduce it, so let's concentrate on what bothers me: Haskell.
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.
Thats actually a good point, I agree the list of "successful" programs for Haskell is a sad joke. I know some People in finance use it for HFT, but other than that? Can anyone give better examples? Because it is hyped a lot around HN, and 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.
Thats what I was afraid of. I'm still curious because learning Haskell would probably make me a better programmer, but I find it easier to motivate myself if its not just a theoretical exercise.
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.
> Writing GUI app? GUI bindings for Haskell are pretty awful and unnatural.
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]
Seems pretty much like every other GUI stuff I used...
> 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.
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?
No, I don't "don't like Haskell" for any reason, I just see many people talking about how cool and productive it is, so I want them to stop talking and show it in practice. Because, as I said, there aren't many (should I say "any"?) successful apps written in it, so it's a little hard for unenlightened people like me to grasp how good it is.
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.
> No, I don't "don't like Haskell" for any reason, I just see many people talking about how cool and productive it is, so I want them to stop talking and show it in practice. Because, as I said, there aren't many (should I say "any"?) successful apps written in it, so it's a little hard for unenlightened people like me to grasp how good it is.
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.
The mozilla guys know this already. They've specifically talked about how many serious security bugs would have been caught by using a language like Rust.
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.
Even for C++ we have the language, compiler and runtime features to mitigate the majority of these attacks. The problem is nobody wants to pay the runtime cost and/or risk breaking old binaries.
No, it's because writing software in C++ is like riding your bike in the middle lane of a highway with no helmet on.
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).
C is irreducibly dangerous, but you can do quite a lot with C++ by avoiding legacy C stuff. Build almost everything on top of the STL and Boost, which are safe.
And of course there are security bugs (eg, goto fail) that would affect any language.
Fully agree, mankind would be better without C and C++.
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.
The examples should be the other way around. Very safe and simple to drive but slower and not that powerful: bike an a proper bike lane (Python). Reasonably safe & fast: SUV (Rust). Really fast and you can do crazy things (drive on one wheel at 200km/h) but also enormously dangerous: Motorcycle (C/C++).
Or a tank (Ada). Seriously, Ada is alive and in version 2012 pretty okay. It depends on your application domain, of course, but if you care about safety and reliability, Ada is battle-proven.
Would be nice if more information on these exploits were provided, such as would a GrSecurity reinforced sandbox (or SELinux sandbox for that matter) for Chromium have stopped the exploit from gaining a shell, or the OpenBSD priv separation of X
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.
These exploits usually target browsers running on Windows, which until recently did not have ASLR or DEP enabled by default (and still doesn't in the case of some browser plugins). Many Linux distros like Debian or Ubuntu have had RELRO, SSP, PIE, and ASLR enabled by default for browsers for a few years now. PaX and Grsecurity would indeed protect against all of these exploits -- up until one or two years ago. These newest exploits are way out of my league, and I don't know if anything could stop their authors.
To some extent it's true though. If you want to do things the paranoid way, then Linux does offer you many more possibilities of protection.
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.
Funny thing. I looked at my logs, and only today there were 6 attempts of getting into my computer, originating in different countries. And that's because the lamer ones don't get far enough to go into the logs.
this is why I have a hard time believing that cryptocurrencies will achieve mass adoption: eventually everyone gets hit by a 0-day, and then your money is gone forever.
(I realise cold storage exists, but most people won't bother...)
Cash has the same problem, which is why banks and credit cards exist. There's no reason your bank account and your VISA card couldn't be denominated in Bitcoins, affording you exactly the same protections you have now.
You might lose $100 out of your smartphone wallet every now and then. But that will hopefully be rare.
No, cash does not. There is no equivalent to issuing one command to a botnet and collecting a hundred thousand people's wallets. Cash has other problems, which is why bank and Visa exist, but there's no zero-day exploit equivalent.
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.
So you think people will prefer to use worthless plastic/paper currencies that are continuously deflated by governments to fund war and oppression? Cryptocurrencies will streamline the new digital economy - which encompasses all of our lives. Hardware wallets will soon allow people to secure their money with ease. Cryptocurrencies will revolutionize the world in ways that we don't yet understand. It's hard to conceptualize, but bitcoin the 'currency' is so insignificant compared to bitcoin the 'invention'.
> So you think people will prefer to use worthless plastic/paper currencies that are continuously deflated by governments to fund war and oppression?
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.
The main way that governments obtain funds for "war and oppression" isn't by disbursing fiat money, but by taxes. If we switch to 100% cryptocurrencies, taxation won't go away, even if it'd have to be done Roman-style, before such things as 'income declarations' existed; and the cryptocurrencies will no more allow people to "secure their money with ease" than gold allows today.
How did ChromeOS fair? I can understand how general purpose OSs can be pwn'd, but I'm more curious about how mobile platforms such as iOS, Windows RT, Android, and ChromeOS hold up to these competitions.
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.
Do they release more technical information on the exploits after the browser makers have had time to produce patches? The things these guys do always blow my mind.
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.
A bit off topic perhaps, but is it fair, as the article does, to call these hackers "white hat"? Especially Vupen which sells to the highest bidder(s), although selected, should be considered black hat, as they don't work with the intention of securing software, they even advertise on their site that they will sell the worst security holes for offensive use only.
Motivated by the same, a couple of days ago I went to the trouble of downloading rust and building Mozilla Servo. Unfortunately, if my build is anything to go by, it won't even render most pages yet, so that practical alternative path is presently closed.
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.