9 ms·

Analysis of PS4's security and the state of hacking

210 points by jsnell 11y ago

nickpsecurity 11y ago
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 11y 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.
  - nickpsecurity 11y 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 11y 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.
  - nickpsecurity 11y 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.
    - Jasper_ 11y ago
      Sure. You can do all of this. But you'd also be requiring Sony to put in the effort to write an optimized compiler, debugger, and toolchain effort to bring FreeBSD up on a MIPS platform. MIPS is dead. You never talk about what an "accelerator" is in your case -- you say "stuff like disks and networking". Both of those already have dedicated hardware, and they're IO bound, not CPU bound, so an "accelerator" doesn't help much. What you want for an accelerator is something to accelerate graphics and physics, perhaps a "Graphics Processing Unit", and something realtime to do audio processing, like a "Digital Signal Processor". Modern computers already have both of those accelerators built-in. Your funky MIPS architecture doesn't add anything but dev annoyance.
- saidajigumi 11y 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 11y 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 ...
    - saidajigumi 11y ago
      Absolutely all of those three (and x86, obviously) were supported. I forget if ARM was supported back then, but I can't imagine that it isn't now.
  - monocasa 11y 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.
- mtanski 11y 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.
  - nickpsecurity 11y 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. :)
    - pandaman 11y ago
      GPU in PS4 has 18 cores, in Xbox one - 12. They work quite well. Not exactly powers of two, but neither is 48, to be honest. The problem with Cell was not that it had multiple cores. It was that it had to do a lot of graphics tasks to take the load off the weak GPU. And doing graphics on a CPU is quite hard. Doing so in concert with another GPU is doubly so. On the other hand, doing CPU work on GPU is much easier.
      - nickpsecurity 11y ago
        Good point. Powers of 2 a bit of a brain fart of mine. That adding more cores worked well was my point in recommending an Octeon-like design. Didn't know the PS3's graphics system sucked that bad. Trying to do a real GPU + a fake one would definitely be hard, esp if the CPU was hard to begin with.
      - mtanski 11y ago
- TD-Linux 11y 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.
  - nickpsecurity 11y 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.
    - TD-Linux 11y ago
      I'm comparing to things like: TI-83 - embarassingly bad hardware for the year 2000+, but everyone had one and you got to learn z80 assembly. Very similar to programming for 80's home computers. Gameboy Advance - really nice open source toolchain, fun hardware (classic framebufferless sprite / tile graphics, but very powerful), and being somewhat inexpensive and portable (this is long before the iPhone). Nintendo DS - by far my favorite system, it keeps the great toolchain of the GBA and still has the fun graphics hardware. Flash cartridges for this were cheap and plentiful, making development super easy. It also had primitive but very easy to use 3D graphics to combine with the traditional GBA hardware. It also had a touchscreen (when resistive was still cool), a wavetable synthesizer, wifi, and all sorts of other goodies to play with. Wii - the last system I thought was interesting before I stopped messing with consoles. It was still very PC like but had the neat controllers, was cheap, and had weird fixed function graphics inherited from the Gamecube.
      - nickpsecurity 11y ago
        Well, sure, odd and limited systems can certainly be fun to learn and bring to a usable state. You can play the same game with the PC hardware: it's called the demo scene (e.g. kkkrieger). Usually a different game with that kind of power, though. The game is to do the coolest stuff you can with the hardware. You might squeeze out extra performance, modify the software architecture, leverage components in creative ways, and so on. You should've had a lot of fun with Cell processor if you like hackery. It blended several different models into one interesting piece of hardware that could be tweaked into emulating them all and doing some side-by-side. More interesting (and useful!) than any of the above systems. That's why supercomputer people put a cluster of them to good use. :)
feld 11y 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 11y ago
  The article says userspace ASLR is used, and indeed presented a speed bump along the way.
  - feld 11y 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 11y 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 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 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.
- feld 11y 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-June/001646.html 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 11y ago
  Or they want people to think FreeBSD is more secure?
- feld 11y ago
  amluto, thanks for commenting about this. The fix is now getting pushed out: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc 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 11y ago
FreeBSD's default x86-64 calling convention doesn't pass arguments in registers?
- pcwalton 11y ago
  Presumably the function calling convention does, but not syscalls.
  - deleted 11y ago
    [deleted]
  - pbsd 11y 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 11y ago
When was this published?
- paulannesley 11y 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.html https://github.com/CTurt/cturt.github.io/commits/master/ps4.... Blame: https://github.com/CTurt/cturt.github.io/blame/master/ps4.html https://github.com/CTurt/cturt.github.io/blame/master/ps4.ht...
bagels 11y 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.

