Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Synthetic Memory Protections: An update on ROP mitigations [pdf]

openbsd.org

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#51

Post by tete »

saagarjha wrote: post #9

> iOS is execute-only; Android tried a few years ago (abandoned) Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/ . > Dumb applications that invent their own ABI (very few) I mean…

> This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision

While I understand where that comes from, I'd argue that OpenBSD does both. There is quite a few more general approaches in the system.

In my opinion (which might be wrong, please disagree!) you need both, because one tends to have that issue that layers and layers of general mitigation are added, but when someone takes a look the issues tend to arise where the specific setup and general context is exploited which is harder to protect against.

There is a great talk that I can't find right now, that is about a company network that was pretty securely set up, but taking a look at the constellation (including specifications of standard protocols) is abused to still compromise it.

I am not sure if that's the best approach, but while I agree it's overall better to completely rule out a whole class of bugs/attacks go for it, however it's usually with exceptions which is why these these things are even still a topic.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#52

Post by tete »

t-3 wrote: post #24
mburee wrote: post #11

Earlier quoted context omitted.

OpenBSD?

It's worth noting that the new mitigations discussed in the talk are only available in -current. They'll be in the next release though (which should be coming in the next few months).

April being the best guess currently, though end of likely, because May 1st is the usual goal. The best guess being April, because it's what the (non-finished) 7.3 page says for the month right now. Of course that's not a guarantee, but it makes it likely. Also a branch of 7.3 already exists.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#53

Post by mikewarot »

ngneer wrote: post #47
mikewarot wrote: post #32

Earlier quoted context omitted.

First let me offer an analogy What would the use of electricity be like without circuit breakers? You'd have to carefully and completely vet each new device you wanted to connect to your house, and make sure that you weren't going to burn the wires up, or even take down the power grid. (AKA the power in the 1960s TV show Green Acres) With circuit breakers, you carefully limit the availability of current to loads, and…

Awesome, thanks for the great analogy and explanation! What you are proposing is the compartmentalization approach, like sealing off areas of a ship or cordoning off a fire using walls (or fire trails in a forest). I am definitely a proponent of capability based security for tighter control over permissions and limiting the damage when things go wrong. The only problem with that is that some programs by definition MU…

Capability Based Security is a much richer choice than the simple App Permissions you see on phones, it includes "powerboxes" which replace the Dialog Box your application calls with the same result... only the User picks the file, and the OS enforces the resulting selection (instead of trusting the app to do it)

As far as the user is concerned, it works the same way... but as far as we programmers are concerned, it now makes it impossible to get at files the user doesn't want the program to reach, in a very simple and transparent way.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#54

Post by saagarjha »

tete wrote: post #51
saagarjha wrote: post #9

> iOS is execute-only; Android tried a few years ago (abandoned) Wonder if the author is aware of the reasons why this was disabled (it's functionally gone on both platforms). On iOS newer processors have PAC which provides much stronger guarantees against ROP and Linux disabled it because execute-only mappings bypass PAN: https://blog.siguza.net/PAN/ . > Dumb applications that invent their own ABI (very few) I mean…

> This brings us to OpenBSD's strategy for exploit mitigation, which is in my eyes has far too much tunnel vision While I understand where that comes from, I'd argue that OpenBSD does both. There is quite a few more general approaches in the system. In my opinion (which might be wrong, please disagree!) you need both, because one tends to have that issue that layers and layers of general mitigation are added, but whe…

I think OpenBSD has tunnel vision on the wrong part of an exploit. Like they'll read a blog post on how to construct a ROP chain and instead of figuring out how you might prevent someone from subverting control flow they look at the tool used to find gadgets and try to make that harder. Or if they see exploits that spray syscall instructions they will block them in JIT regions. The problem here is that these aren't actually the hard parts that need significant effort to change for an attacker, they're really just whatever happened to be convenient. You can do a very specific mitigation that e.g. hardens a problematic API but you really want to make sure an attacker goes "hmm, I am not really sure what I would do if you blocked this, I guess I'll have to think for a while about how I might even get started" versus "sigh, this is annoying, guess I need to try the other way that is a little more work".

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#55

Post by saagarjha »

beachhead wrote: post #49
saagarjha wrote: post #43

Earlier quoted context omitted.

People have done this in the past, at this point most people are just going to meme about it rather than respond. The response that they get is always “if it’s so easy why don’t you hack it?” which is quite frankly more effort than anyone wants to spend on an OS that doesn’t really harm anyone just sitting by itself layering all sorts of “mitigations” on itself. They’re basically completely divorced from what any rea…

I hear you. I guess I'd just like to see more hacking and less of the memes. For me I think again that it would help more than hurt. I'm an old man now and maybe I've gone a bit soft but I don't see much benefit in mocking and am more interested in helping even if that means wasting a bit of time.

Someone might make a CTF challenge out of it someday I guess.

Re: Synthetic Memory Protections: An update on ROP mitigations [pdf]

#56

Post by beachhead »

saagarjha wrote: post #45
beachhead wrote: post #41

Earlier quoted context omitted.

Can you share more about what you are working on right now? If not, hopefully we'll see something about it in the near future once you're done.

I hope so! There’s not much to share yet because I’m still working on evaluating how well it would work, but the aim is to make n-day exploits infeasible to deploy to devices that are still vulnerable. It’s difficult because we are have very little we can work with when dealing with an attacker who can fully compromise the device, but some preliminary analysis of the strategy against recent exploits and approximation…

I'm looking forward to it!
Post reply on HN