File upload and download error

[kepler404]

Describe the bug Implant upload and download large files cause implant to crash

Steps to reproduce the behavior:

1. Sequence of events in attached picture

Expected behavior Upload and download suggestions Show progress bar

Screenshots

Desktop (please complete the following information):

• OS: debian
• Version v1.5.14

[moloch--]

The limit should be ~2Gb, will investigate.

[mrThe]

Can confirm, also there is huge cpu and memory usage on upload, and upload not even happening(i see zero traffic), and also OOM killer just kill the process, since im testing on small vm in docker.

Looks like a server issue, where it tries to read file right into the memory and do something with it (encrypt i guess).

---

And sure it did it: https://github.com/BishopFox/sliver/blob/master/client/command/filesystem/upload.go#L71

	fileBuf, err := ioutil.ReadFile(src)
	if err != nil {
		con.PrintErrorf("%s\n", err)
		return
	}
	uploadGzip := new(encoders.Gzip).Encode(fileBuf)

And next it tries to push the whole file to a single protobuf payload. I assume It is needed to be changed to chunks uploading method.

---

I don't know much about the protobuf itself, but my next assumption is to implement proper upload\download aside from existing one for now, and keep existing as a deprecated for some time so it not break anything.

---

As workaround it possible to use portfwd feature and upload\download files using ncat or something you like.

[moloch--]

Oh yea i added an outline for chunking in the protobuf but it for sure YOLO's the entire file currently.

[moloch--]

Max message a size in the Protobuf is 2Gb-1byte, so to support arbitrary sizes we need to switch to chunking anyways.

[moloch--]

I think there's also some situations in where the timeout doesn't get applied correctly for super long running commands due to some of the indirection on the server.

[cmprmsd]

I see [!] rpc error: code = Unknown desc = implant timeout on small file downloads, too e.g. 10MB nanodump files. Using https with nginx forwarding on a redirector server in order to see the proxied source IP. (This might cause some issues I guess).

Also my glorious_ring (:rofl:) fails on downloading even small files:

On the larger files, I see the implants host starting network transfer, so it's doing something but fails.

iirc this worked several versions ago.

[moloch--]

We'll see if we can reproduce, but double check that you don't have a max request size configured in your redirector.

[cmprmsd]

Here's the nginx-config. I guess it's the same that you recommend in the wiki.

Maybe it's the way I connected the redirector to my instance of Sliver. I currently use ssh -R 127.0.0.1:443:127.0.0.1:443

server {
        listen 443 ssl default_server;
        #isten [::]:443 ssl default_server;
        proxy_ssl_verify              off;
        ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_certificate     /etc/nginx/ssl/cert.pem;
        ssl_certificate_key /etc/nginx/ssl/privkey.pem;
                location / {
                proxy_pass https://127.0.0.1:4443/;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                #try_files $uri $uri/ =404;
        }
}

The connected sliver multiplayer client however is connected directly to the server.

Hope that helps :)

EDIT: Uploads do work. I tested it with a 5MB file, while any download fails. EDIT2: Also downloading directly on the server console fails.

[hayasec]

same problem

[realalexandergeorgiev]

changing max request size in nginx from 0 to 100m solved the issue for me