Simple Hello-World BOF crashes beacon

[1mansh0w]

I'm having issues creating a simple BOF that does not crash the beacon.

Here is the source code:
/~https://github.com/1mansh0w/sliver-bof-hello-world

Here is how I load it:

1. extensions rm say-hello
2. extensions load "[path]/hello_world"
3. extensions install "[path]/hello_world"  

When I now execute the BOF only once it always runs fine, but executing it a couple of more times will always crash the beacon. The client will just show this message and the session is lost:

"Executing say-hello ..."

Am I doing something wrong or is there a bug in sliver?

Thanks!

---

I'm running the latest version of Sliver (v1.5.22) on both client and server. I'm cross-compiling the BOF on Ubuntu.

[rkervella]

Are you running a beacon or a session?

[1mansh0w]

Hey @rkervella, thanks for looking into it!

I'm running a session. Maybe it is related to: #679

To clarify a little bit more: If I just run the BOF once on a session it works without problems. But if I execute it multiple times (right after another) the session crashes.

[rkervella]

Yup I've seen that happens with other BOFs, as stated in #679. I'll have a look. I looked at your BOF, it seems fine so it's definitely a bug on our side.

[rkervella]

The annoying part is I can't seem to be able to reproduce:

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World
[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello
[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[server] sliver (TIRED_BUSTLE) > say-hello

[*] Successfully executed say-hello (coff-loader)
[*] Got output:
Hello World

[1mansh0w]

Interesting... You have used my Makefile with mingw I guess?

Is there any information/log when executing BOFs? Like a stack trace or any information that helps debugging once a session/beacon crashes?

[rkervella]

Yes, if you generate your implant with --debug, and run it from a terminal, you should be able to see the crash.

[r00t0v3rr1d3]

sa-uptime and sa-resources when in beacon mode are consistent in eventually crashing for me

[rkervella]

sa-uptime and sa-resources when in beacon mode are consistent in eventually crashing for me

Only in beacon mode though?

[r00t0v3rr1d3]

For me, MOST of the instability / crashing seems to go away in session mode. Occasionally I can get those same BOFs to hang forever in session mode if I up arrow + enter really fast.

[moloch--]

Hurm, i wonder if its some race condition in the invocation?

[rkervella]

Yeah definitely looks like it

[1mansh0w]

What's really weird now is that since I have created an implant with --debug, it doesn't crash anymore. I can neither crash my say-hello BOF nor sa-uptime:

So I thought there was an issue with the old implant, but when I created a new implant (v1.5.22) without --debug, I can get it crashing again:

I didn't look into the code yet to see whether the debug flag really contributes to the issue.
@r00t0v3rr1d3 Do you see any difference when you build an implant with the debug flag?

[rkervella]

Hm that's good to know. I'll run more tests with obfuscation enabled, see if crashes. If so, it could also be an issue with garble.

[r00t0v3rr1d3]

I haven’t tried recently to build one using the —debug flag. Not with Golang, but with C - I’ve definitely seen things where the debug version magically saved crashes from happening that the exact same code in “release” form would cause it to fall on its face.

[rkervella]

Alright I can reproduce with obfuscation enabled.

[rkervella]

Alright it was indeed a race condition, PR #797 should fix this one and #679 .