Adds "local" payload type and privesclib #255
Conversation
This adds the "local" package for use with exploit specific use cases that have appeared multiple times. The first payload in this contains a shared object library for linux that clocks in at 204 bytes and handles privilege escalation when run as root. This has come up a few times and could be potentially useful elsewhere. A note, this uses both "embed" to get the binary into the payload variable directly and "go:generate" on the local/privesclib_amd64.asm file in order to allow for dynamic generation.
|
|
||
| // Defines default structures and payload functions. | ||
| type ( | ||
| PrivEscLibraryPayload struct{} |
There was a problem hiding this comment.
I think my complaint is that PrivEscLib (and privesclib_amd64) are really generic names. Is that... ok? Like I can see a world where we want to do more of these right?
There was a problem hiding this comment.
I was also quite torn on these, but that part is supposed to be generic. Since that's the type that gets functions defined from: ie the actual payload call in this is local.PrivEscLibrary.AMD64(). I think that keeping the top level struct type as broad is fine, but maybe the function signature should be something like LinuxSharedObjectAMD64() vs AMD64() or even have another type for OS and then keep the architecture?
I'm not sold on any of these as the best way to do it (I'm not even positive embedding binaries is a good idea period), so if you have any thoughts I'm happy to rearrange.
There was a problem hiding this comment.
I do think that having something with the final signature of local.PrivEscLibrary.Linux.AMD64() would probably be fine and cover most the use cases while being specific enough to prevent confusion.... but I also hate all the dots lol. We could even do a local.PrivEscLibrary.LinuxSharedObjectAMD64(), but I fear the protocol signature explosion.
There was a problem hiding this comment.
I'm not sold on any of these as the best way to do it (I'm not even positive embedding binaries is a good idea period), so if you have any thoughts I'm happy to rearrange.
🤣
I am also not positive. However, it's an interesting step forward and code can always be removed from the library. I'm not afraid to bump the major version :) I think maybe more experience using this part will inform us on how it should be improved. That's fine by me. Go ahead and merge when you are ready.
This adds the "local" package for use with exploit specific use cases that have appeared multiple times. The first payload in this contains a shared object library for linux that clocks in at 204 bytes and handles privilege escalation when run as root. This has come up a few times and could be potentially useful elsewhere.
A note, this uses both "embed" to get the binary into the payload variable directly and "go:generate" on the local/privesclib_amd64.asm file in order to allow for dynamic generation.
I also did a quick clarification on the reverse payload godoc because it was a little confusing.