Analysis of PS4's security and the state of hacking

http://cturt.github.io/ps4.html

by jsnell • 11 years ago

210 47 11 years ago

cturt.github.io

Lots of good detail here. Raise your hand if you knew the switch to AMD would greatly benefit hacking vs custom, PPC chips. (raises hand) Now you know why I deployed security-focused stuff on PPC at one point. The economics of hacking alone work in your favor. :)

Personally, I think they should've tried to license Cavium's Octeon III processors: RISC (MIPS) ISA; 48 cores at 2.5GHz; many pre-made accelerator engines; huge I/O bandwidth. A royalty deal that made Cavium money for profit & continued R&D, while letting Sony have them cheap in PS4, would've made for one, badass gaming rig. Cavium might have had upgrades ready for PS5, too, given all the improvements they made going from Octeon II to III.

Everyone went with AMD instead. So, we get the real benefits of reuse of x86 code, low-costs, and reduced production issues. However, we also get all the black-boxes of risk in x86, a monoculture where an attack on AMD CPU's/firmware might break all game systems, inherent inefficiencies of x86, and lack of hardware differentiation (mainly accelerators) that developers can benefit from. Only time will tell if it was a good trade.

sliverstorm• 11 years ago

The reality is they don't need perfect security. Just "enough" to keep things like piracy at modest levels. For example, if your new system allows you to trounce your competitor and obtain most of the marketshare, it is easily worth a modest increase in piracy.

Sony has done MIPS (PS2) before, and they have done PPC (PS3) before. They might change their mind again for the PS5, but it's not like they didn't even think of MIPS or PPC.

nickpsecurity13• 11 years ago

Oh I agree. I was just pointing out it would happen. Happens every time a company jumps on a mainstream platform unless what they had before was horrific. What you say is the exact model for how device-manufacturers look at security. Well, that plus I.P. protection where appropriate. They mostly use obfuscations for that.

vvanders• 11 years ago

Sony got pretty burned by the SPU architecture on the PS3 by being late follower to XBox, This meant that developers were porting from Xbox or PC(!) which was the Wrong Thing(TM).

You could really make the SPUs scream if you knew what you were doing and the added benefit of better cache locality on other platforms. I think they went to a similar architecture to avoid the pain that it brought to the developers on their platform that weren't ready for it.

It's kind of a shame the PS3 hadn't lead. Almost every team that went PS3->360->PC saw huge gains(due to needing to pack into 256kb blocks for the SPU). Where as everyone that went (PC)->360->PS3 was in a world of pain.

nickpsecurity13• 11 years ago

I saw this one coming. It's why I put accelerators in there. Yeah, it's best to keep the hardware mostly like whatever developers are used to using and compatible with existing code. Cell was so radically different from typical systems, even SIMD/MIMD CPU's, that it was a pain to work with even for cross-platform companies.

The Cavium model is more what I was thinking. They make the processors simple, fast, and on a good NOC. Then, add accelerators for whatever. I'd straight up ask game companies what code, algorithms, patterns, etc keep popping up in their games and could be accelerated. I'd accelerate some of that. However, I'd mostly focus on low-level stuff like disks and networking that most developers would prefer to ignore. Solid, high-performance, real-time implementations of all that with hardware acceleration of critical paths. Octeon already does that. That plus a dedicate I/O processor & asynchronous interrupts. That will let the CPU focus on gaming stuff while getting massive utilization.

Beats the hell out of "throw more cores and cache at PC architecture." Intel and AMD certainly dominate in general performance. Yet, the amount of people, tooling, and dollars that go into that is mind-boggling. Of course, that my recommendation is the better model is obvious by the fact that Intel and AMD are taking it themselves. They're also both doing well with their "semi-custom" business that does that for clients.

saidajigumi2• 11 years ago

Now you know why I deployed security-focused stuff on PPC at one point. The economics of hacking alone work in your favor.

