PLEX86  x86- Virtual Machine (VM) Program
 Plex86  |  CVS  |  Mailing List  |  Download  |  Computer Folklore     

Exploiting Linux vulnerabilities


Exploiting Linux vulnerabilities 8127
On Sunday 22 January 2006 10:11, Erik Funkenbusch stood up and spoke the following words to the mbuttes incomp.os.linux.advocacy...: JPBis Bailo? Woops, I must have missed that... ;-) Oh, I see...

We know that it's possible for flaws in software running on Linux, for example: KDE flaws put Linux, Unix systems at risk ClamAV hole sees Linux vendors rush out updates so (at least in principle) we know that a remote attacker might be able to get arbitrary code to execute on some Linux machines.

We also know that with Linux, that would usually only be the first step to taking over a machine, as the exploit code would typically only execute with user privilege, limiting what it could do. The cry then goes up from Linux detractors and Microsoft apologists, to claim that doesn't matter, because the malicious code can still do "everything it needs to", such as use the network, send email, and access or damage user data.

Exploiting Linux vulnerabilities 8123
You have a number of flaws in your argument, as well as a lot of "hoping...

However, I don't quite get this, because when I look at the behaviour of actual virus-worm-trojan attacks against Windows, that *isn't* all that successful and automated malicious code needs to do; getting to execute once as a local user is only the start for malicious code attacking Linux, with further obstacles to overcome in order to propagate effectively.

Exploiting Linux vulnerabilities 8124
No, it's not impossible at all. But the level of difficulty is quite a bit higher, which reduces the pool of talent that...

If it's a case of exploiting a buffer overflow or similar, then often the malicious code that executes is just a stub, which retrieves further code. Unlike the recent Microsoft-WMF flaw, which took advantage of a "feature" *designed* to run code from a data file, it's likely that unplanned weaknesses such as overflows run a risk of crashing processes, rather than executing any arbitrary code at all, and so it makes sense for malicious code to be crafted as the smallest possible stub, which can then remotely pull in the rest of the attack.

So far, so good for the malicious code, and the same could be done under Linux for an initial stub to "bootstrap" itself. Now what does the putative virus-worm-trojan "want" to do, as it were? There is obviously an immediate top priority, if it is to propagate: If it can't do that, then it may only ever get one chance to execute. It's quite likely to crash by itself anyway, as especially with Linux there is no way it can anticipate in advance what sort of system environment it might be trying to execute under, and if it causes any noticeably odd system behaviour the computer may well be restarted deliberately by the user.

Either way, unless it can hook itself up to auto-start in future, it's not going to be doing anything for very long, and it's not going to propagate itself effectively if it gets wiped out in the next reboot. Setting itself to auto-run might be easy on Windows; to do the same on my Linux box not so easy, and it will "want" to acquire root privilege to be sure of doing so.

So getting root access *is* important for malicious code to do, and local user exploits on their own are insufficient; nor is rooting a Linux box necessarily that easy to do (a subject for another post!). If denied root access, then propagation of the malicious code is going to be ineffective.

What about the user data? Of course our putative malicious code is able to access or damage the user's data, which is important for the user in a way that the OS files are not. However, damaging data is a bad tactic for malicious code to use; for example, at the extreme end if it deletes the user's data outright, it is guaranteed that the user is going to notice and do something about it, whether undertaking their own recovery or seeking more send buttistance. Either way, the malicious code has also just guaranteed that it's going to get wiped out as well, which means it won't be propagating on anywhere any more.

That won't bring back that user's data; but it does ensure that the impact will be isolated and the infection won't spread. Just like a real virus, killing your host, and especially killing your host quickly, also means that the infection won't spread in the population as a whole. The more destructive the malicious code is, the less effectively will it propagate; the less destructive and more stealthy it can be, the more likely it is to survive and keep propagating for months or even years to come.

Why do I go on and on about propagation? Because that is the essential element for successful automated malicious code, and the more propagation is made difficult or denied, the more the population is secured from attack. *That* is where better security and better immunity from mbutt-automated malicious code comes from, for people using Linux.

Not from "security through obscurity", or relative popularity. Not because there are never any exploits possible against Linux, nor because it's impossible for a determined "black hat" to specifically target and compromise a particular Linux box. Security and immunity comes because automatic propagation is difficult or impossible, so that if a threat which can take advantage of a possible exploit does arise, it dies out fast, affecting at most only a few of the potentially vulnerable users.

Again, just like real world infections, when there is no monoculture and propagation is difficult, there is no need to achieve 100% immunity for every member of the population - all that is necessary is sufficient immunity to slow and halt propagation so that any spreading infection follows an exponential decay curve, rather than an exponential growth curve.

Exploiting Linux vulnerabilities 8128
GreyCloud OK, got that. Without a ~-.profile sounds nearer to what I was after. Two situations come to mind: 1) Larger scale multi-user, where the user does *not* own the computer, but the administrators...

And that *is* a perfectly achievable level of security and immunity to aim for, and which Microsoft and Windows software lacks.

-- JPB


Linux | Previous | Next

Exploiting Linux vulnerabilities 8123

Linux Advocacy Newsgroups

My screeching of the song, _Whiter_Shade_of_Pale