Pwn2Own results for Wednesday (Day One)
pwn2own.com
Pwn2Own results for Wednesday (Day One)
1–10 of 23 posts
Re: Pwn2Own results for Wednesday (Day One)
#2At 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.
Re: Pwn2Own results for Wednesday (Day One)
#3At 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?
Re: Pwn2Own results for Wednesday (Day One)
#4Looks like day 2 happened already and had some pretty good exploits:
http://www.pwn2own.com/2014/03/pwn2own-results-thursday-day-...
Re: Pwn2Own results for Wednesday (Day One)
#5It 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.
Re: Pwn2Own results for Wednesday (Day One)
#6Looks like day 2 happened already and had some pretty good exploits: http://www.pwn2own.com/2014/03/pwn2own-results-thursday-day-...
Re: Pwn2Own results for Wednesday (Day One)
#7It 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…
Mozilla's Rust & Servo go exactly in this direction, thankfully.
Re: Pwn2Own results for Wednesday (Day One)
#8At 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?
On a mac Activity Monitor will show you that, also there are also things like top, ps aux and pgrep. These would work:
pgrep -lf -U root | grep processname
or:
ps aux | grep root | grep processname
Re: Pwn2Own results for Wednesday (Day One)
#9It 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 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.
Re: Pwn2Own results for Wednesday (Day One)
#10It 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…
[deleted]