Redqueen doesn't handle strcmp() calls on linux userspace target #212
Comments
|
---upd--- It seems, that if there are unused-bytes in payload data before place WHERE redq-dict C-string must be put -- kAFL can't save such testcase to corpus correct. 94 │ if (len >= 4) {
95 │
96 │ /* set a byte in the bitmap to guide your fuzzer */
97 │ //((uint8_t *)trace_buffer)[0] = 0x1;
98 │ if (payload_buffer->data[0] == '!') {
99 │
100 │ //((uint8_t *)trace_buffer)[1] = 0x1;
101 │ if (payload_buffer->data[1] == 'N') {
102 │
103 │ //((uint8_t *)trace_buffer)[2] = 0x1;
104 │ if (payload_buffer->data[2] == 'Y') {
105 │
106 │ //((uint8_t *)trace_buffer)[3] = 0x1;
107 │ if (payload_buffer->data[3] == 'X') {
108 │
109 │ //((uint8_t *)trace_buffer)[4] = 0x1;
110 │ /* Notifiy the hypervisor and the fuzzer that a "crash" has
111 │ * occured. Also a string is passed by this hypercall (this is
112 │ * currently not supported by AFL++-Nyx) */
113 │ if (*(int*)&(payload_buffer->data[4]) == 0xdeadbeef) {
114 │ if (!strcmp(&(payload_buffer->data[10]), "PWNED!!!")) {
115 │ hprintf("PWNED\n");
116 │ char *magic;
117 │ magic = &(payload_buffer->data[20]);
118 │ if (!memcmp(magic, "RedQueen", sizeof("RedQueen"))) {
119 │ void **crash = 0xdeadbeef;
120 │ *crash = 0xcafefeed;
121 │ kAFL_hypercall(HYPERCALL_KAFL_PANIC_EXTENDED,
122 │ (uintptr_t) "Something went wrong\n");
123 │ }
124 │ }
125 │ }
126 │ }
127 │
128 │ }
129 │
130 │ }
131 │
132 │ }
133 │
134 │ }Backend pass that code and increase edges count up to 59, but: In case of next branches: all works as expected I have some experience with AFL's cmplog backend stuff, in qemu userspace. |
|
Please, can anybody test this behaviour and discard or approve it? |
|
poke @il-steffen |
Thanks for debugging this. Can you check the logic on frontend side as well? :-) The Redqueen analysis + first mutation stage is here: The "state logic" implements the mutation pipeline of the workers. For the Redqueen stage, it first performs coloring + tracing using I am not sure if the initial stage should have found the input already, but in principle the colorizer will first do some input expansion so the unused bytes should have been passed. If the trace logic found the compare, you should be able to see it written to the traces, where it is picked up by the InfoGatherer stuff. Your log indicates that the input was eventually found in the later havoc stage using the RQ-dictionary:
However, the supposedly crashing payload also seems wrong here. This "received new input" is what the worker eventually hands off to the manager process as the crashing input, and the manager will store it after checking that the bitmap is unique. But it seems that even the worker/self.execute() got the wrong input here, so maybe the execution is out of sync somehow? I suspect your issue is related to how the redqueen mutator handles the strings. This was python2 code once which has a messed up way of handling strings, and we didn't really have a lot of tests for migrating to python3 except that it still seemed to work. |
|
Kindly appreciated for reply, guys. I was able to move on a bit with strings. There were several issues, at least.
Btw, in CMPLOG impl of qemuafl there was very cool stuff, which split ints to bytes. I don't sure if it possible to do that trick with intel-pt (but think it should), if it isn't done yet?
Atm it pass first strcmp() and totally stacked on second memcmp(). and now we got: /dev/shm/kafl_root/snapshot/fast_snapshot.mem_dump is too big to perform |
|
Whew, thanks! Suggestion @Wenzel: Lets collect/create a couple redqueen trace files that we load into RedqueenInfoGatherer() and call get_proposals() on. Then fix up some of this code to generate good inputs. The kafl debug tool has some very old, very unlikely to work, code for this: https://github.com/IntelLabs/kafl.fuzzer/blob/master/kafl_fuzzer/debug/core.py#L321 |
|
Hi guys, any upd on this? @il-steffen @Wenzel |
|
Hi @kotee4ko, this issue has been in my TODO list for a while, unfortunately it's not trivial to investigate and solve. I'd like to point out that I really appreciate the quality of your bug report though, thank you for this. |
I reach some troubles with redqueen feature: it doesn't handle
strcmp()calls on linux userspace target.Launch command:
kafl fuzz \ --kernel /boot/vmlinuz-$(uname -r) \ --initrd forkserver.cpio.gz \ --memory 512 \ --sharedir $PWD \ --purge -t 2 -ts 1 --log-hprintf --log-crashes \ --append "nokaslr oops=panic nopti mitigations=off console=ttyS0 hprintf=7" \ -ip0 0x401000-0x4af000 \ --redqueen --redqueen-hammer --redqueen-simple --redqueen-hashes --grimoire --radamsa \ -p 1 --qemu-path /usr/src/QEMU-Nyx/x86_64-softmmu/qemu-system-x86_64Some debugging of qemu-nyx approve, that redqueen strcmp() hooks are reached and works as expected, or, at least, see strcmp() calls is target and could access guest args.
The target, as always, is simple, statically built, small harness with several branches to test integers and strings extractions.
full backtrace:
But kafl doesn't insert findings to corpus.
---upd---
After some time fuzz session log next in stdout:
So, the magic string was found and successfully injected to input, the harness react by crashing, as expected, and kAFL log this. But not new path in corpus/regular neither correct (crashing) payloads in corpus/crashes are present.
Any advices?
Thanks.
Originally posted by @kotee4ko in #12 (comment)
The text was updated successfully, but these errors were encountered: