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

31–40 of 56 posts

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

#31

Post by itsokimbatman »

matrix12 wrote: post #27
itsokimbatman wrote: post #25

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

Are there any real CTF's done against OpenBSD to present this evidence?

Not that I'm aware of, but as someone who works in security, I've exploited a bunch of bugs against real world, hard targets both for my own educational purposes and also as part of my job with client engagements. I'm not going to pretend I'm the best in the world, but I'm decent. More importantly, I know a lot of folks with hats of many colors who are a lot better than I am.

When Luca Todesco (the person who wrote that toot) tells you your exploit mitigations are trash, you listen.

Like I said, I'm not going to make any claims to being an elite hacker. I have a cool job that I love, and I enjoy doing this stuff for fun too to keep my skills sharp. But reading through that presentation, there's nothing that made me pause and think "This is a game over scenario." If you have a moderately powerful bug with halfway decent primitives these mitigations aren't really going to stop anyone.

An elite team like NSO group? This isn't going to effect them one bit.

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

#32

Post by mikewarot »

ngneer wrote: post #20
mikewarot wrote: post #12

The fact that you must trust programs to do the right thing is the root cause of the problem. There exist operating systems and security models that stop this type of attack dead in its tracts. This is fallout from the failure of Multics, and the rise of Unix.

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 protect the wiring inside the house from many forms of trouble.

--

When you run a program on a PC, by default it runs with all of your credentials. There's nothing stopping it from ANY side effects. You're restricted to carefully considering each piece of software, and hoping it doesn't take your system down, or worse.

A system that specifies at/during runtime what resources a program is allowed to access and how (via capabilities) can't be subverted to reach outside those restrictions, no matter how clever or confused the program gets.

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

#33

Post by anthk »

pnm45678 wrote: post #8
rini17 wrote: post #4

Earlier quoted context omitted.

no actually after 50 years of "how to shoehorn memory into something C can use" we reap the rewards

perhaps it's time we stopped shoehorning memory to fit C and just used more memory-safe languages?

Multics had both. It's the Unix inspiration. Imagine something more secure and with a better hardware design than Unix.

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

#34

Post by anthk »

Zurrrrr wrote: post #21
mikewarot wrote: post #12

The fact that you must trust programs to do the right thing is the root cause of the problem. There exist operating systems and security models that stop this type of attack dead in its tracts. This is fallout from the failure of Multics, and the rise of Unix.

> The fact that you must trust programs to do the right thing is the root cause of the problem. Well, yeah, that's the issue. That's why relying on simple DAC is so inadequate. Really, some kind of MAC is needed. Things like pledge and unveil are nice but clearly inadequate (I actually had a pretty braindead discussion on that recently, with someone not understanding the differences and trying to equate them out of i…

Ahem. It might not solve the issue but it's to late to bring Multics back. And I acknowledge Multics was far better in security.

Also, something I would like it's the polar opposite with the MIT/ITS philosophy + Emacs. There's GNU Guix, but I don't like Ice-9's crap on Guile as if it was the default, I prefer SRFI's. Something hackable from the start, with Scheme as the REPL and a Scheme based window manager. Gnome with Mutter bindings to Guile instead of GJS would be a dream.

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

#35

Post by Zurrrrr »

anthk wrote: post #34
Zurrrrr wrote: post #21

Earlier quoted context omitted.

> The fact that you must trust programs to do the right thing is the root cause of the problem. Well, yeah, that's the issue. That's why relying on simple DAC is so inadequate. Really, some kind of MAC is needed. Things like pledge and unveil are nice but clearly inadequate (I actually had a pretty braindead discussion on that recently, with someone not understanding the differences and trying to equate them out of i…

Ahem. It might not solve the issue but it's to late to bring Multics back. And I acknowledge Multics was far better in security. Also, something I would like it's the polar opposite with the MIT/ITS philosophy + Emacs. There's GNU Guix, but I don't like Ice-9's crap on Guile as if it was the default, I prefer SRFI's. Something hackable from the start, with Scheme as the REPL and a Scheme based window manager. Gnome w…

Multics? I was talking more about things like RSBAC.

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

#36

Post by blacklion »

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.

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

#37

Post by anthk »

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…

         man login.conf

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

#38

Post by anthk »

itsokimbatman wrote: post #31
matrix12 wrote: post #27

Earlier quoted context omitted.

Are there any real CTF's done against OpenBSD to present this evidence?

Not that I'm aware of, but as someone who works in security, I've exploited a bunch of bugs against real world, hard targets both for my own educational purposes and also as part of my job with client engagements. I'm not going to pretend I'm the best in the world, but I'm decent. More importantly, I know a lot of folks with hats of many colors who are a lot better than I am. When Luca Todesco (the person who wrote t…

If you think Theo and co. are newcomers to security, y'all gonna have a bad time. You and the NSO group.

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

#39

Post by anthk »

itsokimbatman wrote: post #26
IAmLiterallyAB wrote: post #16

Was lucky enough to watch this in person. One of the best talks of the conference. The immutable bit together with the syscall bit is going to be a real pain for shell code

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.

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

#40

Post by beachhead »

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. I think something like that would help rather than hinder OpenBSD.

Post reply on HN