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

Pwn2Own results for Wednesday (Day One)

pwn2own.com

Post reply on HN
Print view View original

11–20 of 23 posts

Re: Pwn2Own results for Wednesday (Day One)

#11

Post by rwg »

bfish510 wrote: post #3
rwg wrote: post #2

At Pwn4Fun, Google delivered a very impressive exploit against Apple Safari launching Calculator as root on Mac OS X. I'll bet it was ocspd they exploited. The CRL handling code in libsecurity is awful, and ocspd runs as root without a sandbox profile.

How can you tell if a process runs as root or is run within a sandbox?

"ps" will show the effective uid ocspd is running as:

    % ps aux|grep ocspd
    root              534   0.0  0.0  2442712   2036   ??  Ss    3:53PM   0:00.04 /usr/sbin/ocspd
I don't know how to show the sandbox a running process is contained in, but it's easy enough to show that launchd runs ocspd directly, without sandbox-exec:

    % grep -A3 ProgramArguments /System/Library/LaunchDaemons/com.apple.ocspd.plist
            ProgramArguments
            
                    /usr/sbin/ocspd
It's possible for a process to programmatically place itself in a sandbox (see /usr/include/sandbox.h), but a quick look at the source to ocspd and a quick disassembly of what actually ships with OS X 10.9.2 shows ocspd does not do that.

Re: Pwn2Own results for Wednesday (Day One)

#12

Post by SiVal »

pcwalton wrote: post #9
SiVal wrote: post #5

It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. In the majority of places in your code, manual me…

> It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. That's true, but I would claim something even s…

Would Firefox be better (more secure and with no performance handicap) if written in Rust? I realize that there is an enormous amount of existing code that shouldn't be thrown away, but if Mozilla wanted to create a browser from scratch today (or in a couple of years, when Rust has been debugged and polished), would they write it in Rust?

Re: Pwn2Own results for Wednesday (Day One)

#13

Post by letney »

SiVal wrote: post #12
pcwalton wrote: post #9

Earlier quoted context omitted.

> It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. That's true, but I would claim something even s…

Would Firefox be better (more secure and with no performance handicap) if written in Rust? I realize that there is an enormous amount of existing code that shouldn't be thrown away, but if Mozilla wanted to create a browser from scratch today (or in a couple of years, when Rust has been debugged and polished), would they write it in Rust?

This is exactly what Servo[1] is.

[1] http://www.fastcolabs.com/3027664/under-the-hood-of-mozillas...

Re: Pwn2Own results for Wednesday (Day One)

#14

Post by hershel »

pcwalton wrote: post #9
SiVal wrote: post #5

It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. In the majority of places in your code, manual me…

> It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. That's true, but I would claim something even s…

Pcwalton, do you guys at mozilla think servo could be foolproof against sandbox escapes, or that this is a bit unrealistic ?

Re: Pwn2Own results for Wednesday (Day One)

#15

Post by pcwalton »

hershel wrote: post #14
pcwalton wrote: post #9

Earlier quoted context omitted.

> It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. That's true, but I would claim something even s…

Pcwalton, do you guys at mozilla think servo could be foolproof against sandbox escapes, or that this is a bit unrealistic ?

There's no such thing as "foolproof against sandbox escape" without proving a sandbox, as well as all it depends on, correct. But I believe that memory safety is a security advance.

Re: Pwn2Own results for Wednesday (Day One)

#17

Post by Ellipsis753 »

sitkack wrote: post #16

What this shows is that if you are using a machine connected to the internet, assume you have been rooted. If you are paranoid, do all of your surfing in a VM over Tor and reset that VM state after every launch.

Good idea but there's quite a lot of exploits in virtual machines that let them infect the host machine too. :P So it's really pretty hard to stay safe. You could always run your OS from a read-only CD? At least you'd be none-infected on each reboot.

Re: Pwn2Own results for Wednesday (Day One)

#18

Post by mikeash »

Ellipsis753 wrote: post #17
sitkack wrote: post #16

What this shows is that if you are using a machine connected to the internet, assume you have been rooted. If you are paranoid, do all of your surfing in a VM over Tor and reset that VM state after every launch.

Good idea but there's quite a lot of exploits in virtual machines that let them infect the host machine too. :P So it's really pretty hard to stay safe. You could always run your OS from a read-only CD? At least you'd be none-infected on each reboot.

Until someone infects your BIOS, anyway.

Re: Pwn2Own results for Wednesday (Day One)

#19

Post by ChuckMcM »

Ellipsis753 wrote: post #17
sitkack wrote: post #16

What this shows is that if you are using a machine connected to the internet, assume you have been rooted. If you are paranoid, do all of your surfing in a VM over Tor and reset that VM state after every launch.

Good idea but there's quite a lot of exploits in virtual machines that let them infect the host machine too. :P So it's really pretty hard to stay safe. You could always run your OS from a read-only CD? At least you'd be none-infected on each reboot.

My favorite is you run the browser on a different machine and you place a webcam near it that you can visit on your primary machine. Sending keystrokes and mouse moves to the browser machine using an infrared laser to create a unidirectional serial link to the machine.

Air gap AND lasers, how cool is that?

Re: Pwn2Own results for Wednesday (Day One)

#20

Post by Someone »

SiVal wrote: post #5

It appears that most of these attacks relied on exploiting the unfortunate design of C, which makes manual memory management the default and safe, managed memory the special case. It should be the reverse. Speed will always matter, but you don't have to use risky, manual memory mgt everywhere to get speed; you just need it in the few spots where it makes a difference. In the majority of places in your code, manual me…

Your edit almost made me eat my comment, but I will go further: there's nothing risky about manual memory management, as long as the compiler and/or runtime prohibit you from accessing memory you didn't allocate, adding null pointer and boundary checks (which may need runtime support to get the size of an allocated memory block) where the compiler cannot guarantee that you only access memory you allocated.

The reverse situation, garbage-collecting systems that do nothing to prevent you from dereferencing null pointers or going out of bounds, is just as dangerous as C.

Post reply on HN