For GNU less, you can use the -R option, which is like -r except that it only lets color escapes through, and not all escape sequences. So if you want to alias less to less -R that is much safer.
However, I honestly don't see why I should do something foolish as `curl | sh`, even though from time to time I see websites suggesting this crazy approach. The first thing I think of is "why should I give you control on my shell?".
…I guess, however, this is kind of a natural behavior for the user who doesn't know the shell-fu. I've seen a similar article once about Ubuntu Forums. Unfortunately I can't recall the URL.
Another cool thing, besides icebergs, would be a service checking for escapes given the URL. Or for other caveats (e.g. is the url https? Is it editing weird files (follows list of files))
The ANSI driver that came with MS-DOS, ANSI.SYS, also allowed keys to be rebound to small macros.
So you could TYPE (cat) a file and then later press a harmless key like D and ANSI.SYS could output something like whatever the DOS equivalent of "rm -fr /" was (probably DELTREE /Y C:\) as though it had come from your very keyboard.
This was very common in the BBS era. Anti-virus software would usually detect those sequences. People who wanted to look at ANSI art but were aware of this would use alternative ANSI implementations like the one from PC Magazine, which I am a bit surprised to find out can still be downloaded from their website, which also still exists: http://www.pcmag.com/article2/0,2817,5343,00.asp
...But I supposed we'd be distracting attention away from the point... ;)
Anyway, does anyone know of any escape sequences or similar content which would cause GNU or OSX to perform and action? Or, of any buffer-overflow-type scenarios for the escape sequence handlers? (Surely most graphical terminals rely on some well-known library...)
You can even put ANSI escape sequences in file names, since there is no notion of an encoding for file names in POSIX. They're just strings of any byte except / and NUL. Fortunately GNU ls won't print most escape sequences verbatim to stdout, but other implementations and/or programs might, and I have had some success creating a file name that GNU ls always prints in a fixed color (this was a while ago, don't have it on hand).
Though as that link mentions, using the terminal's bracketed-paste feature can avoid that. It talks about oh-my-zsh but support for that is built-in to zsh since 5.1. It still isn't perfect, as the pasted text might contain fake end sequences or your terminal interrupt character.
> Hint:
> 'less' doesn't interpret escape sequences unless the -r switch is used,
> so stop aliasing it to 'less -r' just because there's no colored output.
Instead you can just use `less -R` which allows colored output but doesn't interpret any other escape sequences.
> You might be thinking "If I opened that in my browser, I would detect
it being malicious!"
Well, think again...
One can have all sorts of fun with user-agents, something that can
easily come to mind is verifying if the user-agent is from curl or wget,
and make them download the malicious file, if not,
redirect them to a legitimate file that looks like the original
output. Your browser would fool you then.
I can't decide whether this is evil, genius or disturbing. I don't typically copy paste curl commands, but it never occurred to me that even if you check the URL curl is pointing to with your browser that's no guarantee that the same script will be downloaded and parsed in the server.
Or you can just do it yourself if you don't trust the source (And if you don't, you should really ask yourself why you're engaging in this exercise at all anyway): download the file, review in vim (which will display esc sequences), and then execute that file with sh yourself.
col -bx strips nonprintable characters. I have been using this for many years. Especially since the spread of Unicode.
As for _viewing_ nonprintable characters, I am a heavy sed user and honestly I rarely use the l command except occassionally to view newlines, tabs and carriage returns. I prefer od or xxd.
ATM0 would just silence the speaker. What you want is:
+++ATH0
Wouldn't work on properly implemented modems, as the standard required a quarter (or possibly half) a second pause between the +++ escape, and the hayes command.
Now, you sending this to IRC wouldn't do much at all. What you would want to do was rather take a look at their IP address, and use the "ping -p" command, as that allows you to specify up to 16 bytes padding that will be echoed back. You would then encode +++ATH0 as the pattern, which would be sent back from them to you .. and if it was a silly modem, it would hang up.
32 comments
[ 3.2 ms ] story [ 79.1 ms ] thread"'less' doesn't interpret escape sequences unless the -r switch is used, so stop aliasing it to 'less -r' just because there's no colored output."
However, I honestly don't see why I should do something foolish as `curl | sh`, even though from time to time I see websites suggesting this crazy approach. The first thing I think of is "why should I give you control on my shell?".
…I guess, however, this is kind of a natural behavior for the user who doesn't know the shell-fu. I've seen a similar article once about Ubuntu Forums. Unfortunately I can't recall the URL.
Another cool thing, besides icebergs, would be a service checking for escapes given the URL. Or for other caveats (e.g. is the url https? Is it editing weird files (follows list of files))
So you could TYPE (cat) a file and then later press a harmless key like D and ANSI.SYS could output something like whatever the DOS equivalent of "rm -fr /" was (probably DELTREE /Y C:\) as though it had come from your very keyboard.
This was very common in the BBS era. Anti-virus software would usually detect those sequences. People who wanted to look at ANSI art but were aware of this would use alternative ANSI implementations like the one from PC Magazine, which I am a bit surprised to find out can still be downloaded from their website, which also still exists: http://www.pcmag.com/article2/0,2817,5343,00.asp
Anyway, does anyone know of any escape sequences or similar content which would cause GNU or OSX to perform and action? Or, of any buffer-overflow-type scenarios for the escape sequence handlers? (Surely most graphical terminals rely on some well-known library...)
> Hint: > 'less' doesn't interpret escape sequences unless the -r switch is used, > so stop aliasing it to 'less -r' just because there's no colored output.
Instead you can just use `less -R` which allows colored output but doesn't interpret any other escape sequences.
I can't decide whether this is evil, genius or disturbing. I don't typically copy paste curl commands, but it never occurred to me that even if you check the URL curl is pointing to with your browser that's no guarantee that the same script will be downloaded and parsed in the server.
The kind of vulnerabilities that are basically just subverting a user's trust are totally fascinating to me.
col -bx strips nonprintable characters. I have been using this for many years. Especially since the spread of Unicode. As for _viewing_ nonprintable characters, I am a heavy sed user and honestly I rarely use the l command except occassionally to view newlines, tabs and carriage returns. I prefer od or xxd.
NO CARRIER
or:
ATM0
... and watching 10-20-30 people suddenly disappear from the channel as their DOS based comm program passed them as commands directly to the modem.
ATM0 would just silence the speaker. What you want is:
+++ATH0
Wouldn't work on properly implemented modems, as the standard required a quarter (or possibly half) a second pause between the +++ escape, and the hayes command.
Now, you sending this to IRC wouldn't do much at all. What you would want to do was rather take a look at their IP address, and use the "ping -p" command, as that allows you to specify up to 16 bytes padding that will be echoed back. You would then encode +++ATH0 as the pattern, which would be sent back from them to you .. and if it was a silly modem, it would hang up.