4 ms·

I don't pretend to fully understand everything that's going on with this exploit, but I give Pinkie Pie full props for being such a genius. Reading these types

I don't pretend to fully understand everything that's going on with this exploit, but I give Pinkie Pie full props for being such a genius. Reading these types of write ups always leaves me with a sense of awe for the hacker.

zobzu 14y ago
tbh the exploits themselves are relatively simple when you read them. its like when I say speaking 7 languages is incredible. When it's what you do all day, it's also straightforward. what's generally impressive, is finding them (and thus writing the proper tools to find them) and having enough dedication to keep at it. the other impressive thing is the lack of generic fixes even thus we know how to make them happen (which involve using pretty much using a "written-from-the-ground-up" OS), apparently, security is fairly low on the "it makes us lose money, let's fix it all properly" scale ;-)
- daeken 14y ago
  Generally speaking, vulnerability discovery is fairly straightforward, just requires tenacity and a knack for knowing where to look/fuzz. Exploitation on this level requires a huge amount of creativity, to know how to fit the building blocks together into a functioning exploit. Regardless, I'd put them on about the same level of difficulty, having done both (though I've done far, far more discovery than exploitation). > the other impressive thing is the lack of generic fixes even thus we know how to make them happen (which involve using pretty much using a "written-from-the-ground-up" OS), apparently, security is fairly low on the "it makes us lose money, let's fix it all properly" scale ;-) This is the real meat of this comment, though, and it's what I really want to respond to. We don't have generic fixes that actually meet our requirements in terms of performance and developer time. The real, fundamental problem is simple: memory corruption should not be possible; put another way, pointers considered harmful. Possible solutions to this are the Singularity/RenrakuOS/SharpOS/MOSA approach, where you have a tiny, trusted compiler that takes on the security risk and generates native code, with the entire rest of the system running in safe, managed code. I promoted this concept for a while -- RenrakuOS is mine -- but at the end of the day, the performance is just not there yet, and won't be for quite a while. But even more than that, it doesn't solve any of the problems with logic-related vulnerabilities; these become more and more important as you eliminate the lower level bugs.
  - nikcub 14y ago
    > Exploitation on this level requires a huge amount of creativity, to know how to fit the building blocks together into a functioning exploit. This is what I consider hacking. Not writing another Javascript library.
  - martinced 14y ago
    "The real, fundamental problem is simple: memory corruption should not be possible; put another way, pointers considered harmful. Possible solutions to this are the Singularity/RenrakuOS/SharpOS/MOSA approach..." That is very interesting and it's reassuring to know there are still people out there who value security from the ground up, so thanks to you for working on RenrakuOS (didn't know it existed, I like the concept).
  - zobzu 14y ago
    " know how to fit the building blocks together " which is, in essence, finding all the vulns at various levels. maybe it's just a difference of point of view after all. I'm thinking that knowing system architecture, and programming with the various languages used by the program is necessary and natural for exploit research, but maybe that's because I've been around that stuff for too long. And yes, I was hinting at the kind of OSes you're mentioning. When you're left with logic bugs, it's a huge step forward IMO. Most importantly, as long as you're not having all data in one container the failure of one component does not impact the next component unless you made terrible messaging choices, those being generally extremely controlled to avoid these (which arguably browser vendors are attempting to do right now, but that their browser-based-OSes are trying to decouple)

zobzu 14y ago

tbh the exploits themselves are relatively simple when you read them. its like when I say speaking 7 languages is incredible. When it's what you do all day, it's also straightforward. what's generally impressive, is finding them (and thus writing the proper tools to find them) and having enough dedication to keep at it. the other impressive thing is the lack of generic fixes even thus we know how to make them happen (which involve using pretty much using a "written-from-the-ground-up" OS), apparently, security is fairly low on the "it makes us lose money, let's fix it all properly" scale ;-)

daeken 14y ago
Generally speaking, vulnerability discovery is fairly straightforward, just requires tenacity and a knack for knowing where to look/fuzz. Exploitation on this level requires a huge amount of creativity, to know how to fit the building blocks together into a functioning exploit. Regardless, I'd put them on about the same level of difficulty, having done both (though I've done far, far more discovery than exploitation). > the other impressive thing is the lack of generic fixes even thus we know how to make them happen (which involve using pretty much using a "written-from-the-ground-up" OS), apparently, security is fairly low on the "it makes us lose money, let's fix it all properly" scale ;-) This is the real meat of this comment, though, and it's what I really want to respond to. We don't have generic fixes that actually meet our requirements in terms of performance and developer time. The real, fundamental problem is simple: memory corruption should not be possible; put another way, pointers considered harmful. Possible solutions to this are the Singularity/RenrakuOS/SharpOS/MOSA approach, where you have a tiny, trusted compiler that takes on the security risk and generates native code, with the entire rest of the system running in safe, managed code. I promoted this concept for a while -- RenrakuOS is mine -- but at the end of the day, the performance is just not there yet, and won't be for quite a while. But even more than that, it doesn't solve any of the problems with logic-related vulnerabilities; these become more and more important as you eliminate the lower level bugs.
- nikcub 14y ago
  > Exploitation on this level requires a huge amount of creativity, to know how to fit the building blocks together into a functioning exploit. This is what I consider hacking. Not writing another Javascript library.
- martinced 14y ago
  "The real, fundamental problem is simple: memory corruption should not be possible; put another way, pointers considered harmful. Possible solutions to this are the Singularity/RenrakuOS/SharpOS/MOSA approach..." That is very interesting and it's reassuring to know there are still people out there who value security from the ground up, so thanks to you for working on RenrakuOS (didn't know it existed, I like the concept).
- zobzu 14y ago
  " know how to fit the building blocks together " which is, in essence, finding all the vulns at various levels. maybe it's just a difference of point of view after all. I'm thinking that knowing system architecture, and programming with the various languages used by the program is necessary and natural for exploit research, but maybe that's because I've been around that stuff for too long. And yes, I was hinting at the kind of OSes you're mentioning. When you're left with logic bugs, it's a huge step forward IMO. Most importantly, as long as you're not having all data in one container the failure of one component does not impact the next component unless you made terrible messaging choices, those being generally extremely controlled to avoid these (which arguably browser vendors are attempting to do right now, but that their browser-based-OSes are trying to decouple)