[nkrisc]

The link won’t load for me, but I’m having a hard imagining how a remote server could change a file on your hard drive.

Is it about deceptive commands that look like they’ll do something different using weird characters to alter what commands run or something?

[Izmaki]

The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash. I don't remember the magic by heart, but the blog post conclusion was essentially that you can't / shouldn't blindly trust which scripts you pipe straight into bash from the internet, because even if it looks correct in a browser, the script you might end up running could be different.

It's more of a "this is possible" than "this is a real concern", of course.

[nkrisc]

> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash.

Maybe I’m not that clever but I can’t imagine at all how that would even be remotely possible. How would curl even know it’s being piped into something else? And if curl can’t know, how would the remote server know?

Send different response to browser vs curl, sure, that’s easy. But I’m saying download it to your local disk first, read it from there, then run your local copy, that you read. Don’t read it in the browser.

[Izmaki]

The Way Back Machine link works again, go read the blog post. :P

From the blog:

> Execution in bash is performed line by line and so the speed that bash can ingest data is limited by the speed of execution of the script. This means if we return a sleep at the start of our script the TCP send stream will pause while we wait for the sleep to execute. This pause can be detected and used to render different content streams.

> Unfortuneatly its not just a simple case of wrapping a socket.send("sleep 10") in a timer and waiting for a send call to block. The send and receive TCP streams in linux are buffered on a per socket basis, so we have to fill up these buffers before the call to send data will block. We know the buffer is full when the receiving client to replies to a packet with the Window Size flag set to 0 (Win=0 in wireshark).

[endofreach]

> The remote server is able to determine whether you are fetching the script using curl/browser or piped directly into bash

I think you must be mixing something up here. At least i would be very surprised to learn how pipes are that leaky over the wire. It would be very interesting. But i can't imagine how a remote would differentiate between curl and curl piped. And the article doesn't load unfortunately.

[Izmaki]

It has to do with how you can abuse how the TCP data is streamed, not that a web server detects a pipe.