client/server_args with spaces in them?

[agoodm88]

Hi,

Thanks for sharing this interesting work!

I am trying to fuzz a proprietary binary/client where client_args and server_args have spaces in them - for example --server --arg1 value1 --arg2 value2 --arg3

I am fairly sure I am missing something json related here but if I try to run the session with just 1 argument I get expected output, if I try with 2 arguments I get output I would expect if I missed the spaces out.

I am guessing I need to do something different to ensure the spaces are not stripped as if I recall correctly json strips spaces out, any pointers would be appreciated?

Alan

[domenukk]

Just adding multiple args should work, similar to this:

FitM/config/fitm-args.ts3.json

Line 10 in 6e851f3

"server_args": ["license_accepted=1"],

You'd do for example

"server_args": ["--server", "--arg1", "value1", "--arg2", "value2", "--arg3"],

[agoodm88]

Thanks, this does get me further. After completing this I run into criu complaining that it wants netspace to dump a tun link:

(00.012713) Error (criu/tun.c:306): tun: Net namespace is required to dump tun link

So I thought, ok thats easy, run the binary via unshare -n, however now I run into a similar problem to my args. It looks like the spaces are stripped out of the command. I did try ["modifying", "the", "client"], etc lines similarly to the args lines, but it seems it wants a string and not a sequence. I guess this means I cant fuzz this application in this way?

[domenukk]

The arg list gets passed to the final process here:

FitM/src/lib.rs

Line 296 in 6e851f3

.args(cli_args)

It should not strip anything?
If your target really needs a single arg with a space in between, you would want to do it "like this" but that would be very uncommon

[agoodm88]

Its not the arg list I am struggling with now, criu wants the application running in a separate namespace (I believe?) so I tried modifying "client": and "server": lines adding /usr/bin/unshare -n to the start. Like "client": "/usr/bin/unshare -n /path/to/binary",

Upon running it like this I get a "no such file or directory" error in active-state/stdout which suggests to me that the spaces are being stripped out of the binary path?

[domenukk]

Ah yes you want to specify the files to be included in the namespace/snapshot, see

FitM/config/fitm-args.ts3.json

Line 15 in 6e851f3

"server_files": [

Basically the namespace starts a new chroot env and we copy everything we need into it to run

[agoodm88]

I am not sure what you mean here, I tried adding the path to the directory with the binary in it to "server_files": ["/path/to/dir/with/binary"]

But I still see Error while loading /usr/bin/unshare -n /path/to/dir/with/binary/actualbinary: No such file or directory in active-state/stdout so I feel like I am barking up the wrong tree?

[domenukk]

The path inside the namespace might be different, the files get copied in, if that makes sense?
Maybe if you run it with the QEMU_STRACE=1 env variable set (in the config Json) you can see which path it tries to access

[agoodm88]

I am already running with "server_envs": {"QEMU_STRACE": "1"},

Where would I see the errors which might help me diagnose what is wrong?

What is server_files supposed to be set to? Full path to each required binary? Something else?

[domenukk]

You'd see it in the stderr file (or whatever the name is).
unshare -n creates a new namespace, I's not really be surprised if that breaks things. Why do you need it?

[agoodm88]

Because criu is complaining that I need one if I dont use one:

(00.012713) Error (criu/tun.c:306): tun: Net namespace is required to dump tun link

Maybe its not possible to fuzz vpn server/client in this manner?

[domenukk]

I guess the tub device needs to be part of the namespace? It's a rather low level component, I wouldn't know the answer. Likely our network emulator wouldn't work on the tun device, either

[agoodm88]

I am only really interested in fuzzing the negotiation phase of the connection, not the established connection once its created (where data would flow over the tun device). Does this change anything?

[domenukk]

Can you maybe nop out all tun device interactions? That'd probably be the easiest solution.
Else you may need to add the tun device to the namespace FitM creates somehow

[derpsteb]

Heyhey,
cool to see that you are testing the fuzzer :)!

Can you try changing this line to look like this: unsafe { sys_clone(libc::CLONE_NEWNET | libc::CLONE_NEWPID | libc::CLONE_NEWNS | libc::SIGCHLD)? };?
This is the function we use to create the new namespaces in which the targets will get restored. Adding CLONE_NEWNET will spawn the target inside a new net ns. This worked for me in the sense that I could see a different net namespace id inside the target, compared to the net ns on the host. I checked by adding lsns to the restore.sh.tmp. This way the restore script will print the namespace ids before restoring the process.

I am not sure if you really want to do this as your target might now not have access to the tun interface that you possibly created manually in the initial net ns(?).
Otherwise you could try to run unshare -n /bin/bash before starting fitm all together?

[agoodm88]

Thanks for your input. Running the entire session in an 'unshare -n /bin/bash' session, and the edit you posted above both result in things getting further before bailing out. Both methods seem to achieve the same outcome.

It now seems to be bailing out because its trying to read from /dev/urandom which apparently isnt available. I did try adding /dev/urandom to the server_files but this didnt help.