Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Tale of Two Pwnies (Part 1)

blog.chromium.org

Post reply on HN
Print view View original

61–70 of 82 posts

Re: A Tale of Two Pwnies (Part 1)

#61

Post by pcwalton »

tptacek wrote: post #4

What's amazing about this bug is that at every step you learn something that makes Pinkie Pie more terrifying while simultaneously making the Chrome security model sound more and more forbidding.

Except for the memory corruption part. When reading that, I'm more aghast that we're still dealing with these basic bugs like "out of bounds array write leads to ROP chain that executes arbitrary code in the process". That just makes me feel even more that huge million-line codebases of C++, even well-engineered code like Chrome, cannot be trusted, because of the fundamental flaws in the C++ memory model for code that must be secure.

Re: A Tale of Two Pwnies (Part 1)

#62

Post by fusiongyro »

mietek wrote: post #48
wvyar wrote: post #45

Earlier quoted context omitted.

I'm personally unfamiliar with the languages you mention in the first paragraph. Would you mind linking to some information about them?

BitC could be one of them. Unfortunately, the author has recently announced he's ceasing work on it. 1. http://www.bitc-lang.org/ 2. http://en.wikipedia.org/wiki/BitC

He quit because he found type classes to be both insufficient and a lot of trouble for this purpose. My impression is that he would love to work on a new language targeting the same problem but making some different engineering tradeoffs. I hope he manages to secure funding so he can do that, BitC was a very interesting project.

Re: A Tale of Two Pwnies (Part 1)

#63

Post by fusiongyro »

ktosiek wrote: post #28
adrusi wrote: post #11

Earlier quoted context omitted.

someone's gotta write the kernels though, I can't think of any way to write kernels or compilers where memory corruption is impossible.

You can use a language with dependent types (types depending on values, so you can have arrays of type "array of 10 ints" etc.) - it adds some type-level work, but makes a lot of mistakes not even compile. But complicated type systems are, unfortunately, rarely used in languages suitable for system programming. I only know about ATS in this group actually :-)

Dependent typing is really neat, but it introduces some new problems. Namely, the type checker becomes Turing complete. We have other examples of this level of complexity turning out to be manageable (C++ templates, for example, and the Hindley-Milner algorithm which turns out to be super-exponential in the worst case) but the power of dependent typing is begging to be used and abused to a greater degree.

