Slashdot Mirror
Getting Hacked Through Your Terminal
hdm writes "My company recently published a paper on security issues with common terminal emulator applications. The interesting thing about these vulnerabiltiies is that many of them only require the victim to be running tail on their log files (apache, syslog, etc) for the attack to be successful. The paper (TXT) can be found here."
just pipe your stuff through strings. it should help a bit
Given the profliferation of exploits related to race conditions, predictible file creation, etc,
;-)
we should henceforth re-tool our code to only make use of stateless protocols!
The difference between stupidity and genius is that genius has its limits.
~~~
I always pre-filter my logs thru a Perl script. Besides removing verbose messages that are not useful, my filters replace such non-printable characters with a printable character. Not only does it make it easier to spot strange octets on the screen, it does not depend on the terminal emulator remaining secure.
chongo (was here)
So they discovered ANSI bombs over again.
Simple! Just tell Linux not to load ANSI.SYS, problem solved!
Another day, another vulnerability. These exploits are getting more bizzare and more useless every day. The risk factor here is ridiculously low.
I don't want to here about anymore useless exploits or no risk vulnerabilities. If you really want my window title, I'll telll you what it is; Getting Hacked Through Your Terminal - Konqueror
Now, when someone gets an exploit to replace the Slashdot ads with Goatse, then I'll be impressed.
However, certan software would allow an attacker to insert these control codes anywhere, and not just interpret them from the menus.
Imagine the hilarity that insues once the attacker figures out the embed sequence for the drop to DOS feature.
The more you know, the less you understand.
Someone has to be using a terminal for someone to be able to do this to them. Is it just me, or is the solution really obvious? Just chmod every thing with a command line to 000! That should keep those naughty, naughty crackers out!
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
The idea is probably to give a scenario so those weak on imagination have something to use to show their boss to explain why they should spend time on this issue.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Apparently the OSX terminal might be susceptible to this. It is possible to alias different escape sequences to commands like lm and ll to make the terminal full screen, send it to the background, make it tall, etc.
/var/log/messages, but I won't be the one to find out as my PowerBook is in the shop...
It would be interesting to see whether actual commands can be executed if tailing
Back in the day, "Ansi Bombs" were considered an art form. With the art scene so active, you could usually embed some evil escape string in a good looking graphic and know that you were going to get people.
The problem was DOS' overly-powerful ANSI.SYS interpreter. It let you remap any key to an arbitrary set of keys, making keyboard macros pretty easy. However, it also let evildoers remap "Space" to, for example, "del *.*, enter, y, enter." Luckily, there were third party ANSI interpreters that didn't suffer this vulnerability.
One time, when I was about to reformat my HD, I even wrote an ANSI bomb to do it. Crazy stuff. There's an interesting (and of course, old) paper about it here.
It all goes downhill from first post
I dare to say that putty IS vulnerable. This is what happens when I run a similiar command. Sure, it still expects an enter and anyone who takes his time to read stuff on his/her screen before blatantly hitting enter will notice the command. This was done with the latest build which I just downloaded from the site.
Hate me!
If you had read the article, rather than just glancing through it... those were the terminal emulators he used.
Eterm was affected, Putty, Xterm, and Rxvt.
Black and grey are both shades of white.
So they discovered ANSI bombs over again.
Looks like it.
I recall the "ANSI Standard Trojan Horse" (though it was misnamed). It became quite common after ANSI standardized a cross between the VT100 and Ann Arbor Terminals escape sequences.
Simplest form was to send a "talk" mesage to a root user containing an escape sequence that programmed a hotkey with your command-to-be-run-as-root and then "hit the key" by remote control. (You could even bury it invisibly in an otherwise innocuous-looking message.)
ANCIENT stuff. What-early '70s?
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
In my neck of the woods TXT is practically synonymous with text messaging. No, actually it's, synonymous with the delivery of TXT msg svrl hrs aftr u snt thm...
# init 5
Connection closed.
Oh...
The author went on to have an interesting converstaion with Micahel Jennings, author of Eterm on Bugtraq here.
ex$$
The following terminal emulators were found, according to the article, to NOT be susceptible to screen dump or window title attacks:
Some asked about my Perl filter for tailing log files.
Sans typos, here is an example that removes certain types of messages and fields, checks the file every 60 seconds, picks up trailing on the new file when the log file gets rotated (moved away), trims to 224 characters and replaces unusual chars with ~'s (assuming you use ASCII).
As they say in perl, there is more than one way to do it. The above code fragment is just to give you the general idea.
chongo (was here)
The paper mentions injecting escape sequences into log files which are being tail -f'ed... and that there's nothing new about terminal exploits.
/var/log/apache/common.log' would limit less to 1024K (1M) of buffer, which means old data will eventually be discarded, but keeps less from malloc'ing all your core. As always, Read The Fine Manual for details :)
When I first heard about this (a couple of years back) I started using less +F for tailing logs. less will convert the escape character into the token ESC (in bold or inverse video), avoiding any escape-sequence exploits.. and also adds the benefits of being able to scroll back and search, which would make it worth using even if there were no such thing as a terminal exploit.
If you're going to leave it running for a long time, you might want to also look into the -b and -B options, to limit the amount of buffer space it will allocate: something like `less -b1024 -B +F
I just checked: the `more' command on my Linux and Solaris boxen seems to pass escape sequences through, so you really do want `less' (or alias less=more, if you're used to typing `some_command|more'), not to mention `more' has no equivalent to `less +F' or `tail -f'.
Hope this helps someone...
One point that stood out at me is how many apps are vulnerable because they started with an insecure codebase. This is how exploits become common - one buggy piece of code spreads to a dozen others and never gets fixed in any of them, if only because authors say "let's add our new features instead of validating these 25,000 lines of code we started with."
What if life is just a side effect of some other process and God has no idea we exist?
For instance, you can recover a root password in just 10-15 minutes on ANY machine.
You shouldn't make such claims without any evidence.
Do you care about the security of your wireless mouse?
By trimming down to 224 characters, I avoid line wrap. System crackers cannot cause a very long line to wrap at just the right place to fake another entry.
Sure, I'll perhaps miss important text beyond the 225th char, but I'm willing to take that risk. Besides, the script converts tabs to a single space and removes some common fields and phrases which further cut down down on long lines. And I can always to back to the logs to look at really long lines if I want to.
And yes, maybe some terminal emulator has some long line bug somewhere. My perl script helps avoid testing it. :-)
chongo (was here)
Some years ago I managed to make an xterm dump core simply by typing the contents of a binary file, which did not contain any malicious data, it just be coincidence contained a byte sequence that would cause xterm to dump core. Investigating this I found, that some sequence of 24 bytes was responsible. But if I made the xterm window larger, it would not crash from this sequence, however it turned out the original file contained another longer sequence that could also make a larger xterm dump core. I never actually understood exactly what was going on, but I found that later xterm versions does not crash from the sequences I saved from back then.
Do you care about the security of your wireless mouse?
will take care of the tail of a log file problem...
They're obvious exaggerations for the intent of being humorous. No one should take them seriously or interpret them as anything other than playful jabs.
Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
A long long time ago, on a uucp-net far, far, away, we didn't use terminal emulators, we used real hardware terminals. Most of them didn't run ANSI (I don't remember if the ANSI terminal standards were defined yet, but they looked very much like a DEC VT-100 terminal), but that meant there were lots of types of terminals, all trying to achieve market differentiation by having cool features or small size or large screens or cool plastic cases. Lots of different cool features means lots of vulnerabilities. The hackers in question had REDISCOVERED AN OLD TECHNIQUE - they found ways to hand escape sequences to VT100 terminals that would get the terminal to send arbitrary text back to the computer, which in those good old command-line days meant they could do anything they wanted. All you needed to do was email somebody a message with carefully crafted character strings in it, or use the talk program to write them to their terminal (back when everybody left their ttys writeable so talk would work.) Some of the popular techniques were to abuse programmable function keys (send a sequence to put some string in F1, then another sequence to auto-trigger the F1 key), or automatic whoami-responders (VT100 had one of these), or put the terminal into loopback testing mode (letting you type anything you want.)
The Hewlett-Packard HP2621 and its relatives had two easy things to do, which didn't let you send arbitrary characters but still hosed the user - one did a reboot on the terminal (and thereby dropped the connection), while the other put it into test pattern mode (sending a long string of UUUUUU to the computer.) There may have also been some block-mode things that let you send arbitrary characters to the computer, but these two were the easiest and best-documented. A couple years later, when I was a newbie learning Unix programming and security at Bell Labs, and Robert Morris Senior (father of RTM the Worm Author) was a department head for computer security (before he went to NSA), we'd had a discussion about some techniques I was trying (which he cracked through personally :-), and a few days later, when I'd patched those holes, I was playing rogue in the evening, and one of his people talked the test pattern sequence at me. For a few seconds, I though Umber Hulks were suddenly going to eat my character, but then realized I'd been hacked, and it was one of RTM's people following up on what I'd patched and what I hadn't...
Terminology note on "hacker" as opposed to "cracker" or "vandal" - The folks at Berkeley really were hacking - tinkering with things to find their limits - and while they could potentially use their knowledge for evil, they instead told people about it, which reminded lots of us to check for potential security holes in our systems.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Larry Wall's famous quote says Great Hacker virtues include Laziness, Impatience, and Hubris.
I would agree, and say that a Great Hacker would locate those killer ctrl codes, get a boatload of diagnostic information together, and hand all that over to the maintainer of the terminal program and then not sweat trying to figure it out themselves.
Let someone that knows the code, and might be better able to divine what's up have a wonk at it. You could even check the diffs if it ever gets patched, and you were curious and had time to kill.
Then, the Great Hacker would go and patch their own project to fix up the newest incoming bug report.
Then, the Great Hacker would rest and eat of the Divine Pizza.
And all would profit.
Keep your packets off my GNU/Girlfriend!
You do have "mesg n" set, do you?
If not, you are attachable by "write " as well.
And yes, this is very, very old. Many an administrators open terminals have been taken remotely using this when I was at university.
Kristian
Some programs or setups spit stuff out to the console - warnings, error messages etc.
I remember doing something similar when testing my company's TIS FWTK setup years ago. When you used an address with unbalanced brackets, sendmail when called by smapd will grumble to the console. As a test I sent an email with a ESC sequence setting the foreground colour to black and it worked. Wasn't too surprised. Wasn't able to find an exploit for the console term at that time, and no one abused it (security through obscurity).
Later I switched to using qmail (IIRC qmail 1.0.3 dates to 1998, the TIS FWTK has been around for quite some time). Just to test things out I also recently wrote an smtp proxy to enforce state and filter out stuff(qmail may be robust, but it tends to pass the junk unfiltered to other stuff which may be less robust).
Some O/Ses send a many kinds of messages to the console too.
But the later option was too risky for my taste, because the "login" process was owned by you. So instead, I wrote a doomsday shell script. It gave you a # prompt to make you believe you are running as root. It then emulated various UNIX commands. For example "jobs" showed [1] rm -rf / & and "kill" returned "Permission denied". It logged all the commands and responses to an obscure file in my home directory. Once I got our semi-knowlegable system administrator's assistant to "interact" with this script and it was quite fun reading him using kill 10 times in a row with the same arguments. She really thought the filesystem was going south.
Terrible abuse that can be inflicted on X terminals or public lab PCs with terminal emulators is left to the imagination of the reader.
There are lots of things you can easilly do with physical access to the computer, but finding the root password is not one of them. Unless something has been done to prevent it, I can bypass the root password in less than five minutes. Either pass an init argument to the kernel or boot from external media. Once the root password has been bypassed it can easilly be changed if I would want to.
Preventing boot from external media and boot arguments will slow down the process, and of course BIOS and bootloader must be password protected. But I can get a long way with a screwdriver unless the harddisk has been encrypted.
In case you want to prove your claim, please tell me what my root password is. Here is the line from my
Do you care about the security of your wireless mouse?
This is a nice touch, but remember that it's only security by obscurity. If you have physical access to the machine, you can just as well boot from a floppy, or remove the harddisk and put it into some other computer booting from another disk.
Not that it isn't useful, though. Most sysadmins do give their users physical access to their desktop (or laptop) computers. But then the users are, at least to some degree, trusted...