Live data from Hacker News

A Tale of Two Pwnies (Part 1)

blog.chromium.org

21–30 of 82 posts

Re: A Tale of Two Pwnies (Part 1)

#21

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?

IMHO, as Pinkie demonstrated, there isn't anything foolproof that you can do against a malicious hacker. Having sponsored and/or incentives for white hat hackers to find and report exploits seems to be the best answer.

If this stance were adopted into the wider software development community, would it turn more black hat hackers into white hats?

EDIT: grammar

Re: A Tale of Two Pwnies (Part 1)

#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 - at least support for all plugins but a few whitelisted ones from the older ages.

Like Flash and maybe QuickTime (though both have a terrible security track record).

Though considering the persistence of piling up bugs that was happening here, for all we know, there would have been a different exploit somewhere else that could have worked even without NPAPI. It would just close one more attack surface.

Re: A Tale of Two Pwnies (Part 1)

#23
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

> "If you don't have a young girl"

Most of my recent MLP exposure is through my 20-something brother. Apparently he's in one of the larger demographics for the modern show. See http://en.wikipedia.org/wiki/My_Little_Pony:_Friendship_Is_M...

Re: A Tale of Two Pwnies (Part 1)

#24

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?

The term you're looking for is "cracker".

Re: A Tale of Two Pwnies (Part 1)

#26
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?

Indeed. It is the Singularity Research OS. Links: http://en.wikipedia.org/wiki/Singularity_(operating_system)

http://research.microsoft.com/en-us/projects/singularity/

Re: A Tale of Two Pwnies (Part 1)

#27

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?

The term you're looking for is "cracker".

No, crackers defeat software protections. No one in the security industry (legitimate or otherwise), uses the term cracker for anything other than that, despite what Eric S Raymond et al would like you to believe.

Re: A Tale of Two Pwnies (Part 1)

#28
post #11
post #9

Earlier quoted context omitted.

I really doubt that we'll be using programming environments where memory corruption is possible in 2040.

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 :-)

Re: A Tale of Two Pwnies (Part 1)

#29

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 just found the hole by reading exactly what you gave him.

What you should be asking is, how do we stop making software with vulnerabilities. The goal is to make it so that there is no hole to find, not to get rid of the hole-finders.

Re: A Tale of Two Pwnies (Part 1)

#30
post #11
post #9

Earlier quoted context omitted.

I really doubt that we'll be using programming environments where memory corruption is possible in 2040.

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 up, could do something like memory corruption, it will be made as small as possible, verified as rigorously as possible, and get the tar beaten out of it until it's as safe as humanly possible.

This will not be a security paradise, because there's plenty of other ways to screw up. Even if we magick a perfect capabilities-based system into existence in 2040, with every desirable property that is promised fully manifested, programmers will still fail to correctly use it, because security is profoundly a Hard Problem. But the same freaking buffer exploit for the ten millionth time should be a thing of the past. (Library support should also be well on its way to making cross-site scripting a thing of the past, too.)

Post reply on HN