sites like this are neat until you remember that curl’s willingness to write ansi escape codes to stdout when it is a tty (as this site relies on to format the output when the user agent is curl) is actually a security vulnerability.
tldr: There are a variety of ways that attackers can cause you to execute execute arbitrary code when you echo their maliciously-crafted data to your terminal. Therefore, when you run curl without redirecting its output, or when you cat a file you’ve downloaded, you’re trusting the server (and also the network, when you don’t have https:// in the url) not to exploit you.
Of course the terminal emulators are ultimately to blame but when there are so many problems in so many of them, imo curl’s default behavior should be to filter its output when writing to a tty.
sites like this are neat until you remember that curl’s willingness to write ansi escape codes to stdout when it is a tty (as this site relies on to format the output when the user agent is curl) is actually a security vulnerability.
Could you give me an ELI5 please
This post The Terminal Escapes: Engineering unexpected execution from command line interfaces has a summary of the longer paper in the first link.
tldr: There are a variety of ways that attackers can cause you to execute execute arbitrary code when you echo their maliciously-crafted data to your terminal. Therefore, when you run
curlwithout redirecting its output, or when youcata file you’ve downloaded, you’re trusting the server (and also the network, when you don’t havehttps://in the url) not to exploit you.Ah ok that makes sense, thank you!
I’m more-inclined to blame a virtual terminal than the program writing the sequences if there’s an exploit there.
Of course the terminal emulators are ultimately to blame but when there are so many problems in so many of them, imo curl’s default behavior should be to filter its output when writing to a tty.
is there a curl argument that can be used to block this behavior?