210 points by jsnell 11y ago

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 11y 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.
- nickpsecurity 11y 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 11y 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.
- nickpsecurity 11y 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.
  - Jasper_ 11y ago
    Sure. You can do all of this. But you'd also be requiring Sony to put in the effort to write an optimized compiler, debugger, and toolchain effort to bring FreeBSD up on a MIPS platform. MIPS is dead. You never talk about what an "accelerator" is in your case -- you say "stuff like disks and networking". Both of those already have dedicated hardware, and they're IO bound, not CPU bound, so an "accelerator" doesn't help much. What you want for an accelerator is something to accelerate graphics and physics, perhaps a "Graphics Processing Unit", and something realtime to do audio processing, like a "Digital Signal Processor". Modern computers already have both of those accelerators built-in. Your funky MIPS architecture doesn't add anything but dev annoyance.
saidajigumi 11y 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 11y 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 ...
  - saidajigumi 11y ago
    Absolutely all of those three (and x86, obviously) were supported. I forget if ARM was supported back then, but I can't imagine that it isn't now.
- monocasa 11y 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.
mtanski 11y 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.
- nickpsecurity 11y 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. :)
  - pandaman 11y ago
    GPU in PS4 has 18 cores, in Xbox one - 12. They work quite well. Not exactly powers of two, but neither is 48, to be honest. The problem with Cell was not that it had multiple cores. It was that it had to do a lot of graphics tasks to take the load off the weak GPU. And doing graphics on a CPU is quite hard. Doing so in concert with another GPU is doubly so. On the other hand, doing CPU work on GPU is much easier.
    - nickpsecurity 11y ago
      Good point. Powers of 2 a bit of a brain fart of mine. That adding more cores worked well was my point in recommending an Octeon-like design. Didn't know the PS3's graphics system sucked that bad. Trying to do a real GPU + a fake one would definitely be hard, esp if the CPU was hard to begin with.
    - mtanski 11y ago
TD-Linux 11y 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.
- nickpsecurity 11y 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.
  - TD-Linux 11y ago
    I'm comparing to things like: TI-83 - embarassingly bad hardware for the year 2000+, but everyone had one and you got to learn z80 assembly. Very similar to programming for 80's home computers. Gameboy Advance - really nice open source toolchain, fun hardware (classic framebufferless sprite / tile graphics, but very powerful), and being somewhat inexpensive and portable (this is long before the iPhone). Nintendo DS - by far my favorite system, it keeps the great toolchain of the GBA and still has the fun graphics hardware. Flash cartridges for this were cheap and plentiful, making development super easy. It also had primitive but very easy to use 3D graphics to combine with the traditional GBA hardware. It also had a touchscreen (when resistive was still cool), a wavetable synthesizer, wifi, and all sorts of other goodies to play with. Wii - the last system I thought was interesting before I stopped messing with consoles. It was still very PC like but had the neat controllers, was cheap, and had weird fixed function graphics inherited from the Gamecube.
    - nickpsecurity 11y ago
      Well, sure, odd and limited systems can certainly be fun to learn and bring to a usable state. You can play the same game with the PC hardware: it's called the demo scene (e.g. kkkrieger). Usually a different game with that kind of power, though. The game is to do the coolest stuff you can with the hardware. You might squeeze out extra performance, modify the software architecture, leverage components in creative ways, and so on. You should've had a lot of fun with Cell processor if you like hackery. It blended several different models into one interesting piece of hardware that could be tweaked into emulating them all and doing some side-by-side. More interesting (and useful!) than any of the above systems. That's why supercomputer people put a cluster of them to good use. :)

feld 11y 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 11y ago
The article says userspace ASLR is used, and indeed presented a speed bump along the way.
- feld 11y 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 11y 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 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 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.

feld 11y 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-June/001646.html 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 11y ago
Or they want people to think FreeBSD is more secure?
feld 11y ago
amluto, thanks for commenting about this. The fix is now getting pushed out: https://www.freebsd.org/security/advisories/FreeBSD-SA-15:21.amd64.asc 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 11y ago

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

pcwalton 11y ago
Presumably the function calling convention does, but not syscalls.
- deleted 11y ago
  [deleted]
- pbsd 11y 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 11y ago

When was this published?

paulannesley 11y 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.html https://github.com/CTurt/cturt.github.io/commits/master/ps4.... Blame: https://github.com/CTurt/cturt.github.io/blame/master/ps4.html https://github.com/CTurt/cturt.github.io/blame/master/ps4.ht...

bagels 11y 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.