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

41–50 of 56 posts

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

#41

Post by beachhead »

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…

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.

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

#42

Post by saagarjha »

anthk wrote: post #39
itsokimbatman wrote: post #26

Earlier quoted context omitted.

This is literally going to be a minor annoyance at most for the handful of attackers that go after OpenBSD.

Today even doing something outside the syscalls is not allowed.

Which syscalls?

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

#43

Post by saagarjha »

beachhead wrote: post #40
itsokimbatman wrote: post #25

Honestly the only thing that really needs to be said: https://nso.group/@qwertyoruiop/110086216898968720

It would be cool for one of these folks (or anyone really) to show us why these things won't work. I see people I respect in that thread but I'm also very tired of hearing about how trivial these things are and not seeing someone spend, according to them, very little time to bypass these things. Obviously, I'm not smart enough to do it or else I'd be doing it. However, I'm not going around making wild claims either.…

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 real-world exploit these days looks like (blind ROP, really?) or how attackers work (“99% secure will stop them!!”) but somehow always really convoluted and optimized at stopping one very specific exploit flow rather than a general technique. The real solution for stopping ROP/JOP is going to be CFI, shadow stacks, etc. rather than trying to kludge something on hardware that doesn’t support it.

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

#44

Post by saagarjha »

blacklion wrote: post #36
itsokimbatman wrote: post #25

Honestly the only thing that really needs to be said: https://nso.group/@qwertyoruiop/110086216898968720

Could you explain what does "boomer" means here? I think I understand "Ok, boomer" in general but can not extrapolate this understanding to security talk.

Outdated, simplistic, incorrect.

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

#45

Post by saagarjha »

beachhead wrote: post #41
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…

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 approximations of how they might change if we ship are promising. The key point is that we expect our strategies to “expire” on a given timeline and need to explicitly design in a way to respond to changing techniques in a way that is highly asymmetric. We’ve found that the closer to the actual bug you place a mitigation the harder it becomes to work around, and we think we have a new way to get very close cheaply.

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

#46

Post by mikewarot »

anthk wrote: post #37
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…

man login.conf

How does using this allow the user at run-time to specify that a task should only have read access to X and dynamically give write access to fu.bar?

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

#47

Post by ngneer »

mikewarot wrote: post #32
ngneer wrote: post #20

Earlier quoted context omitted.

Could you please elaborate? One must trust programs that handle data to handle data, that requirement is difficult to get around.

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 MUST have access to user data and therefore by definition WOULD cause harm. So, for example, an email client needs network access and to upload attachments from the filesystem, in order to perform its function. Then, those same said permissions can be subverted. Tricky...

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

#48

Post by ngneer »

muyuu wrote: post #28
ngneer wrote: post #20

Earlier quoted context omitted.

Could you please elaborate? One must trust programs that handle data to handle data, that requirement is difficult to get around.

Ideally, the scope of failure to do with the data what they should do, would be bounded. In reality, programmes asked to handle some data can fail to do the expected handling and produce undetermined side-effects.

Precisely! We need to structure programs so as to behave within a well defined transitive data closure.

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

#49

Post by beachhead »

saagarjha wrote: post #43
beachhead wrote: post #40

Earlier quoted context omitted.

It would be cool for one of these folks (or anyone really) to show us why these things won't work. I see people I respect in that thread but I'm also very tired of hearing about how trivial these things are and not seeing someone spend, according to them, very little time to bypass these things. Obviously, I'm not smart enough to do it or else I'd be doing it. However, I'm not going around making wild claims either.…

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.

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

#50

Post by tete »

beachhead wrote: post #40
itsokimbatman wrote: post #25

Honestly the only thing that really needs to be said: https://nso.group/@qwertyoruiop/110086216898968720

It would be cool for one of these folks (or anyone really) to show us why these things won't work. I see people I respect in that thread but I'm also very tired of hearing about how trivial these things are and not seeing someone spend, according to them, very little time to bypass these things. Obviously, I'm not smart enough to do it or else I'd be doing it. However, I'm not going around making wild claims either.…

While I don't say it is, this is also a classical tactic to discredit something that could be a problem. This strategy has been used with other projects. If you are worried that this has potential it will ruin your project/income you're going to shit-talk it.

Some years ago there was a leak of plans to do that very with Tor. Spreading FUD so less secure systems are used. Discrediting contributors, turning people against each other and so on.

Common theme. If someone has a way to break something, they'd at least gain publicity for it, if they have any positive interest they'll at least mention a source or provide any chance for rebuttal (the whole point of the scientific method), if neither happens be at least skeptical.

Post reply on HN