You're not the only one that thrives without having "the right papers". Thank $DEITY that there are some people that look beyond the pedigree, but look at real skill sets.
If programming is something that comes naturally to one, and if a person actually loves to do it as well (and forgo simple needs like eating, sleeping, and drinking for extended periods of while whilst one is in the 'zone') then one should seriously pursue such a thing and exploit that to the fullest:) Of couse you should not forget to have a life. Jordan seems to have that all in check pretty well, although he's still a busy man.
Sometimes I wish I had the time management skills of some people....
Well, remember that there are lots of people less careful than most of us. Fine, you use different passwords everywhere. You use a NATted network with private networks. That's good. But some people aren't that careful.
> Most software vital to keeping the system operational cannot be affected by a non-root user
tty's are not 'vital' for functionality:) Have a look on your local *nix box, find out on which tty or pty you are, and ls -l the corresponing entry in/dev . Now who is the owner, and which file modes does it have? Yups! it's owned by your userid, and the modes are usually 660 (user group uucp usually, some older systems even use 666, to make nifty stuff like talk(1) and write(1) work properly)
Yes, you are the full owner of your own tty lines on the systems. You can do anything you wish with them. Read from them, write to them. Your shell does that too. What stops some daemon to hook in and log well.. everything you type? Absolutely nothing. They get reset to root ownership once you log out.
You are right about the rest though. It's way easier to social engineer someone to run your malicious code than to exploiting with no human assistance:)
> It first has to get itself installed. Want to name a few that have suceeded?
It only has to run. And by the way, if it's a big project that gets trojaned by someone, it _will_ take you a while until you or other find out. In the mean time between you finding out about the back door, several copies might be running already on you systems.
You need to get off the "Oh this will not happen to my systems"-stance. Once you think that, get worried. What if it does happen, and sensitive data gets sent to god knows where, gets corrupted or destroyed? What then? Have you taken precautions against that? Not only post-mortem actions (like restoring backups), but how about proactive measures?
There are lots of ways to audit, protect, restrict access and fix problems, but a 100% secure system is impossible. You are human, I am human. We make mistakes and overloook things. If we code, we introduce bugs into code. Some are very hard to spot. Some are very hard to really fix correctly. Every bug _could_ be a security hazard, and also very well intended features can lead to compromise. It's a scale that balances between security and useability. You can not have lots of both. If you want more security, you need to sacrifice some useability. Do you really think a developer will work on such a restructed machine? I think not (unless you're DJ Bernstein perhaps;- ). Most developers work from their own workstations to write code, compile, test, debug, fix bugs and commit code into a repository. Having a useable environment with a $HOME they can do their stuff in, a useable shell, a useful editor and a working toolchain. Are they possible victims of a trojan? Possibly. Will they be productive if you hammer their workstations tighly shut with excessive restrictions? Not really.
Also, a given is that there are many new to any kind of unix that are setting up unix boxen. The software is easy to get a hold of, so lots of novices try their hand at it. I assure you that many of those novices are not well versed in the dark art that is called "security" and will set up their boxes insecurley.
It's not what _you_ would do, it's the way joe sixpak sets up his newfangled RedHat box, runs a malicios script without even pondering about md5sums, noexec mounting, scratch filesystems, chroot jails, sandboxing, firewalling, security policies and grepping through perl, Makefile, C or shellscript code. Many joe sixpacks will use the root user as their primary user (even though they are recommended to do otherwise).
So every argument you make, (albeit useful, I could also think of lots of ways to run untrusted code in a sandbox) are kind of moot, because you will only need a few idiots that don't take care. And trust me, there are idiots enough out there. And that goes for all operating environments out there.
Oh, and why isn't every UNIX box trojaned to hell and back nowadays? That's because unix still off the collective scope of trojan/virus/malware coders. You better take heed and take extra care, because once UNIX gets veru very popular, the things I'm speculating about might verywell become commonplace. What would we do? Switch back to MULTICS? Every MULTICS machine I've heard about is trojan and virus free you know... does dat make it an immune system?
No system is immune. Period. As long as the machine can run executable code, there is a possibility for a trojan to run rampant, however slight.
well, that would work somewhat, but what if it's obfuscated:)
I guess you might be somewhat in the right direction if you make the -i switch for rm the default (with an alias or something). Then it will ask you if you're sure you want to erase $HOME.
Trying a suspect script out in a chrooted cage or a non-networked FreeBSD jail would be an idea too.
> On a scratch partition which should be the only one on the system that isn't noexec, writeable only by root, or read-only. Give each developer a directory in the scratch filesystem and symlink it into his $HOME. This also will protect you when one of those programs they want to run goes amuck.
Only root can write? How can developers create executables then when they can't write them to the filesystem? They have to su to root, or use sudo to run make or gcc? Not a good idea. Even when they have to use different machines to debug/test, people tend to use the same password on multiple systems. When one system is compomised, more usually follow.
And besides: It still doesn't prevent a trojaned app to start a daemon that hooks the developers tty. That's called a keylogger, and they can run as a normal user, because when you log in, you become the owner of your tty, hence you can read/write from/to it. Add some remote connecting capability or a capability to send mail and your system is compromized.
It's very hard to stop these kind of attacks. Of course you can try to make a system idiot-proof, but don't forget that the universe creates cleverer and cleverer idiots at a faster rate:)
Windows troll? ROFL! That's the first time someone ever called me that for being critical and a devils advocate. This _must_ be slashdot:)
Try UNIX administrator and developer with over 7 years of experience with the wonderful platform (Linux, IRIX, *BSD, SunOS and Solaris, if you really want to know).
I _know_ what I'm talking about. And no, it's not personal experience, just speculation. And real threats.
Pick up the Practical Internet and UNIX security book from Garfunkel et al, and be enlightened. It's an old book, but it already mentioned malware and trojans on UNIX systems.
Watch who you're trying to troll. I'm not some fucking newbie.
Exactly! Mod the parent up please. It's an excellent example.
Another option is to trojan a deeply buried Makefile or a Makefile.in in some application. Good luck digging through all the Makefiles or Makefile.in files for weird make targets...
Heck, one could even use the make @ prefix to make compiling that little trojan app silent...
That's kinda tough when you have developers on your system. How the hell are they going to actually _run_ stuff? I think being able to run stuff from your $HOME is a bit of a necessity for people who code for a living.
If it were just people reading mail and doing basic stuff from the shell you would be right though. But still, what if a user, frustrated because he can't run some app in his $HOME, turns to/tmp,/var/tmp,/usr/tmp or (sometimes) even/var/spool/uucp (which is usally chmodded 1777 and appears on lots of systems that don't even _have_ uucp installed)? Sure, mount your root fs or/usr fs noexec when these dirs are not mounted on a seperate filesystem (which happens on lots of systems)... Have fun recovering:)
There are clueless people out there that do it and cause it to "spread". Just like those dunces that click on trojaned outlook attachements.
Tha apt argument: Being a little paranoid about signatures is not a bad thing. But what if your local debian mirror becomes compromised? Would you notice? I doubt it. Will apt notice? I don't think so.
> To do anything these viruses need to run as root. But the article make no mention of this, or how a virus could get root.
Oh ye of little understanding...
What if a "virus" just nukes your $HOME? Say goodbye to that 45 page thesis you slaved over the last few weeks..
Or, let's say you are a wheel user, you execute this innocent looking malware, and suddenly a daemon gets started that hooks into your (pseudo) tty (because, when you log in, they get chowned to you) and logs your keystrokes? You su to root, and the keystrokes get mailed somewhere... with your box IP number and username. Well, the attacker just got your root password. Worried yet?
A "virus" doesn't need root. It just needs a uncareful human.
Well, shall we remove all scripting from the UNIX shells so these threats don't have a chance? Oh, and lets boycot perl too. It's too damn flexible. A malicious user could write a virus with it with great ease! Oh, and while we're at it, lets abolish compilers too. *mutter* *mutter* *mutter*
(yes, this wasn't meant seriously. but it _is_ on topic:)
Now _HOW_ the _FRIGGIN_ hell did login get trojaned?!?! I'm _sure_ I reainstalled the compiler from scratch. It _can't_ be from there!;-) <-- notice the wink, yes an attempt at sarcasm.
Oh, I love UNIX, I use it exclusively at home, but people saying thatt *nix is invincible 1) piss me off, 2) should hand in their advocacy badges. The malware suddenly "appearing" in popular unixes just goes to show that how more visible a platform becomes, the more viruses [1] suddenly appear.
By the way, using the printing facility to overwrite files in $HOME is more like making software do what it's not supposed to do just to prove a point: a hack, be it one that's possible often (a bit like printing to a file called `/bin/sh -i |` or something else in that ilk:) But yes, "malware" could exploit these bugs and "spread" futher.
[1] No I don't spell it like 'virii' anymore. Webster's told me not to
For example, take shell archives (shar). Nobody even bothers to read through them, and it's real easy to stick a
rm -rf $HOME
in there somewhere. There, instant malware. And it's age-old. What about./configure scripts? Or Makefiles? Nice targets to pass on to the unsuspecting punter.
> Oh, and in case a manger might need to get in you can number them 1 and 2.
Uhmmm yeah right... If you want that password to appear on a post-it note on a screen in the office, you should do that. And before y'all spout off that there are also competent managers out there: Most manglement type people I worked with are pointy-haired. Yes most. I''ve only known 2 managers in my carreer that were competent hackers (not crackers, mind you)
Escrowing your keys/passwords is a good idea, but please escrow your keys to people who you trust and from which you know that they are competent and can bear the responsibility of knowing that password/passphrase/whatever.
It's good that this is brought up. I need to escrow my keys to some people too before I kick the proverbial bucket. If I decide to leave life as it is and go for the after-life, my sucessor/replacement should be able to administer it.
I used to work on Sun Rays too, at this place. Usually I used my newfound mobility with the Sun Rays to get *away* from annoying coworkers so I could get some work done:)
This technology has been around for a while though... I sure digged it. It's really easy when you need help from a collegue: You just rip his card out of the sunray and pop yours in. There, now he's sitting behind your desktop, looking at your problem. Very handy.
Let's turn that argument around: What if their servers turn to shit within the first two weeks they go online, and stay broken because they can't handle the load? It could happen, microsoft underestimated heavy load before (case in point: terraserver, which had BIG problems).
Slashdot Mirror
That's the best news I've heard all day!
You're not the only one that thrives without having "the right papers". Thank $DEITY that there are some people that look beyond the pedigree, but look at real skill sets.
If programming is something that comes naturally to one, and if a person actually loves to do it as well (and forgo simple needs like eating, sleeping, and drinking for extended periods of while whilst one is in the 'zone') then one should seriously pursue such a thing and exploit that to the fullest :) Of couse you should not forget to have a life. Jordan seems to have that all in check pretty well, although he's still a busy man.
Sometimes I wish I had the time management skills of some people....
That's what I did once. It didn't modify the mail's body, it just added a convenient X-Spam header.
And don't forget the shortage of printer toners... Even if you don't even own a laser printer of copier...
Well, remember that there are lots of people less careful than most of us. Fine, you use different passwords everywhere. You use a NATted network with private networks. That's good. But some people aren't that careful.
> Most software vital to keeping the system operational cannot be affected by a non-root user
tty's are not 'vital' for functionalityYes, you are the full owner of your own tty lines on the systems. You can do anything you wish with them. Read from them, write to them. Your shell does that too. What stops some daemon to hook in and log well.. everything you type? Absolutely nothing. They get reset to root ownership once you log out.
You are right about the rest though. It's way easier to social engineer someone to run your malicious code than to exploiting with no human assistance :)
> It first has to get itself installed. Want to name a few that have suceeded?
It only has to run. And by the way, if it's a big project that gets trojaned by someone, it _will_ take you a while until you or other find out. In the mean time between you finding out about the back door, several copies might be running already on you systems.You need to get off the "Oh this will not happen to my systems"-stance. Once you think that, get worried. What if it does happen, and sensitive data gets sent to god knows where, gets corrupted or destroyed? What then? Have you taken precautions against that? Not only post-mortem actions (like restoring backups), but how about proactive measures?
There are lots of ways to audit, protect, restrict access and fix problems, but a 100% secure system is impossible. You are human, I am human. We make mistakes and overloook things. If we code, we introduce bugs into code. Some are very hard to spot. Some are very hard to really fix correctly. Every bug _could_ be a security hazard, and also very well intended features can lead to compromise. It's a scale that balances between security and useability. You can not have lots of both. If you want more security, you need to sacrifice some useability. Do you really think a developer will work on such a restructed machine? I think not (unless you're DJ Bernstein perhaps ;- ). Most developers work from their own workstations to write code, compile, test, debug, fix bugs and commit code into a repository. Having a useable environment with a $HOME they can do their stuff in, a useable shell, a useful editor and a working toolchain. Are they possible victims of a trojan? Possibly. Will they be productive if you hammer their workstations tighly shut with excessive restrictions? Not really.
Also, a given is that there are many new to any kind of unix that are setting up unix boxen. The software is easy to get a hold of, so lots of novices try their hand at it. I assure you that many of those novices are not well versed in the dark art that is called "security" and will set up their boxes insecurley.
It's not what _you_ would do, it's the way joe sixpak sets up his newfangled RedHat box, runs a malicios script without even pondering about md5sums, noexec mounting, scratch filesystems, chroot jails, sandboxing, firewalling, security policies and grepping through perl, Makefile, C or shellscript code. Many joe sixpacks will use the root user as their primary user (even though they are recommended to do otherwise).
So every argument you make, (albeit useful, I could also think of lots of ways to run untrusted code in a sandbox) are kind of moot, because you will only need a few idiots that don't take care. And trust me, there are idiots enough out there. And that goes for all operating environments out there.
Oh, and why isn't every UNIX box trojaned to hell and back nowadays? That's because unix still off the collective scope of trojan/virus/malware coders. You better take heed and take extra care, because once UNIX gets veru very popular, the things I'm speculating about might verywell become commonplace. What would we do? Switch back to MULTICS? Every MULTICS machine I've heard about is trojan and virus free you know... does dat make it an immune system?
No system is immune. Period. As long as the machine can run executable code, there is a possibility for a trojan to run rampant, however slight.
I guess you might be somewhat in the right direction if you make the -i switch for rm the default (with an alias or something). Then it will ask you if you're sure you want to erase $HOME.
Trying a suspect script out in a chrooted cage or a non-networked FreeBSD jail would be an idea too.
> On a scratch partition which should be the only one on the system that isn't noexec, writeable only by root, or read-only. Give each developer a directory in the scratch filesystem and symlink it into his $HOME. This also will protect you when one of those programs they want to run goes amuck.
Only root can write? How can developers create executables then when they can't write them to the filesystem? They have to su to root, or use sudo to run make or gcc? Not a good idea. Even when they have to use different machines to debug/test, people tend to use the same password on multiple systems. When one system is compomised, more usually follow.And besides: It still doesn't prevent a trojaned app to start a daemon that hooks the developers tty. That's called a keylogger, and they can run as a normal user, because when you log in, you become the owner of your tty, hence you can read/write from/to it. Add some remote connecting capability or a capability to send mail and your system is compromized.
It's very hard to stop these kind of attacks. Of course you can try to make a system idiot-proof, but don't forget that the universe creates cleverer and cleverer idiots at a faster rate :)
Windows troll? ROFL! That's the first time someone ever called me that for being critical and a devils advocate. This _must_ be slashdot :)
Try UNIX administrator and developer with over 7 years of experience with the wonderful platform (Linux, IRIX, *BSD, SunOS and Solaris, if you really want to know).
I _know_ what I'm talking about. And no, it's not personal experience, just speculation. And real threats.
Pick up the Practical Internet and UNIX security book from Garfunkel et al, and be enlightened. It's an old book, but it already mentioned malware and trojans on UNIX systems.
Watch who you're trying to troll. I'm not some fucking newbie.
And I'll leave it at that :)
Not to crack down apt, it's a neat system. But it's not perfect. Nothing is.
End of pissing contest please...
Another option is to trojan a deeply buried Makefile or a Makefile.in in some application. Good luck digging through all the Makefiles or Makefile.in files for weird make targets...
Heck, one could even use the make @ prefix to make compiling that little trojan app silent...
If it were just people reading mail and doing basic stuff from the shell you would be right though. But still, what if a user, frustrated because he can't run some app in his $HOME, turns to /tmp, /var/tmp, /usr/tmp or (sometimes) even /var/spool/uucp (which is usally chmodded 1777 and appears on lots of systems that don't even _have_ uucp installed)? Sure, mount your root fs or /usr fs noexec when these dirs are not mounted on a seperate filesystem (which happens on lots of systems)... Have fun recovering :)
On the other hand, writing a socket app in perl or even in C is not impossible or even rocket science.
I never new I could use the linux /proc fs _that_ way though...
Tha apt argument: Being a little paranoid about signatures is not a bad thing. But what if your local debian mirror becomes compromised? Would you notice? I doubt it. Will apt notice? I don't think so.
> To do anything these viruses need to run as root. But the article make no mention of this, or how a virus could get root.
Oh ye of little understanding...What if a "virus" just nukes your $HOME? Say goodbye to that 45 page thesis you slaved over the last few weeks..
Or, let's say you are a wheel user, you execute this innocent looking malware, and suddenly a daemon gets started that hooks into your (pseudo) tty (because, when you log in, they get chowned to you) and logs your keystrokes? You su to root, and the keystrokes get mailed somewhere... with your box IP number and username. Well, the attacker just got your root password. Worried yet?
A "virus" doesn't need root. It just needs a uncareful human.
Well, shall we remove all scripting from the UNIX shells so these threats don't have a chance? Oh, and lets boycot perl too. It's too damn flexible. A malicious user could write a virus with it with great ease! Oh, and while we're at it, lets abolish compilers too. *mutter* *mutter* *mutter*
(yes, this wasn't meant seriously. but it _is_ on topic :)
Now _HOW_ the _FRIGGIN_ hell did login get trojaned?!?! I'm _sure_ I reainstalled the compiler from scratch. It _can't_ be from there! ;-) <-- notice the wink, yes an attempt at sarcasm.
Thank you for that :)
Oh, I love UNIX, I use it exclusively at home, but people saying thatt *nix is invincible 1) piss me off, 2) should hand in their advocacy badges. The malware suddenly "appearing" in popular unixes just goes to show that how more visible a platform becomes, the more viruses [1] suddenly appear.
By the way, using the printing facility to overwrite files in $HOME is more like making software do what it's not supposed to do just to prove a point: a hack, be it one that's possible often (a bit like printing to a file called `/bin/sh -i |` or something else in that ilk :) But yes, "malware" could exploit these bugs and "spread" futher.
[1] No I don't spell it like 'virii' anymore. Webster's told me not to
For example, take shell archives (shar). Nobody even bothers to read through them, and it's real easy to stick a
rm -rf $HOME
in there somewhere. There, instant malware. And it's age-old. What about ./configure scripts? Or Makefiles? Nice targets to pass on to the unsuspecting punter.
Damn preview button :P
s/administer it/administer my systems/
*shrugs*
> Oh, and in case a manger might need to get in you can number them 1 and 2.
Uhmmm yeah right... If you want that password to appear on a post-it note on a screen in the office, you should do that. And before y'all spout off that there are also competent managers out there: Most manglement type people I worked with are pointy-haired. Yes most. I''ve only known 2 managers in my carreer that were competent hackers (not crackers, mind you)
Escrowing your keys/passwords is a good idea, but please escrow your keys to people who you trust and from which you know that they are competent and can bear the responsibility of knowing that password/passphrase/whatever.
It's good that this is brought up. I need to escrow my keys to some people too before I kick the proverbial bucket. If I decide to leave life as it is and go for the after-life, my sucessor/replacement should be able to administer it.
This technology has been around for a while though... I sure digged it. It's really easy when you need help from a collegue: You just rip his card out of the sunray and pop yours in. There, now he's sitting behind your desktop, looking at your problem. Very handy.
Would you still want to pay that amount?
I'll leave this question open...