4 ms·
“Concerned about theoretical man-in-the-middle attacks when piping scripts from curl to your shell?” This case is where you know what's at the URL you specifie
by kpreid 16y ago
“Concerned about theoretical man-in-the-middle attacks when piping scripts from curl to your shell?”
This case is where you know what's at the URL you specified, but since it was/will be downloaded over HTTP, in principle a MITM could change the content when it's downloaded by curl, so you're running a different script than the one you reviewed/uploaded.
- jcsalterego 16y agoYeah, but if you pipe the curl output to your shell anyway, this is the same thing. Unless of course it's some sort of "timing attack" (advance apology to purists if I'm using this term incorrectly) and the server knows you've downloaded this once (with gosh perhaps) and then sends you the malignant stuff the second or subsequent times. Edit: sorry, the above makes no sense because you will have reviewed it with gosh and probably wouldn't download it again.
- NateLawson 16y agoYou mean a "race condition", not timing attack. There are lots of ways you can get bad data from a given server over curl, even if using HTTPS and the attacker does not have full control over the server: * Typo in URL and typosquatter sends you whatever commands they want * XSS in server-side scripts leads to injection of commands via unescaped tags There may be others I haven't thought of. Perhaps a DNS glue record can be used to inject shell metacharacters where the server has an error handler that reports the client hostname? The fact that any of these are even possible shows how fragile this mechanism is.