Perhaps true for a small-time, individual hacker. Over a decade ago, I recall being quite impressed by a professional pentest team whose tools included a lovely exploit authoring DSL embedded in a popular scripting language. That DSL allowed them to write "abstract" descriptions of specific software exploits, ala vs openssh vX.YpZ, then "render" (~~ compile) the exploit code automatically against any of their supported target architectures and/or OSes. (i.e. all of them.) Even though perfectly capable of it, they got tired of manually porting everything around.

This has also been a strong reminder for me that exploits are usually against the software, irrespective of the hardware architecture. It's easy for folks to get mixed up about that.

For something like hacking a PS4, the "obscure platform" logic might apply(), but never assume it applies to any attacker who can afford (n.b.: not just build) a sophisticated attack platform.

() With the caveat that now it's a numbers game, and you're up against bored teens/tweens with way too much time to throw at the problem.

rsync• 11 years ago

"That DSL allowed them to write "abstract" descriptions of specific software exploits, ala vs openssh vX.YpZ, then "render" (~~ compile) the exploit code automatically against any of their supported target architectures and/or OSes. (i.e. all of them.)"

Fair enough, but was one of those targets PPC ? MIPS ? Sparc ? Genuinely curious ...

monocasa3• 11 years ago

You're also up against hardware hackers who stand to make a buck selling prepackaged hardware exploits (AKA modchips). You'd be surprised how much resources these guys have available to them.

spott• 11 years ago

So, I'm kind of curious: It seems that the whole ROP thing depends on X86's CISC architecture in order to allow turing complete programming. Am I wrong in this understanding?

nickpsecurity13• 11 years ago

I don't assume anything and actually made security DSL's myself at one point for defence. The threat model was widely deployed malware and some targeted attacks. The ISA knocked out the malware plus targeted attacks according to monitoring. The more clever attacks we saw (firmware I guess) were blocked by guards and strong, app-level security. One thing I always got guards to do was modify the traffic patterns to make the system pretend to be a different type of system (eg Linux on x86). Even sophisticated attackers, unable to bypass or even see the guard, apparently couldn't get by because they were never smart enough to try an obscure OS + ISA combination.

That was a nice hold-up until I learned about separation kernels and split-trust architectures. That was a nice hold-up until recent work on modifying CPU's to increase security. Got plenty of those at concept stage that should do plenty with a few having been implemented by others w/ ranging Linux or FreeBSD support. Now, I'm working on verified specification and synthesis of hardware plus mask and mixed-signal verification to solve the last part of the problem.

On a side note, I told some people with simple IT needs to switch to PPC Mac's after Apple switched to x86. They just hated all the hacking and malware issues. Set them up with portable software on PPC so they could leave at any time and take their data with them. Predicted software would get supported for years, some of Internet would be usable, and replacement hardware would be cheap due to PPC Macs going on eBay. They're still using them today and I got another laptop as an air-gapped machine-in-progress last year for $80. Gonna port Tinfoil Chat transmit node to it if I get time. :)

mtanski4• 11 years ago

Games for a long time struggled to with scaling up to more then one core. Even today the games scale to like 2 or 4 cores. Just at the PS3 cell, it took a long time for games to really utilize the PS3's full potential. That's why I don't think that dropping 48 cores on game devs would have been a good business decision.

nickpsecurity13• 11 years ago

You can just drop 48 cores on them or you can drop 48 cores plus tools and patterns to use them well. There's been techniques for linear, reliable scaling in academic literature and even in industry (eg NonStop, MPP's) for years. There were also toolkits that helped automate that process using c-like languages.

That said, just because they can't use it right off the bat doesn't mean they won't figure it out over time. We really didn't get to see them try. The Xbox used a non-power-of-2, lame core count while Cell didn't use traditional cores at all. Apple to oranges a bit although 360 is a realistic comparison if the multicore tooling sucks.

So, what's Microsoft and Sony's recent approach? Drop a bunch of cores on them. :)

TD-Linux2• 11 years ago

