Shmat MacOS Issue

[xpcmdshell]

Which versions of MacOS has LibAFL been tested on? I'm running into an issue with shmat failing. I haven't filed an issue/bug for this, since I wasn't sure yet if it was user error, or if there was a deeper issue in the code itself.

I'm using the latest commit on the main branch, and here is my system configuration:

➜  ~ sw_vers
ProductName:	macOS
ProductVersion:	11.5
BuildVersion:	20G71

➜  ~ sysctl kern.sysv.shmmax kern.sysv.shmmin kern.sysv.shmseg kern.sysv.shmall
kern.sysv.shmmax: 524288000
kern.sysv.shmmin: 1
kern.sysv.shmseg: 32
kern.sysv.shmall: 131072000

➜  ~ csrutil status
System Integrity Protection status: disabled.

I was interested in the Frida support for some MacOS fuzzing, so I tried out the frida_libpng example:

✗ target/debug/frida_libpng ./libpng-harness.so LLVMTestOneInput ./libpng-harness.so --cores=0
Workdir: "/Users/user/dev/LibAFL/fuzzers/frida_libpng"
spawning on cores: [0]
child spawned and bound to core 0
I am broker!!.
[/Users/user/dev/LibAFL/libafl/src/bolts/llmp.rs:2178] "New connection" = "New connection"
[/Users/user/dev/LibAFL/libafl/src/bolts/llmp.rs:2178] addr = 127.0.0.1:49803
Connected to port 1337
[/Users/user/dev/LibAFL/libafl/src/bolts/llmp.rs:2178] stream.peer_addr().unwrap() = 127.0.0.1:49803
Setting core affinity to CoreId { id: 0 }
[/Users/user/dev/LibAFL/libafl/src/events/llmp.rs:837] "Spawning next client (id {})" = "Spawning next client (id {})"
[/Users/user/dev/LibAFL/libafl/src/events/llmp.rs:837] ctr = 0
We're a client, let's fuzz :)
First run. Let's set it all up
The application panicked (crashed).
Message:  An error occurred while fuzzing: Unknown("Failed to map the shared mapping")
Location: src/fuzzer.rs:256

Backtrace omitted.

Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Inserting a small debug panic print at that location (libafl/src/bolts/shmem.rs) like this:

 panic!(
            "LAST ERR (from_id_and_size): id={}, id_int={}, map_size={}, map=0x{:x}, err={}",
            id,
            id_int,
            map_size,
            map as c_int,
            std::io::Error::last_os_error()
        );

We get the following result:

 LAST ERR (from_id_and_size): id=1179649, id_int=1179649, map_size=268435456, map=0xffffffff, err=Invalid argument (os error 22)

The documentation for shmat states that EINVAL can be caused by the following:

shmid is not a valid shared memory identifier.
shmaddr specifies an illegal address.

Interestingly, if we check ipcs -a output while the broker is still running but the client has crashed, we see a shm entry with the id that was passed in the crashing code, which I imagine indicates that it's correct:

m 1179649 0x00000000 --rw-------  user    staff  user    staff      1 268435456  17316  17315 23:09:32 23:09:32 23:09:32

And the 2nd parameter, shmaddr, is 0, so shmat should just choose the mapping address. This call seems like it'd be correct to me, maybe someone else has insight into what could be failing? Other info that might be helpful is what the working MacOS environment looks like that the code was tested in.

Thank you!

[s1341]

1. We are aware of an issue with shm on macos, related to differences between the implementation of shmctl on macos vs other unixes. We have a plan to fix it, but haven't got there yet.
2. frida mode currently only truly supports aarch64.

[domenukk]

Wrt the shared maps, apparently MacOS behaves different to Linux here. You can use a simple restarting mgr for now to just do some fuzzing, if you want. To scale to multiple cores, we first have to fix the bug 😬

[xpcmdshell]

Cool, I'll try the SimpleRestartingEventManager as a drop in for now

[domenukk]

Started development on a fix in #238
Not working yet though as MacOS is just odd sometimes

[s1341]

@domenukk yes. Coverage should work on x86_64.

[domenukk]

Just as an update to this, fuzzing on MacOS using frida should now fully work. Still missing from ASAN and cmplog