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

41–50 of 82 posts

Re: A Tale of Two Pwnies (Part 1)

#41

Post by Arelius »

wizzard wrote: post #31
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…

L4 was verified to the tune of about $4.6 million dollars, or $500 per line of code. And that's for a microkernel under 10 KLOC. And that's assuming no changes are made. Ever.

The idea of having a small kernel that is properly verified, and properly run user-level code in a memory-protected manner isn't absurd. And when put into the context of Operating System budgets, 4.6 Million dollars is completely reasonable. Again, we're also talking about a hypothetical 2040 OS. not something we're going to have working tomorrow.

Re: A Tale of Two Pwnies (Part 1)

#42

Post by Arelius »

pilif wrote: post #22

In the end it all boiled down to old-style plugins. All the exploits were used to finally install and run an old-style NPAPI plugin. Just like ActiveX, these are binary code that usually runs outsidE of any sandboxing due to compatibility reasons. With NaCL or just the advances in HTML and related technologies, this kind of plugin really should have outlived its usefulness by now and maybe it's time to drop support -…

Let's be fair here, This particular bug used an NPAPI installation to finally get full access, but there many other significant breaches of security previous to this, it seems that the final step, was likely one with the most potential vulnerabilities, with NPAPI just being the easiest to install the payload.

Re: A Tale of Two Pwnies (Part 1)

#43

Post by tptacek »

moldbug wrote: post #40
tptacek wrote: post #36

Earlier quoted context omitted.

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.

Pinkie Pie is a frickin' genius. But I'm curious about this equation, interesting == effective == intricate. Intricate == complex, right? So, the exploit certainly reveals that Chrome's security model is complex . And this is supposed to be a good thing? Seems like a good thing, if you're Pinkie Pie...

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.

Re: A Tale of Two Pwnies (Part 1)

#44

Post by rgoddard »

moistgorilla wrote: post #6

This really takes you into the mind of a hacker(the malicious kind). Judging from what I saw it seems they combine a ton of small exploits to produce a major security breach. The amount of understanding of the underlying system you need to have in order to put these exploits together is mind boggling. What do we do against people like this?

Honestly, the overall process reminds me of what I do some days trying to automate processes which were not designed to be automated. I know what I want to do, I just have to figure out how, step by small step, using things not in the way they were intended to be used.

Re: A Tale of Two Pwnies (Part 1)

#45

Post by wvyar »

jerf wrote: post #30
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 don't write them in C. You write them in a not-yet-existing language that allows low-level, but safe, access. (Prototypes of this language certainly already exist, I'm not convinced any are ready for this level of prime time.) You probably also have some additional hardware support not yet existing. And while, yes, deep at the heart of the system there will be something or some set of somethings that, if screwed…

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

Re: A Tale of Two Pwnies (Part 1)

#47

Post by skeletonjelly »

wtracy wrote: post #35
skeletonjelly wrote: post #17

Earlier quoted context omitted.

Just don't let them run out of bugs to find, or get bored :P

What's the problem if they run out of bugs to find? Would that not imply that there are no exploits left to be made?

Because if they get bored, they'll find other things to exploit/break. It's in their nature.

Re: A Tale of Two Pwnies (Part 1)

#48

Post by mietek »

wvyar wrote: post #45
jerf wrote: post #30

Earlier quoted context omitted.

You don't write them in C. You write them in a not-yet-existing language that allows low-level, but safe, access. (Prototypes of this language certainly already exist, I'm not convinced any are ready for this level of prime time.) You probably also have some additional hardware support not yet existing. And while, yes, deep at the heart of the system there will be something or some set of somethings that, if screwed…

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

Re: A Tale of Two Pwnies (Part 1)

#49

Post by aboodman »

pilif wrote: post #22

In the end it all boiled down to old-style plugins. All the exploits were used to finally install and run an old-style NPAPI plugin. Just like ActiveX, these are binary code that usually runs outsidE of any sandboxing due to compatibility reasons. With NaCL or just the advances in HTML and related technologies, this kind of plugin really should have outlived its usefulness by now and maybe it's time to drop support -…

Wait until you see the other one. There are a surprising and depressing number of ways to get a browser to run native code on legacy operating systems.

Yes, plugins should go away. No, that won't stop this kind of thing :/.

Re: A Tale of Two Pwnies (Part 1)

#50

Post by shmageggy »

lawnchair_larry wrote: post #29
moistgorilla wrote: post #6

This really takes you into the mind of a hacker(the malicious kind). Judging from what I saw it seems they combine a ton of small exploits to produce a major security breach. The amount of understanding of the underlying system you need to have in order to put these exploits together is mind boggling. What do we do against people like this?

I don't like how you vilify him and call him malicious. Nothing about this was malicious. He even gave it to google for far less than it was worth. This was a legitimate audit and demonstration and it is wrong to associate anything negative with it. What do we do against people like this? You're asking the wrong question. Remember, he didn't put those bugs there. He didn't break anything. It was already broken. He ju…

Just to play angel's advocate, your parent could have been referring to an abstract malicious hacker, who would probably think the same way and use the same techniques as Pinky. The "mind of a hacker (the malicious kind)" is probably very much like the mind of Pinky, except for the parts governing ethics. And he asks what to do "against people like this", not what to do against Pinky himself.

But you are right, and it is valuable to point out that neither Pinky nor Homakov nor any other talented whitehat are in no way malicious.

Post reply on HN