Raise your hand if you knew the switch to AMD would greatly benefit hacking vs custom, PPC chips

Eh, I'd argue the opposite. The consoles being boring PC hardware has basically made hacking them pretty unrewarding.

nickpsecurity13• 11 years ago

What consoles were you using? The closest thing to PC hardware were the Xbox's, which was intentional. The Playstations used MIPS-based setups with tricks like scratchpad while PS3 had Cell processor. Had it been boring and PC-like, then porting to PS3 would've been a breeze.

feld4• 11 years ago

Capsicum is part of FreeBSD itself so it doesn't have to be listed separately in the list of Open Source Software.

I'm also surprised anyone thought it was using ASLR -- it's a huge effort to get that completed and working sanely, which is being handled by the HardenedBSD folks. Their work didn't even exist when the PS4 was released.

I think it's possible for Sony to backport it and use it, but seems unlikely they would do that at this stage.

I'd also like to point out that FreeBSD jails on PS4 means there are ~23 million units in the wild deploying that technology. Will take quite a while for Docker containers to catch up, haha :-)

zurn• 11 years ago

The article says userspace ASLR is used, and indeed presented a speed bump along the way.

feld4• 11 years ago

I think it's unlikely they would fork from the upstream FreeBSD kernel that much without contributing ASLR back. They would end up having to repeat it all again for Playstation 5.

Stranger things have happened, though.

amluto• 11 years ago

FreeBSD was vulnerable to BadIRET. Oddly, they never seem to have published an advisory, but the fix was here:

https://reviews.freebsd.org/rS275833

I thought the handling of that issue was very strange. I notified CERT, who apparently coordinated with FreeBSD, but no one ever really responded. The closest thing to an advisory that I can find at all is my post:

http://www.openwall.com/lists/oss-security/2015/07/09/1

which contains a PoC that crashes the system. It's almost certainly possible to turn it into privilege escalation, though.

Go figure. I suspect that the security community just doesn't pay as much attention to FreeBSD as they do to Linux.

feld4• 11 years ago

Probably has to do a lot with timing. At the time of your report, the Security Officer was DES. Life happened, and he wasn't able to keep up or respond to events as quickly.

As of June, Xin Li (previously Deputy Security Officer) has taken over as security officer and things have been handled very promptly and succinctly.

https://lists.freebsd.org/pipermail/freebsd-announce/2015-Ju...

edit: I'm passing word to FreeBSD security officers to see if they can review this

cbd1984• 11 years ago

Or they want people to think FreeBSD is more secure?

feld4• 11 years ago

amluto, thanks for commenting about this. The fix is now getting pushed out:

https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21...

In the future do not be afraid to bang a drum loudly or do whatever it takes to get people's attention. It's unfortunate this wasn't immediately acted upon, but the community is needed just as much as the core team to keep things on track.

Thanks again for airing it publicly; I know I'm glad my servers are patched now.

tptacek• 11 years ago

FreeBSD's default x86-64 calling convention doesn't pass arguments in registers?

pcwalton• 11 years ago

Presumably the function calling convention does, but not syscalls.

pbsd• 11 years ago

Neither does; the author is linking to the i386 documents, where there is indeed a difference between syscall and C calling conventions on some operating systems. On x86_64, everyone follows the SysV ABI and uses registers for both purposes.

maxjus• 11 years ago

When was this published?

paulannesley• 11 years ago

Originally on 2015-06-29, updated frequently and as recently as three days ago.

Commits: https://github.com/CTurt/cturt.github.io/commits/master/ps4....

Blame: https://github.com/CTurt/cturt.github.io/blame/master/ps4.ht...

bagels• 11 years ago

The section on ROP is fascinating. Has anyone done a ROP compiler?

Some program that takes a binary + c code -> address list?

If you think of the gadgets as being like assembler instructions, it seems like it'd be possible, though tricky to do.

Analysis of PS4's security and the state of hacking

Related Stories