Menu
▾
▴
#77 winexe failure with any samba newer than v4.1
You can find a thread that discusses the problem here - http://forums.fedoraforum.org/showthread.php?p=1749571&posted=1#post1749571
After commenting on that thread, I completed field-hackery of the winexe source, and after stripping every reference to anything relating to libsamba-debug-samba4, winexe compiled & linked. Now I won't get any output as those DEBUG macros (and 'DEBUGLVL' in one place) are not included in the binary, but as long as the thing works I don't care much.
Now the question is - is 'winexe' dead? Is anyone reading this?
Thanks for all your work Michael and Mark. Here is the error I am getting on both CentOS 7 and Ubuntu Desktop 16.04. I look forward to the fix and/or the rewrite. Awesome tool.
[3334/3819] Compiling default/smb_static/smb_static.objlist.empty.c
Waf: Leaving directory `/root/u-mstowe-winexe/samba/bin'
Build failed: could not find 'smb_static/smb_static.objlist.empty.c' for
{task: cc smb_static.objlist.empty.c -> smb_static.objlist.empty_2.o}
Checking for library smb_static : not found
Build of static winexe : disabled
Hi,
The problem with centos 7 is the smb_static library just does not build.
I have got it to compile and build a shared library version on centos 7 using michael's version which rewrites the debug code as the debug library is now private on later versions of samba.
OK. I've found the smb2 calls in the samba4 source. They are the smb2_connect calls in source4/libcli/smb2/connect.c I'll code winexe to call them and see what happens.
I am having problems writing to the IPC$/ahexec named pipe that the winexesvc listens on.
my samba4 / SMB2 version opens IPC$ and writes to ahexec but nothing is coming through. I have put the service into debug mode and it just says the pipe gets opened but nothing comes through.
the original winexe code does 'raw' comms? What is that?
I'm also working this problem, and am encountering an issue in the same place.
Replacing smbcli_full_connection(), struct smbcli_tree, and related data structures with smb2_connect(), struct smb2_tree, etc is working correctly (after fixing the build issues). I replaced smbcli_open() and smb_composite_savefile() in svcinstall.c with smb2_create() and smb2_write(), and have the winexesvc service delivery and control working.
In async.c, working with the \ahexec pipe, there doesn't seem to be 1-to-1 replacements for the smb_raw_foo() calls. I'm attempting to use smb2_create_send(), smb2_create_recv(), smb2_read_send(), smb2_read_recv(), etc, using struct smb2_create, struct smb2_read, etc, and replaced the int fd in the struct async_context with a union smb_handle.
What I'm actually getting is an error from smb2_create_recv(). I'm not postive I'm using the correct values in the struct smb2_create when calling smb2_create_send(), although the call returns NT_STATUS_OK. smb2_create_recv() returns either NT_STATUS_ACCESS_DENIED, or NT_STATUS_OBJECT_NAME_NOT_FOUND, depending on how I fiddle with the struct smb2_create flags. What is further confusing is that I get the same behavior on the initial attempt to open the \ahexec pipe on the first call to async_open() (I'm removing the service after every run of winexe), as well as on a second attempt after installing the service.
Debugging in the service always shows ERROR_IO_PENDING following ConnectNamedPipe(), immediately followed by winexesvcCtrlHandler() receiving a SERVICE_CONTROL_STOP and an exit of the service.
Mark, perhaps we can sync up on this?
Hi Colvin,
Great to hear someone is also looking at this.
I've got it to work...just. but there seems to be an issue in the async_read_recv code, but it may be down to the smb2_create.
Most times I am getting an NT_STATUS_INVALID_PARAMETER returned in te read code.
It works 1 in 10 times and all works great, but it is just not reliable enough,
After spending weeks on this, I have just about given up, re-written the winexesvc_loop code to use temp files instead of pipes and getting winexe.c to open the files in the ADMIN$ share instead.
Any help would be great.
I have debugged the samba-4-4-4 code to try and find out where the INVALID_PARAMETER is coming from with no joy.
I have renamed async_open to async_create and here is it is.
Can we swap emails on this?
int async_create(struct async_context c, const char fn, int open_mode)
{
c->io_create = talloc_zero(c, struct smb2_create);
if (!c->io_create)
goto failed;
c->io_create->level = RAW_OPEN_SMB2;
c->io_create->in.create_flags = 0;
/ c->io_create->in.root_fid.fnum = 0; /
c->io_create->in.desired_access =
SEC_STD_READ_CONTROL |
SEC_FILE_WRITE_ATTRIBUTE |
SEC_FILE_WRITE_EA |
SEC_FILE_READ_DATA |
SEC_FILE_WRITE_DATA;
c->io_create->in.create_disposition = NTCREATEX_DISP_OPEN;
c->io_create->in.impersonation_level = SMB2_IMPERSONATION_IMPERSONATION;
c->io_create->in.create_options = NTCREATEX_OPTIONS_NON_DIRECTORY_FILE | NTCREATEX_OPTIONS_WRITE_THROUGH;
c->io_create->in.security_flags = 0;
c->io_create->in.fname = fn;
c->rreq = smb2_create_send(c->tree, c->io_create);
if (!c->rreq)
goto failed;
c->rreq->async.fn = async_create_recv;
c->rreq->async.private_data = c;
printf("async create main\n");
return 1;
failed:
printf("error in async create main\n");
DEBUG(1, ("ERROR: async_create\n"));
talloc_free(c);
return 0;
}
Hi Colvin,
I think you were getiing the NT_STATUS_OBJECT_NAME_NOT_FOUND message because SMB2 does not like the \ in the share names. SMB1 didnt seem to care.
I have posted a full fix.
Cheers,
Mark
Hi Colvin, hi Mark,
i was busy looking for some alternative for winexe - and found something - look here:
https://github.com/CoreSecurity/impacket/
This project contains a python script psexec.py which seems to work properly with smb2 (at least my tests succeeded). For me, this is not really an alternative to use productively because this psexec is way slower than winexe.
So, what i suggest is, you two might take a look at the python sources for some inspiration? Maybe here Colvins problem filling the appropriate structs could be solved?
I would be happy if it helped because i would really, really appreciate coming to a new working release of winexe...
Hi Dentar,
Thanks for sending that over. As mentioned above, I have got a new version of winexe working on SMB2, but having problems with the last little bit. It fails 9 out of 10 times. There is a timing issue somewhere and after 2 weeks, day and night I need some coding help. If I put -d99 in the winexe line to slightly slow it down, it works 50% of the time. it is reading from the named pipes from windows that is cauing the issue.
Colvin - Another I had to change in the main winexe code was to change loadparm_init_global from false to true so it correctly setup the max/min protocol values.
testing with smbclient4 passing the -m (MAX PROTOCOL) just does not work. You need max protocol setup for the smb2_connect code to work properly and it has to read it from the smb.conf file. That is just another issue I have a crap work-around for and will come back to it.
int main(int argc, char argv[])
{
NTSTATUS status;
struct smb2_tree smb2tree;
struct program_options options;
dcerpc_init(); ldprm_ctx = loadparm_init_global(true);Last edit: Mark Ridley 2017-06-29
Finally got it all working.
This is a SMB2 version only of winexe. It does not work with SMB1. The SMB3 code in samba is also a bit suspect as it works only about 10% of the time, but I am not fixing that yet.
Let me know how you get on. It is based on Michael's Samba 4.4.5 fork.
just type ./waf configure and ./waf build
git source
So I'm actually going down the road currently with the impacket python setup dentar mentioned above. Getting good results using winexec.py, as for my use case I only ever need a single command executed synchronously. My immediate plan to to roll over to that, but I do intend to check out the winexe work from Mark so I can report how it's working for me. I'd also like to compare Mark's work with my own. If winexe is working, then it's a matter of comparing the performance of the two solutions to see what I ultimately move forward with.
We have also been putting quite a bit of time into the impacket psexec script. The last two issues we have are 1) simultaneous calls to the same Windows machine occasionally (about 0.05% probability) fail, and 2) it fails 100% of the time with command lines longer than about 253 characters. The random failures occur much less frequency when all calls are single-threaded (about 0.002% probability).
Last edit: BorderlineADD 2017-06-13
Anyone got Marks git source compiling with samba 4.5.10?
I am trying on fedora25 but the compiler is complaining about missing header files like:
"libcli/raw/libcliraw.h: No such file or directory"
./waf configure went fine, though...
I'm pretty sure the other includes of winexe.c like:
libcli/raw/smb.h, libcli/smb2/smb2.h, libcli/smb2/smb2_calls.h and libcli/libcli.h
will fail as well..
Does samba4.5 still contain these files? Am i missing some important libs/devel packages?
thanks for any help
Managed to build on Fedora 25 with "LDFLAGS='-Wl,-rpath,/usr/lib/samba' ./waf configure" then "./waf build".
The only problem - now all error messages goes to stdout, not stderr.
Does anyone know if it's even possible to compile this version with a static samba4, for example under CentOS 6? From attempts I've made it appears that the various includes referencing #include "libcli/..." in the winexe code itself, as mentioned by dentar, simply may not work with the static build at all.
Before even getting that far, I had to revert samba to a6bda1f2bc85779feb9680bc74821da5ccd401c5 to get around issues described here:
https://sourceforge.net/p/winexe/bugs/64/
At that point I don't even think samba is even at 4.5. Is there any known way to do this? Thanks!
Like others I've done a lot of testing with the Impacket psexec.py. I've been able to modify that to allow a static service and executable name rather than the random name. I've also been able to allow it to leave the service installed and have it check for the already existing service etc. With the latter, simultaneous commands seem pretty reliable. However I've run into enough nasty bugs to make it unusable as it stands. Just like BorderlineADD I've found that it fails all the time with commands over 250-some characters. Really annoying. Testing with an echo command indicates that the command is in fact running, but psexec.py is getting a status 1 for some reason. Much worse however is that it's very unreliable at reporting the Windows error status, and occasionally drops stderr output from the Windows side. Things like running a non-existent command generate a status 1. However I've discovered that many things don't. For example "cmd /c dir c:\imnotthere" returns a zero status. I also found that failures running SQLCMD returned zero as well...all stuff that works with winexe. That's a show stopper for me. Not a pretty picture.
I'd at least like to have a clearer understanding of the winexe static compile in general. In order to compile previous versions under CentOS 6 I had to install samb4 packages (libs, devel etc). Those are apparently 4.2.x. I'm confused as to what uses all that as apposed to the samba4 checked out from git in the build directory.
Correction to the above regarding psexec.py (apologies for the OT): I discovered that it was simply exiting with ErrorCode but not the ReturnCode. That aside, it seems that some things that work with winexe behave very strangely with it. For example, running simple commands with SQLCMD seems to output literal backspace characters or even nothing at all. Still looking into the command length issues.
on ubuntu 16.04 LTS it compile fine with
git clone git://git.code.sf.net/u/mstowe/winexe u-mstowe-winexe
cd u-mstowe-winexe/source
apt-get -y install python2.7 gcc-mingw-w64 libtevent-dev samba-dev
ln -s /usr/lib/x86_64-linux-gnu/samba/libcli-ldap.so.0 /usr/lib/x86_64-linux-gnu/samba/libcli-ldap-samba4.so.0
ln -s /usr/lib/x86_64-linux-gnu/samba/libdcerpc-samba.so.0 /usr/lib/x86_64-linux-gnu/samba/libdcerpc-samba-samba4.so.0
ln -s /usr/lib/x86_64-linux-gnu/samba/liberrors.so.0 /usr/lib/x86_64-linux-gnu/samba/liberrors-samba4.so.0
ln -s /usr/lib/x86_64-linux-gnu/samba/libsamba-debug.so.0 /usr/lib/x86_64-linux-gnu/samba/libsamba-debug-samba4.so.0
ln -s /usr/lib/x86_64-linux-gnu/libsmbclient-raw.so.0 /usr/lib/x86_64-linux-gnu/libsmbclient-raw-samb.so.0
ln -s /usr/lib/x86_64-linux-gnu/samba/liberrors.so.0 /usr/lib/x86_64-linux-gnu/samba/libsamba-errors.so.0
./waf configure build && build/winexe --help
I've installed samba 4.5 from source under CentOS 6.8 and am attempting to compile Mike Ridley's version dynamically. I've installed under /usr/local/samba, and seem to be running into configure errors I can't resolve, especially on libraries that installed under /usr/local/samba/lib/private. One example is getting this in the log:
So even using this:
...with a proper sym link under /usr/local/samba/lib/private:
It's not finding that library. I'm at my wits end. Can anyone see what's wrong there?
In case anyone needs to build winexe with SMBv2 or SMBv1 check this out:
https://bitbucket.org/reevertcode/reevert-winexe-waf
I created a few patch sets based off Mark Ridley's work to compile with Samba 4.3.13.
Last edit: Alan Baghumian 2018-03-26
Others may want to note that the current git version of this has logging to C:\winexesvc.log enabled. I disabled it with this:
Is anyone able to compile Mark Ridley's version, or does anyone have a precompiled binary that works with SMB2? (Mark?? 😊)
I was able to compile Alan Baghumian's source, but the winexe binary I got from that did not work with SMB2, only SMB1. For Mark Ridley's source, I get errors about missing header files as reported by dentar. I tried manually grabbing all the headers, but ended up with recursive dependencies.
I really need a winexe that works with SMB2 (don't care if it works with SMB1; that has been disabled for security compliance).
Last edit: Jay Jech 2018-05-16
Jay, did you apply the SMB v2.0 patches? I am actually using this with SMB 2.0. See the BUILD file:
https://bitbucket.org/reevertcode/reevert-winexe-waf/src/a7647b5e28d6260e964e479424cc22ebf772bf31/BUILD?at=master&fileviewer=file-view-default
Wow. I hadn't noticed that file until you pointed it out. Following your instructions in the BUILD file, it compiled on the first attempt and the resulting binary is working with SMBv2.0. Thank you, Alan!!