undefined | Better HN

0 pointskstrauser2d ago0 comments

Would xz still have been able to alter opensshd without IFUNC?

0 comments

rwmj2d ago

Yes, liblzma could have used multiple routes to take over sshd. Once you're running inside the process it's game over. The exact details, like how they used ifunc and an audit hook, are very interesting, but ultimately not that important.

robertdfrench1d ago

I've updated the post and am offering $500 if you can pull this attack off without ifunc.

rwmj1d ago

$500 isn't worth my time and I don't trust you'd pay up. But for anyone who wants to attempt to get him to pay up, here are three simple approaches:

(A1) In a POSIX constructor function in liblzma, set an alarm(2) for a few seconds later (once sshd has fully loaded).

(A2) In the alarm callback locate the original function that was patched using dlfcn, and mmap a page of modified code over the top that calls the exploit.

Or:

(B1) POSIX constructor function, call clone(2) to start a background thread.

(B2) In the background thread, sleep for a little, then patch the code as in A2 above.

Or:

(C1) POSIX constructor function that completely replaces the sshd process with a workalike that contains the exploit.

In A & B, for OSes (not Linux) that deny mmap, you'll need to find a struct or stack frame used by the function and work out how to adjust the data it uses or find a function pointer and exploit that.

1 more reply

AshamedCaptain1d ago

It is weird to limit to "the same attack". Why does it even have to be the same attack? From the moment sshd loads your modified lib, you're literally running code with root privileges on the victim machine. You can literally run _any_ attack you wanted, with zero persistence. This is worse than a OpenSSH RCE.

Even in your own talk you basically admit this, so what are you doing here? If you think there's something here that everyone is missing but you don't, why not actually explain what it is?

1 more reply

okanat1d ago

You can always populate .init_array section with a hidden constructor. It would work just like ifunc and would always execute at shared library load time.

robertdfrench1d ago

I think .init_array is too late in the game. ifunc lets you hijack the loader, because it is sort of like a plugin or dynamic config for the loader itself. Everything should be loaded and resolved by the point that .init_array stuff starts getting triggered, though ELF is dark and full of terrors so who knows really.

j / k navigate · click thread line to collapse

0 comments

rwmj2d ago

robertdfrench1d ago

I've updated the post and am offering $500 if you can pull this attack off without ifunc.

rwmj1d ago

$500 isn't worth my time and I don't trust you'd pay up. But for anyone who wants to attempt to get him to pay up, here are three simple approaches:

(A1) In a POSIX constructor function in liblzma, set an alarm(2) for a few seconds later (once sshd has fully loaded).

(A2) In the alarm callback locate the original function that was patched using dlfcn, and mmap a page of modified code over the top that calls the exploit.

Or:

(B1) POSIX constructor function, call clone(2) to start a background thread.

(B2) In the background thread, sleep for a little, then patch the code as in A2 above.

Or:

(C1) POSIX constructor function that completely replaces the sshd process with a workalike that contains the exploit.

1 more reply

AshamedCaptain1d ago

Even in your own talk you basically admit this, so what are you doing here? If you think there's something here that everyone is missing but you don't, why not actually explain what it is?

1 more reply

okanat1d ago

You can always populate .init_array section with a hidden constructor. It would work just like ifunc and would always execute at shared library load time.

robertdfrench1d ago

j / k navigate · click thread line to collapse