I have some hope for Rust because their type invariants system (I forget what they're calling it) lets you glue some of this information to variables in a compelling way without necessarily having to solve all the theoretical and practical problems that come with full dependent typing.

We'll see, I guess.

Re: A Tale of Two Pwnies (Part 1)

#64

Post by zobzu »

tptacek wrote: post #36
zobzu wrote: post #34

Earlier quoted context omitted.

The post is great in itself (clear and easy) but the constant marketing speech about how great Chrome is regardless of the bugs gets on my nerves to be honest. Yes Chrome is a very good browser, but I don't have to read that every paragraph in various forms... specially for tech articles. It also looks like to me that devs commit code in a more lazy way since Chrome has a strong sandbox model for various components.…

There is no way to explain how awesome Pinkie Pie's exploit is without simultaneously explaining how intricate Chrome's security model is. A great way to market a browser is to have a security model so interesting/effective/intricate that any description of a working exploit will also serve as marketing.

I disagree. Marketing does not have to be in every damn blogpost.

It's just annoying ;-)

While they attempt (and apparently succeed) to make you believe that exploiting Chrome is exceptional and it's such a super high security program:

The bottom line is, 2 guys showed up with a complete remote exploit of Chrome. And there are more exploits that are obviously unreleased, and some that will get released each year.

That is the true bottom line.

So again, while the article is nice and clear, the exploit is a good pony job as well - the marketing behind it makes the read annoying. It's a trend and it's not just Google. You even justify is as if marketing was a required thing to have and if you don't try to do it, you're just missing out. Well, I digress.

Re: A Tale of Two Pwnies (Part 1)

#65

Post by zobzu »

marshray wrote: post #53
tptacek wrote: post #43

Earlier quoted context omitted.

That's not an equation. I don't know the right word to use for Chrome's model yet, but unlike some people, I am very bullish on sandboxing.

I too am bullish on sandboxing, but I suspect, like all security boundaries that have come before it, that it will be secure in inverse proportion to the amount of functionality that is allowed to pass through it. App developers will poke more and more holes through the sandbox to enable new ways to cater to users. E.g. the WebGL^H^H^H^H^HGPU command buffers channel leveraged by PinkiePie.

Well yeah WebGL is a freaking good target. And NaCl is too. In fact, when I look at Chrome I look at NaCl and WebGL first. Because they're typical targets.

Chrome did make a good attempt at securing their browser and it works well. Unfortunately it seems that devs write slightly more sloppy code (i mean some of the exploits used are kind of basic, as if they just didn't care all that much because there's a sandbox).

That's my take tho, and it's very arguable.

I like memory-safe based OSes with secure message passing for such reasons. Singularity by Microsoft is a pretty neat implementation for such a concept. While it's not bullet proof it's simple yet (way) more powerful than the hacks we've to go through to sandbox apps on various OSes today.

Re: A Tale of Two Pwnies (Part 1)

#66

Post by zobzu »

sixcorners wrote: post #13
adrusi wrote: post #11

Earlier quoted context omitted.

someone's gotta write the kernels though, I can't think of any way to write kernels or compilers where memory corruption is impossible.

Didn't Microsoft make an experimental kernel with managed code?

Note that managed code is just one feature of Singularity. They have many other important concepts (like SIPs).

Plan9 ain't bad either. There's also different C# clones (that aren't based on Singularity)

Re: A Tale of Two Pwnies (Part 1)

#67

Post by zobzu »

comex wrote: post #52
Arelius wrote: post #18

Earlier quoted context omitted.

In theory, it's possible to use a formally verified approach to ensure this can't happen, and there is a lot of research into that. There is a version of the L4 microkernel that has been formally verified which should prevent memory corruption in kernel space, but I don't know the exact details. This of course won't prevent corruption due to physical sources, such as radiation, but with physical access to a machine y…

The first thing about L4.verified is that formal verification, while admirable, doesn't really matter , at least not in a world where exploits are commodities, exploitation a continuous process: if a program is only a few thousand lines long and written with attention to security, the number of vulnerabilities can at worst be counted on one hand, and attackers will find them all for you in short order. If you're Iran…

There's still role based access control and similar models that you can apply. As well as trusted path execution for binaries.

While none of this is bullet proof, it does add a very customizable kernel-level "sandbox". If you can't run your exploit for example, even thus the kernel is vulnerable, well, too bad.

Now for dreaming out loud, let's go code an OS in Rust that mimics most of Singularity and adds some RBAC on top for good measure (even thus its a much lighter version than on traditional OSes due to the system call avoidance and inherent sandboxing of all apps, as well as the contracted messages.)

Re: A Tale of Two Pwnies (Part 1)

#69

Post by btown »

CrazedGeek wrote: post #19
mark-r wrote: post #16

If you don't have a young girl you might not appreciate the link between "Pinkie Pie" and "Pwnie": http://mlp.wikia.com/wiki/Pinkie_Pie

Somewhat OT, but the show has a fairly sizable periphery demographic (males 13-35), which I would guess the hacker considers himself a part of. More information: http://knowyourmeme.com/memes/subcultures/my-little-pony-fri...

Pinkie's not the only brony hacker either. Consider this Rainbow Dash fan: http://www.reddit.com/r/IAmA/comments/sq7cy/iama_a_malware_c... ... and in general, there are a plethora of bronies scattered across the startup world and CS academia (full disclosure: myself included).

Re: A Tale of Two Pwnies (Part 1)

#70

Post by jackpirate »

marshray wrote: post #54
ktosiek wrote: post #28

Earlier quoted context omitted.

You can use a language with dependent types (types depending on values, so you can have arrays of type "array of 10 ints" etc.) - it adds some type-level work, but makes a lot of mistakes not even compile. But complicated type systems are, unfortunately, rarely used in languages suitable for system programming. I only know about ATS in this group actually :-)

C can represent the type "array of 10 ints": int array[10]; But probably you meant runtime variable values.

the type of that is an (int*) if I'm not mistaking
Post reply on HN