Getting Hacked Through Your Terminal 204
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 (Score:1, Interesting)
For instance, you can recover a root password in just 10-15 minutes on ANY machine.
Re:Most exploits (Score:2, Insightful)
~~~
Re:Most exploits (Score:4, Insightful)
You shouldn't make such claims without any evidence.
Re:Most exploits (Score:2)
Re:Most exploits (Score:3, Interesting)
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
Re:Most exploits (Score:2)
That being said, there Are tools that take an
I will tell you why that password can be broken. The key used to crypt the password is itself. There is a limit to the types of characters, and the number that can be used in a unix password. a bruteforce decryptor can be built that will try every possible combination, starting with the most likely root passwords, and essentially it's just a matter of waiting for the program to find the only string that decrypts the encrypted string to itself.
I don't have the patience nor the desire to run your shadow entry through a brute force decryptor... but the reason the shadow file exists is because on shell machines there are people with the patience and the desire to run those shadow entries through a brute force decryptor. Even if it takes them a week to get the password because the system had a relatively secure password.
Re:Most exploits (Score:2)
Re:Most exploits (Score:2)
You are wrong. The kernel uses a 4096bit seed, and it combines random input from different sources including the timing of keyboard and mouse input. And the seed is saved at system shutdown and restored during boot. In total this means you need to know the exact keypresses and mouse movements I made in the two years passing from when I installed the system and until I generated the password. My password is truly random.
Re:Most exploits (Score:3, Insightful)
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...
Re:Most exploits (Score:4, Informative)
You fail on step 1 (Score:2)
What if the computer is like my own, where I have a BIOS password *and* a padlock locking the case?
Re:You fail on step 1 (Score:2)
Re:Most exploits (Score:2)
Why make it so complicated? I'd just have typed: mount -o remount,rw
Re:Most exploits (Score:2)
strings (Score:3, Informative)
Re:strings (Score:1)
Re:strings (Score:1)
A simple solution (Score:4, Funny)
we should henceforth re-tool our code to only make use of stateless protocols!
Re:A simple solution (Score:1, Funny)
No-one was ever attacked through port 80.
Re:A simple solution (Score:1, Offtopic)
About as sharp as a bag of potatoes, this one.
Re:A simple solution (Score:2)
In a true stateless protocol people need to send a request that ammounts to "send me
Many bugs are in the user-identification and verification routines. Web sites let you do, if you've got the right cookie, nasty things that they shouldn't let you do. Not only does your initial verification need to be secure, but your storing of cookie data in such a way as to let the user back on, with access, needs to be fairly secure. Providing state introduces many bugs you otherwise wouldn't have.
Now, this isn't to say that everything should be stateless, but that you should think about how much time you save by letting people not enter their password at every use, versus the potential risks. Especially if you're coding the security sections yourself. Trusting
Not all terminal emulators were susceptible (Score:2, Informative)
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.
Re:Not all terminal emulators were susceptible (Score:1)
Re:Not all terminal emulators were susceptible (Score:1)
PuTTy (Score:5, Informative)
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.
Re:Not all terminal emulators were susceptible (Score:1)
Re:Not all terminal emulators were susceptible (Score:1)
You should also read about *why* Mr. Moore gave Eterm the "most vulnerable" award. The only reason he gave which hasn't been fixed for almost 2 years now was the quality and thoroughness of my documentation.
Re:Not all terminal emulators were susceptible (Score:1)
Re:Not all terminal emulators were susceptible (Score:1)
CORRECTION to terminal emulators not susceptible (Score:5, Informative)
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.
Re: why 224 character trim? (Score:3, Informative)
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. :-)
Re:CORRECTION to terminal emulators not susceptibl (Score:2)
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.
Re:Not all terminal emulators were susceptible (Score:2)
Re:Not all terminal emulators were susceptible (Score:1)
Re:Not all terminal emulators were susceptible (Score:3, Informative)
The article did mention that Putty was not really susceptible to screen dump attacks, because
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.
This doesn't mean putty is "secure", but it's not as insecure as some others. The baddies seem to be eterm and rxvt. There's a nice description of a compromise scenario via eterm at the bottom of the article.
Re:Not all terminal emulators were susceptible (Score:3, Informative)
Please note that the "case study" provided was contrived at best and damagingly inaccurate at worst. No official release of Eterm EVER could be used in the way they describe. Only people following CVS Eterm would ever have been open to such an attack, and those people would have updated to a fixed version almost 2 years ago.
The case study is intended to illustrate a "Worst Case Scenario" type situation, not be any sort of realistic portrayal of actual events.
Re:Not all terminal emulators were susceptible (Score:2)
Re:Not all terminal emulators were susceptible (Score:2)
Putty is very cool, but I wish it's scrollback features were more -- robust.
"Fictitious Case Study" (Score:1)
"Fictitious Case Study"?
Reading that drivel about Andre and his l33t hax0r buddies totally removed the credibility the rest of the article had achieved!
Re:"Fictitious Case Study" (Score:3, Interesting)
Re:"Fictitious Case Study" (Score:2)
I definitely thought it was a good addition to the report, though.
dave
Reinventing (Score:5, Funny)
Simple! Just tell Linux not to load ANSI.SYS, problem solved!
Also known as the "ANSI standard trojan horse." (Score:5, Interesting)
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?
Re:Reinventing (Score:3, Funny)
Worked quite often...
Re:Reinventing (Score:2)
One thing they forgot about was the enter key mapping which can be loads of fun as well as the function key mapping. Most of the v100ish things will allow you to reprogram the enter key to any 4 character sequence (4 nulls is fun) but many of the people who copied the spec, didn't bother with the 4 character limit.
The more things change... 1979 version (Score:5, Interesting)
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.
Talk is cheap. (Score:2, Funny)
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.
Re:Talk is cheap. (Score:2)
You got it all wrong. Nobody wants to know what your window title is. However somebody wants to decide what your window title is going to become, and later they are going to have your shell execute that as if it were a command.
Re:Talk is cheap. (Score:1)
If you had read the article the author gave quite a convincing hack sequence.
Re:Talk is cheap. (Score:1)
Re:Talk is cheap. (Score:1)
Aha, he's running Konqueror, hence kde *searches for kde-exploits on scriptkiddieheaven.com*
Mohahaha *rubbing his hands with a evil grin on his lips*
Re: Can't read, can you? (Score:3)
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."
Fuzzy memory (Score:4, Interesting)
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.
Re:Fuzzy memory (Score:3, Informative)
No BBS program I ever used (most of my experience is with TriBBS and RemoteAccess, but I also dabbled with Renegade and various Renegade-alikes) would parse the dynamic-content codes outside of files that would actually be displayed by the BBS. My memory's a bit fuzzy as well, so there might have been a few exceptions that I don't explicitly recall, such as allowing users with high enough access levels (e.g., sysops) to use them in messages, or allowing them in certain message bases, but under normal circumstances no one but the sysop would be allowed to use them and even then only in very limited circumstances.
Similarly, no BBS program I ever used had a "drop to DOS" sequence that could be embedded in a display file. Of course there was a menu command that would do it, but a) menus and the ANSI files displayed when users accessed them were always separate and b) the drop to DOS command would have to be explicitly defined in whatever menu for anyone to actually use it, and only insane sysops would allow a regular user access to it.
Re:Fuzzy memory (Score:3, Informative)
And yes, it would be incredibly poor programming practice to have a code path that would allow a user to exploit this. But, consider that many boards had some kind of dynamic headers which would display on top of the regular menus or message boards.
So it could have been possible such that a user could embed a sequence in a forum message and then upon display the stupid software loads the header from disk, appends the part it has to display and then parses it for command sequences and finally displays it.
Perhaps I'm only remembering somone claiming this was possible, I never tried to exploit any BBS, I was on the other side trying to keep myself up to date so these things couldn't happen to me. Either way, it was a blast being a Sysop and its good to see I'm not the only one on Slashdot that got a start there :)
This isn't a big problem. (Score:3, Funny)
Mac OSX (Score:2, Interesting)
It would be interesting to see whether actual commands can be executed if tailing
Re:Mac OSX (Score:3, Interesting)
Re:Mac OSX (Score:1)
Re:Mac OSX (Score:4, Funny)
The bad news: Evil black hat hackers can use remote exploits to move the OSX terminal around the screen.
The good news: With the velvet smooth animated motion, harmonizing colors, translucent effects and drop shadows, being 0wned has never looked better!
BBS ANSI Bombs (Score:5, Interesting)
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. [textfiles.com]
Re:BBS ANSI Bombs (Score:2, Informative)
NO CARRIER+++ was displayed beginning in position 0 (left to right) the modem connection dropped. I made the mistake of sharing this newfound knowledge with my friends who proceeded to disconnect me at every possible opportunity. Of course, today I could have them arrested under the anti-terrorism laws for their purposeful denial of service attack. Hmmm...is the law retroactive??
Re:BBS ANSI Bombs (Score:1)
Uhm, no... (Score:3, Informative)
Eterm was affected, Putty, Xterm, and Rxvt.
This isn't that much of a problem. (Score:1)
Dear Sir, (Score:1)
Thank you,
Anonymous Coward
Thread (Score:5, Informative)
Re:Thread (Score:3, Interesting)
Michael Jenning's comments that he's not an expert on security, but does try his best show a real sense of humour and concern for his users.
Ok, so I'm being a bit of a fanboy, but most links to discussions between open-source developers I see these days are the fights they have (on the very public mailing lists where we can see them). We tend to forget the good work they do the rest of the time.
(raises hat, or would if I was wearing one)
Re:Thread (Score:2, Interesting)
I started out my life on Unix as a sysadmin, and I always found it distasteful how software developers would get all pissed off at the people who reported the vulnerabilities, as if they were somehow to blame for the author's own screw-ups.
The bottom line is simply that the person who wrote the code is responsible for their own mistakes. That's really where the buck stops.
In the end, all that really matters is that things get fixed as quickly and correctly as possible for the sake of the users. Ego-sparring and public feuds accomplish nothing and are ultimately counterproductive.
Tailing logs... (Score:5, Informative)
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...
Re:Tailing logs... (Score:1)
Thanks.
--RJ
Re:Tailing logs... (Score:4, Informative)
Actually that should be:
alias more=less
But otherwise, very helpful. I'd always been in the habit of using 'tail -f', even as root -- and personally I'll be using 'less +F' from now on.
Unstable xterm (Score:3, Interesting)
Re:Unstable xterm (Score:5, Interesting)
This, in a nutshell, is why you'll never be a Great Hacker. I'm most likely projecting my own insecurities upon you, but I'm writing and you're not, so there.
I tend to notice little things like you noticed - that catting a binary file will crash my terminal. And then in a fit of boredom, I might even do as you've done and start trimming away sections of the file to find the offending string. I might even write a one-liner that will parse through it for me, automating what would otherwise be a tedious task. I'll eventually end up with a file that is 23 bytes long, and when catted, crashes the terminal.
But I won't ever find out why. That file will remain a curiosity in my $HOME/misc/, to be pondered at until I find that it no longer crashes whatever terminal program I'm using. It might even remain for a while, until one day I have a directory purging session and delete it, wondering "What the hell is this?".
And that, in my opinion, is what separates Great Hackers from the myriad of wannabes. I'm definitely a wannabe. I'm proficient at everything I do, but I'll never spend the (quite possibly small number of) hours actually finding out why that string crashes xterm, and maybe doing something useful with it. The rewards are definitely there, and I've tasted their sweetness in flashes of inspiration, but I just don't have it.
What is it? I don't know. I don't suspect that I ever will, in this particular field. I think that I might just have it in another field (racing cars), but I think it's likely that I'll be Just Proficient at that, too, much as I have been at most everything for my whole life. And that's a pretty depressing thought.
Great Hackers have it, I think. They must. In fact, part of me wants to disbelieve that it exists; that if I'd just push myself a little bit harder, that if I'd just concentrate a little more, that if I would simultaneously dig deeper into and maintain a broader view/mindset of whatever it is that I'm doing, that suddenly I'd become a Great Hacker. I'd know the formula of self-motivation, and from then on it'd be easy. But it just doesn't seem to work that way - I read the exploits of Great Hackers, and marvel at how they do their work, just knowing that I could never do that! Knowing that given the same set of curiosities, my interest or drive or whatever would sputter out, and at best I'd end up with something nifty, that I might be able to make use of in my next bout of Adequate Hacking.
I'm sitting here thinking that I want to type some sort of sage-like advice to you (whoever you are) about forcing yourself to go the extra mile, or don't be lazy, or to eat your Wheaties before you start hacking. Fact is, I know that I've missed the opportunity to grab it. I also know that I've no clue what I did "wrong", and wouldn't know what to do differently, even could I go back in time and change something. I wish that I could have it, but I know that I never will.
I'm still pretty young (19)... maybe I'll figure out how to grab it between here and there.
Re:Unstable xterm (Score:2, Insightful)
>wannabes. I'm definitely a wannabe.
No, sir. YOu are not a wannabe. Go check out usenet:alt.hacking.* and look for
"Hotmail Hax0rz", "Warez", "Mail haxorz", "DOS", and other usual keywords
associated to 'have-no-clue-but-must-impress-my-friends' wanabees. If you have a
clue, you're already out of that category.
>I'm proficient at everything I do, but I'll never spend the (quite possibly small
>number of) hours actually finding out why that string crashes xterm, and maybe
>doing something useful with it. The rewards are definitely there,
The big key there is "why". That's what gives master hackers their edge. The
thirst of knowledge hanging just above their head, waiting to be plucked. But
how do you pluck it? Do you just rush to it, squishing it in your hands, licking
the residue from your palm? No.. you cherish and understand it. But you don't
give up. If that means asking for help from somebody more learned in that
area... Anything to solve that problem.
>and I've tasted
>their sweetness in flashes of inspiration, but I just don't have it.
But you've never tasted the sweetness of power sitting at a console with remote
root, gotten accidently by noticing and exploiting a 'weird bug'?
>What is it? I don't know. I don't suspect that I ever will, in this particular
>field. I think that I might just have it in another field (racing cars), but I
>think it's likely that I'll be Just Proficient at that, too, much as I have
>been at most everything for my whole life. And that's a pretty depressing
>thought.
Oh, is it? Look at your skills as a stat with a library of different happenings.
Who else here, let alone else in the world has your exact skill set and
memories? Nobody.
And so what, you'll be 'just proficient' in computing. That's way above the
average. Many people have a hard time of understanding "double click" or basic
computer terms. Put together and exploit what you do know and become an expert
in your field of knowledge. That'll get you respect, and access to more
information.
The "it" (Score:1)
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!
Great Hackers (Score:3, Interesting)
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.
Re:Great Hackers (Score:2)
That's what I was trying to say, but shorter, and included the specifc Larry Wall reference I was thinking when I wrote my reply.
That will teach me to post a followup before reading the already posted replies. <autolart>
Re:Great Hackers (Score:2)
No need to worry, we all talk out of turn here.
Hey wait, you've got a lower UID.
No, no excuse.
I think that's nonsense! (and the meaning of IT) (Score:2)
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.
Re:Unstable xterm (Score:1)
tail -f log | cat -v (Score:5, Informative)
Re:tail -f log | cat -v (Score:4, Informative)
It does help to reread the manuals occasionally.
Poking fun at Enlightenment? (Score:1, Insightful)
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)
Re:Poking fun at Enlightenment? (Score:2, Insightful)
It's not that simple. (Score:2)
Re:It's not that simple. (Score:2)
How many of us happen to put pictures of our terminal windows up on our websites?
Gee, I wonder how many desktop themes I've looked at that say "Look how great a terminal window looks in this them!". I know for a fact that MPlayerhq has terminal windows in some screenshots.
Hm, I wonder how many of us don't put pictures of our terminal windows up on our websites? That's probly a smaller number than the one you're looking for....
"write"? (Score:3, Informative)
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
Obvious fix. (Score:2)
Something any smart sysadmin would do, anyway, to display just exactly what was showing up in the log.
Re:Obvious fix. (Score:2)
Cygwin's manpage says it's ignored, too.
-u means "unbuffered". 'cat -v' would wait for newlines. I wonder how linux and cygwin get around the difference. Hopefully, by always being unbuffered.
Doesn't have to be a tail or log file. (Score:3, Interesting)
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.
Forget about emulators, just hack real terminals (Score:4, Informative)
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.
Re:TXT? (Score:1)
Come on, is it that big of a deal really?
Re:TXT? (Score:5, Funny)
Re:TXT? (Score:1)
And here I thought they were referring to RFC 1464: Using the Domain Name System To Store Arbitrary String Attributes [rfc-editor.org]....
Re:TXT? (Score:1)
Re:In case of slashdotting... (Score:1, Insightful)
In other words, it's not going to get slashdotted, so stop karma whoring.
Re:In short... (Score:2)
Actually, Windows *does* have a logging feature, but, in typical Microsoft overdesigned-anal-retentive fashion, it's a pain in the ass to use. Look at "Event Viewer" in the Administrative Tools sometime. I forget the API, but you (the programmer) need to fill out some complex structures and do something-or-other unintuitive to dump a message to the log. To actually see it, you need to go through a scrolling list of messages marked "Information" and doubleclick one to see the actual text.
I don't think anyone actually uses this, other than driver writers and those with the plugs in the backs of their heads.
Re:In short... (Score:2)
Similar situations existed for the registry, DCOM, performance counters, security model, etc., etc.
Re:In short... (Score:2)
I remember looking at that whole business once and going back to logfiles. Although, the message/resource file business *is* a lot more maintainable and internationalizable, and the process isn't all *that* bad. Let's just say it's overkill for 90% of things.
Windows - the Ada mindset of software development!
Damn, I remember being a Perl & Unix hacker, hot the fsck did I end up coding for Winblows XP???
That nice big paycheck at the end of the week helps mitigate the pain and guilt, I've found. Of course, "big" and "mitigate" are relative words.