This is helpful to know, but also pretty general security practice. If you are auditing an artifact, only use that audited artifact after, don't assume that a network endpoint can never change what it serves. If you must use a newly downloaded artifact, verify it matches whatever you audited by comparing some sort of hash or derived value.
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.
> 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.
> 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.
This is helpful to know, but also pretty general security practice. If you are auditing an artifact, only use that audited artifact after, don't assume that a network endpoint can never change what it serves. If you must use a newly downloaded artifact, verify it matches whatever you audited by comparing some sort of hash or derived value.
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?
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.
> 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.
1 reply →
> 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.
1 reply →