Let's isolate xz from sshd

[JustinCappos]

We'd like a POC that isolates xz from sshd. See here if you don't know why this is an interesting thing to make.

An easy way to do this is to set up an rpc client / server and to run sshd and xz in different cages. The eventual setup will have the rpc client run from sshd, which will call into the rpc server which runs xz.

A few tips:

• A good first step is to compile a "hello world" rpc client / server and get this running first to communicate between cages
• The chosen rpc library should use Unix Domain Sockets or Pipes for communication in order to be fast
• You should try to compile sshd normally natively and also for Lind first, before making any changes
• You only need to have your rpc server for xz understand the calls that sshd uses
• Ideally your changes will be minimal. Try to avoid changing code you don't need to change.
• You would normally want to restrict the system call API for the xz program, but for simplicity, you can ignore this for now.

[ve1nard]

Implementation using the loopback address:
https://github.com/ve1nard/sshdRPC

[CacheUseOnly]

My current understanding is to

1. rewrite all function calls in sshd calling xz functions into a RPC.
2. rewrite xz functions that will be called by sshd in RPC schemas
3. setup a RPC server for xz to handle RPC calls from sshd

However, there are two questions block me:

1. sshd does not directly need liblzma

• $ objdump -p $(which sshd) | grep -i 'needed' does not include liblzma.so.5 . In fact, the xz backdoor vulnerability targets OpenSSH but it was done via systemd. [1]
• Solution 1: Find another example.
• Solution 2: Modify the liblzma so that the liblzma.so.5 is substituted with another version which uses RPC.

2. It is mentioned that "Ideally your changes will be minimal. Try to avoid changing code you don't need to change." I wonder if the steps aforementioned is the minimal change one could make.

[JustinCappos]

I think the example people are familiar with is this one, so I'd prefer something closer to your Solution 2. If you need to change source code in other places, that's fine too. It's just a good idea not to rewrite things you don't need to (as you note).

…

On Thu, Oct 3, 2024 at 6:08 PM Yuxuan Luo ***@***.***> wrote: My current understanding is to 1. rewrite all function calls in sshd calling xz functions into a RPC. 2. rewrite xz functions that will be called by sshd in RPC schemas 3. setup a RPC server for xz to handle RPC calls from sshd However, there are two questions block me: 1. sshd does not directly need liblzma - $ objdump -p $(which sshd) | grep -i 'needed' does not include liblzma.so.5 . In fact, the xz backdoor vulnerability targets OpenSSH but it was done via systemd. [1 <https://www.ssh.com/blog/a-recap-of-the-openssh-and-xz-liblzma-incident#:~:text=Linux%20%27systemd%27%20super%2Dservice%20application%20library%20%27libsystemd%27%C2%A0depends%20on%20the%20malicious%20%27liblzma%27%C2%A0library.%20Many%20Linux%20server%20applications%20use%20%27libsystemd%27%20allowing%20%27systemd%27%C2%A0to%20monitor%20and%20control%20execution.%20This%20creates%20an%20indirect%20dependency%20between%20the%20application%20and%20%27liblzma%27.%C2%A0> ] - Solution 1: Find another example. - Solution 2: Modify the liblzma so that the liblzma.so.5 is substituted with another version which uses RPC. 2. It is mentioned that "Ideally your changes will be minimal. Try to avoid changing code you don't need to change." I wonder if the steps aforementioned is the minimal change one could make. — Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD7R44QKARMU4SHTYETZZW57DAVCNFSM6AAAAABGVIJYHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJSGQZDIOBRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[CacheUseOnly]

@JustinCappos @yzhang71 WIP: https://github.com/CacheUseOnly/sshd-isolation

[CacheUseOnly]

@JustinCappos The function the previous work converted is sd_notify(), a systemd function call rather than one that comes from liblzma. In the next PoC, would you like to patch sshd and substitute the sd_notify() or patch the xz and substitute arbitrary functions from liblzma?

[JustinCappos]

I don't think it really matters, so long as it's over RPC. What are the pros and cons of each approach?

…

On Mon, Nov 4, 2024 at 9:21 PM Yuxuan Luo ***@***.***> wrote: @JustinCappos <https://github.com/JustinCappos> The function the previous work converted is sd_notify(), a systemd function call rather than one that comes from liblzma. In the next PoC, would you like to patch sshd and substitute the sd_notify() or patch the xz and substitute arbitrary functions from liblzma? — Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGRODZB44TFA4WLDQPRXTTZ7AMP3AVCNFSM6AAAAABGVIJYHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGA4DONJYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[CacheUseOnly]

They don't differ as two approaches, they are two options isolating different library calls for the PoC. If you don't have a strong preference I'll do the patching xz - liblzma pair since I've already done a similar work.

I don't think it really matters, so long as it's over RPC. What are the pros and cons of each approach?
…
On Mon, Nov 4, 2024 at 9:21 PM Yuxuan Luo @.> wrote: @JustinCappos https://github.com/JustinCappos The function the previous work converted is sd_notify(), a systemd function call rather than one that comes from liblzma. In the next PoC, would you like to patch sshd and substitute the sd_notify() or patch the xz and substitute arbitrary functions from liblzma? — Reply to this email directly, view it on GitHub <#366 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGRODZB44TFA4WLDQPRXTTZ7AMP3AVCNFSM6AAAAABGVIJYHGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJWGA4DONJYGA . You are receiving this because you were mentioned.Message ID: @.>