

Pwn2Own results for Wednesday (Day One) - gioi
http://www.pwn2own.com/2014/03/pwn2own-results-for-wednesday-day-one/

======
SiVal
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 memory management gives you no
benefit but does expose you to a possible vulnerability if you make a mistake.
If the default, lazy option were to let the well-tested runtime do the job for
you, yet you could do a little extra work and get manual override wherever you
wanted, and manual override everywhere brought you essentially back to C, I
think we would have much safer code without a noticeable loss of performance.

Edit: I just realized in the shower that I was saying "memory management" when
I meant direct "memory manipulation" more generally. I'm including arrays
accessed by memory address rather than by bounds-checked index, pointer
arithmetic, etc., not just malloc and free.

~~~
pcwalton
> 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 stronger. Getting safety doesn't
mean giving up manual memory management, as Rust shows (disclaimer: I work on
Rust). You just have to need to have a language or system that enforces that
you use safe manually-managed idioms. The idea that safety requires giving up
performance (e.g. opting into a garbage collector, or even a runtime) is not
true in most cases. In a properly designed system, safety doesn't even require
opting into a runtime.

~~~
SiVal
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?

~~~
letney
This is exactly what Servo[1] is.

[1] [http://www.fastcolabs.com/3027664/under-the-hood-of-
mozillas...](http://www.fastcolabs.com/3027664/under-the-hood-of-mozillas-new-
multi-core-browser-and-the-open-source-language-that-powers-i)

------
conorh
Looks like day 2 happened already and had some pretty good exploits:

[http://www.pwn2own.com/2014/03/pwn2own-results-thursday-
day-...](http://www.pwn2own.com/2014/03/pwn2own-results-thursday-day-two/)

~~~
gioi
[https://news.ycombinator.com/item?id=7401371](https://news.ycombinator.com/item?id=7401371)

------
rwg
_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.

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

~~~
rwg
"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
                <key>ProgramArguments</key>
                <array>
                        <string>/usr/sbin/ocspd</string>
                </array>
    

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.

------
sitkack
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.

~~~
Ellipsis753
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.

~~~
ChuckMcM
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?

~~~
sitkack
I have a more doable sketch of this, running in a guest account on a raspberry
pi over xvnc. Laptop is firewalled from net, raspberry pi is booted from read
only media. Would need hardware ethernet firewall between laptop and raspberry
pi to only allow VNC traffic.

