Open dwendt opened 7 years ago
There are many difficult questions about static vs non-static due to the underlying crypto libraries that may or may not exist on the target host and conflicting versions. Also with the new OpenSSL 1.1 tree, revsh doesn't build at all. I'll keep this approach in mind as I go rewrite the crypto interface to handle other SSL/TLS libs (as a static OpenSSL 1.1 helloworld will segfault during initialization so, time to look into other libs.)
I haven't forgotten about this ticket though, I'm just short of time. I'll keep this ticket open until this all get rolled in, or decided against in the (hopefully near) future.
Cheers!
@emptymonkey: Far as static and cross compile setups, you may want to take a look at how Metasploit builds mettle via musl and deps built on it, and embedded w the payload. Would be rather nice to have the VPN pivots in mettle, in case you want to push some code :-).
Musl is the way to go for building a fully static revsh binary linked statically with a "statically" built OpenSSL 1.1.x library
Here are some examples:
Also something like: https://github.com/richfelker/musl-cross-make or https://github.com/GregorR/musl-cross
Would really make life easier for cross compiling
musl works fine to build this, you just need to remove one include, I believe it is :
#include <linux/if.h>
And of course you will need to cross-compile libssl.a and libcrypto.a as well using your toolchain
And yes, musl-cross-make is the easiest way to do this by far. See https://github.com/mzpqnxow/cross-compile-openssl for how to build openssl using a musl toolchain if you get stuck
No problem with <linux/if.h> include for me maybe that's for arm or mips ? I'm only compiling for x86_64-linux
The only hiccup I found is posix_openpt() defined in revsh.c It's needed to be defined for really ancient systems with glibc < 2.2.1 (CentOS "2.0" has glibc 2.2.4 !) and in Musl libc it's already defined and you even get multiple definition error while linking So I just ignore it with a simple flag -DMUSL when linking with musl libc
revsh.c
#if !defined(MUSL)
int posix_openpt(int flags){
return open("/dev/ptmx", flags);
}
#endif
common.h
#if !defined(MUSL) && !defined(FREEBSD)
int posix_openpt(int flags);
#endif
Hello, is it possible to share how to compile revsh properly with/without musl for x86_64-linux and arm (to run on raspberry pi)? I tried compiling many times and everything seems to fail. Many thanks in advance.
@ghost could just be due to changes in musl as it’s VERY actively developed. I believe my targets were both MIPS/MIPSEL and ARM. Great to hear it’s working without an ifdef/ifndef.
@superuser5 I can try to post something if I get time (actually, please look through my gists and you may find something- I seem to remember posting a guide to building openssl with a musl toolchain at some point
Or, if you just want to get started, clone https://github.com/richfelker/musl-cross-make
Use the example config.mak.dist, copy it to config.mak, modify it to your desired architecture, to save build time only enable C as a supported language, and use make -j && make install
That will get you a good cross-compile toolchain and sysroot. From there, you’ll need to build openssl using that toolchain.
The openssl build system is slightly unusual compared to most but you should be able to find documentation on cross-compiling. If not in my gists, google for “build openssl with musl” or something along those lines.
From there you just need to tell the revsh build where the installed cross-compiled openssl headers/libs are using -I
and by specifying the path to libssl.a and libcrypto.a on the command-line as opposed to using the library path flag
It’s not as complicated as it sounds but if you’re not experienced with cross-compiling (or the details of basic, native compilation) you’ll need at least an afternoon or two to get it right.
There are many difficult questions about static vs non-static due to the underlying crypto libraries that may or may not exist on the target host and conflicting versions. Also with the new OpenSSL 1.1 tree, revsh doesn't build at all. I'll keep this approach in mind as I go rewrite the crypto interface to handle other SSL/TLS libs (as a static OpenSSL 1.1 helloworld will segfault during initialization so, time to look into other libs.)
I haven't forgotten about this ticket though, I'm just short of time. I'll keep this ticket open until this all get rolled in, or decided against in the (hopefully near) future.
Cheers!
@emptymonkey I proposed switching to mbedtls a while back and I think we both agreed but neither had/has had the time to do it.
I’m not sure who is officially helping out with development on revsh now, but maybe someone would be interested in starting an mbedtls branch in earnest, which would probably end up easier since the API is stable across versions and it’s just simpler and more lightweight in general- and meant more to be used as something buikt in-tree, I think. It would also be great to drop all the unnecessary support for TLS < 1.2 as well as all of the unneeded cipher-suites. And all the other cruft openssl brings with it.
@superuser5 I found an old gist I put up @ https://gist.github.com/mzpqnxow/0974f4be1146256637aed20cfcb30da3
Not sure if this is helpful for you, but maybe you can use this to send in a PR?
@mzpqnxow thank you so much, i will test everything and will post update what works.
Hey, so the intended use is to drop /usr/local/bin/revsh onto a host after install, right?
Maybe there should be an extra build step to generate a full static build into a folder. I went into the makefile and set the static build cflags and everything worked fine, but it'd probably be beneficial to usability.
Thanks for the tool though, it's much more convenient than socat.