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

Mandatory enforcement of indirect branch targets

undeadly.org

Post reply on HN
Print view View original

121–130 of 134 posts

Re: Mandatory enforcement of indirect branch targets

#121

Post by andersa »

ComputerGuru wrote: post #117
andersa wrote: post #52

Earlier quoted context omitted.

Windows also recently implemented a far better version of this called Extended Flow Guard (XFG) that not only checks whether the location is a valid destination, but also whether it's a valid destination for that specific source. For example, for any virtual function call or function pointer call, the destination must have a correct tag with the hash of the arguments. It's much more secure, and also faster, since loa…

There’s a great article on XFG here [0] but it observed that a failed XFG check downgrades to a regular CFG check instead of a denial.. meaning it adds zero extra protection? Perhaps this behavior has changed since the preview they tested, though! [0]: https://www.offsec.com/offsec/extended-flow-guard/

That can't be right, it would be entirely pointless then. It looks like the article was written during a pre-release time, so maybe it wasn't fully enabled?

I've not yet been able to use XFG in any production software, due to the requirement of rebuilding every static linked library with it enabled. But it didn't seem to fall back to CFG when I was testing it in a toy program.

Re: Mandatory enforcement of indirect branch targets

#124

Post by PrimeMcFly »

saagarjha wrote: post #123
PrimeMcFly wrote: post #120

Earlier quoted context omitted.

SELinux/RSBAC/AppArmor/grsecurity and similar.

These largely require buy-in from applications just like pledge.

They absolutely don't, that's the key difference.

What makes you think otherwise?

Re: Mandatory enforcement of indirect branch targets

#125

Post by messe »

gizmo686 wrote: post #119
jeffbee wrote: post #50

Earlier quoted context omitted.

Interesting, thanks for pointing this out! Just yesterday I was gazing at some program containing two consecutive xor rax, rax. I thought what’s the point? But as you point out it might be a NOP sled designed to be that specific length.

That would be surprising. xor is often used like that to set a register to 0, which is far from a nop. I'm not sure why it would do it twice, but it might be as simple as the compiler being stupid.

The second one is effectively a nop though.

The fact that it’s xor rax, rax rather than xor eax, eax is also interesting as it’s one byte longer for exactly the same effect (modifying the bottom 32 bits of a register clears the upper 32 bits). It makes me think there’s something weird going on other than compiler stupidity. I’d be interested in seeing the code it was compiled from.

Re: Mandatory enforcement of indirect branch targets

#126

Post by saagarjha »

PrimeMcFly wrote: post #124
saagarjha wrote: post #123

Earlier quoted context omitted.

These largely require buy-in from applications just like pledge.

They absolutely don't, that's the key difference. What makes you think otherwise?

You can’t just stick sandboxing around arbitrary apps without them breaking.

Re: Mandatory enforcement of indirect branch targets

#127

Post by PrimeMcFly »

saagarjha wrote: post #126
PrimeMcFly wrote: post #124

Earlier quoted context omitted.

They absolutely don't, that's the key difference. What makes you think otherwise?

You can’t just stick sandboxing around arbitrary apps without them breaking.

The technologies I listed are not sandboxing, as that term refers to a different category of technology.

And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.

Re: Mandatory enforcement of indirect branch targets

#128

Post by Ericson2314 »

NoZebra120vClip wrote: post #76
Ericson2314 wrote: post #60

Earlier quoted context omitted.

Yeah this is good stuff, and why I felt bad about making the comparison. Not saying Theo is in that camp, but Linus is trying to be less abrasive in general, and Theo is not.

Perhaps we're reading into their personalities more than we should, based on public social-media appearances. Egos tend to become exaggerated when benevolent dictator types make public statements. Their candor and bluntness on a mailing list or Twitter may be completely different than their demeanor and their kindness toward collaborators in private. Now we have the very public drama that happened between Theo and th…

Both their jobs are largely reading and writing emails on mailing lists. They are some of the few famous people where the paper trail is what counts for many intents and purposes.

Re: Mandatory enforcement of indirect branch targets

#129

Post by saagarjha »

PrimeMcFly wrote: post #127
saagarjha wrote: post #126

Earlier quoted context omitted.

You can’t just stick sandboxing around arbitrary apps without them breaking.

The technologies I listed are not sandboxing, as that term refers to a different category of technology. And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.

Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.

Re: Mandatory enforcement of indirect branch targets

#130

Post by PrimeMcFly »

saagarjha wrote: post #129
PrimeMcFly wrote: post #127

Earlier quoted context omitted.

The technologies I listed are not sandboxing, as that term refers to a different category of technology. And you're right, kind of; you need to set the permissions for apps, but that doesn't mean they need cooperation from the software developers. The whole point is that they don't. With those technologies you can lock down complex closed source programs, something not possible with pledge.

Those seem to be of the category of “I have a program and I want to restrict what it does” which seems like a sandbox to me. The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.

It's not a sandbox though, because it's a different type of technology. You can say it's a type of sandbox in concept, and you could make an argument, but referring to it as a sandbox in a technical discussion simply isn't correct.

> The problem here is that trying to figure out what goes on this list is difficult for arbitrary programs, even when you’re the one writing it. When you’re just applying it to third party software it’s very likely something will not function correctly.

That's why there are things like, for example, SELinux permissive mode, where you run the software as needed and observe the permissions it needs, and then grant it those permissions while denying everything else.

Post reply on HN