User: Password:
|
|
Subscribe / Log in / New account

Storm worm gains strength

Storm worm gains strength

Posted Aug 30, 2007 4:44 UTC (Thu) by tzafrir (subscriber, #11501)
In reply to: Storm worm gains strength by flewellyn
Parent article: Storm worm gains strength

Even without SELinux: there should not be a habit of running an executable.
You should not be able to easily install an rpm or deb package from your browser.

Note that if installing an rpm or deb off-the-net becomes a common practice, then simply blocking an automated of it will not help - users will soon find the manual procedure for that.

It's a procedure users should know not to try. The problem here is not technological. It is a matter of getting the right working habits.


(Log in to post comments)

Storm worm gains strength

Posted Aug 30, 2007 8:53 UTC (Thu) by IkeTo (subscriber, #2122) [Link]

> You should not be able to easily install an rpm or deb package from your browser.

That is true, but it is harder and harder to see why social engineering will not happen. All it takes is for a page from somewhere like 12.34.56.78:9012 claiming that you can do some interesting stuff (e.g., free access to porn) by installing their .deb or .rpm, and tell their users to just download their file and say "sudo dpkg -i interesting.deb" or "sudo rpm -i interesting.rpm". Voila, a whole bunch of clueless users will join their botnet. And their naiveness will tell them to just run "sudo dpkg -r interesting" or "sudo rpm -e interesting" to deal with the problem, and their package will be successfully cleaned up, only that their ls, rm, or even dpkg/rpm are already replaced by something downloaded from the web.

Ease of use and security should always go together. The current problem of the whole industry is that they don't. The public directly react to ease of use, they don't react to security, so the producers of software are geared towards creating software that are easy to use and compromise. If we start from having "must be secure" as one of our top priority, we will instead install every package in a sandbox, and have dpkg/rpm manage the external interface of the sandboxes, and have SELinux to make sure that the dpkg/rpm database as well as their binaries and other supporting files can only be modified by dpkg/rpm itself or in recovery mode. This is never done.

Counting on education is dangerous too. With the Internet/computer users doubling every few years, it means there are always half the users that have less than a few years experience with Internet/computers.

Perhaps it should be time to start something new, making use of all the fancy security features available, to make sure we have a "easy to use *and* secure" system to offer to the naive mass.

Storm worm gains strength

Posted Aug 30, 2007 10:25 UTC (Thu) by MathFox (guest, #6104) [Link]

Sorry, security and ease of use are conflicting requirements. A simple example: wouldn't it be much easier if you didn't use the lock on your front door, no need to worry about taking the key with you, no need to put the bag with groceries on the doorstep while digging up the key....
I agree with you that security has been undervalued by major Operating System vendors, but even Microsoft is working very hard on fixing that.

About your proposed social engineering attack: the post-install script of the rpm or dpkg can just copy and activate the rootkit that's hidden in the package... nasty nasty nasty. Is there an easy way to prevent these kind of social engineering attacks; nothing that beats education.

Storm worm gains strength

Posted Aug 30, 2007 12:44 UTC (Thu) by IkeTo (subscriber, #2122) [Link]

> Sorry, security and ease of use are conflicting requirements.

> A simple example: wouldn't it be much easier if you didn't use the lock on your front door, no need to worry about taking the key with you, no need to put the bag with groceries on the doorstep while digging up the key....

If you want the easiest to use system in the world to be rock secure, you are of course toasted. But if you want reasonable security in a system reasonably easy to use, there can be some discussion. Of course, adding development cost into the equation makes it harder. But to say "I only cater for the uneducated, some functionality can be forgone if most Joe users don't need them" can make it a easier.

> I agree with you that security has been undervalued by major Operating System vendors, but even Microsoft is working very hard on fixing that.

If you can enlighten us about what has been done by MS to prevent social engineering, it can be very constructive.

> About your proposed social engineering attack: the post-install script of the rpm or dpkg can just copy and activate the rootkit that's hidden in the package... nasty nasty nasty.

By "every package is in its sandbox" it means even the post-install (or whatever) script is running in its own sandbox, and if a program has been installed in global space for others to run, that program is under a sandbox that never include more than the combined power of the user and sandbox of that package. Everything, like installing a file in "/bin" or creating a cron job, can only be done under the management of dpkg/rpm. Other tweaking might be required, this need to at least give dpkg/rpm a perfect picture to clean up any mess produced by any package.

Of course, this is just out of my imagination. Any system that provides equivalent security is probably just as useful. It is not easy to develop such a system, at all. One must think about how programs are going to interact, how they are going to access user data, and there must be some serious research on how these things cannot be turned into attack vector. In a world where the threats are not there or are seldom seen, these will never happen. But in a world where threats are the norm, there are definitely incentives.

> Is there an easy way to prevent these kind of social engineering attacks; nothing that beats education.

Education can be "easy" to a single individual, it is hard to ensure education to a huge population, all of them from different countries and hence different law systems and values. In fact I believe it isn't going to work at all. Even for well educated people, it is sometimes very tempting to install something that they really shouldn't, and it can be real hard for them to know whether something is safe to install. And the black hat only need a few percent of the network population to have made a wrong decision before they can build a huge botnet. In such hostile environment, we simply cannot count on 90% of the people won't make a wrong decision during at least the first half of the life of their OS install!

Problem is, people are frequently asked to install a program, to the point that most people will not think that it is a security problem. Except it is. And people frequently see packages floating on the web, and many claims to do useful things that they want to do. And in most cases these claims turn out to be true. To the point that most people will trust that the thing they found will be among them, except they might be wrong. If we create a system to "look safe", it needs to actually be safe. Our current systems "look" safe, but they aren't.

Storm worm gains strength

Posted Aug 30, 2007 19:24 UTC (Thu) by oak (guest, #2786) [Link]

> that program is under a sandbox that never include more than the
combined power of the user and sandbox of that package.

So you would be only securing the system, not what user has? (user doesn't
care about "system", they care about their own data, the data to which
they have access)

> And people frequently see packages floating on the web, and many claims
to do useful things that they want to do. And in most cases these claims
turn out to be true. To the point that most people will trust that the
thing they found will be among them, except they might be wrong.

And currently Ubuntu is educating users with its sudo system that whenever
anything popups up a "password" dialog, you're supposed give it your own
password. And with that password the programs are able to do the same
things as root (with sudo). Secure, yeah...

Security by obscurity... "our system is more secure because it doesn't
have a well known root account name"... (It could be more secure if Ubuntu
would educate people to create a completely separate account for
administration.)

Storm worm gains strength

Posted Sep 1, 2007 8:42 UTC (Sat) by IkeTo (subscriber, #2122) [Link]

> So you would be only securing the system, not what user has? (user doesn't
> care about "system", they care about their own data, the data to which
> they have access)

Then they should. If the system itself is not secure, we don't have a basis to talk about data security. If the system is compromised, you can trust the system to recover from neither the system nor its data. If only user data is damaged you can still trust the system. Also, since distributions like Ubuntu enpower users without much previous Unix experience or knowledge to install a Linux based system, it means they are in charge of the system, so there is no "system administrator" but themselves to keep the system in a secure shape. But how distributions can make sure their users are capable to do so? The answer needs to be: By making it simple enough. Of course the user *also* care about data security. That is very much the same argument, albeit much more difficult to provide without very much education.

> And currently Ubuntu is educating users with its sudo system that whenever
> anything popups up a "password" dialog, you're supposed give it your own
> password. And with that password the programs are able to do the same
> things as root (with sudo). Secure, yeah...

I actually do not use a Ubuntu system regularly, I have installed one and used it for less than a week. So I don't perfectly know the security implications, even though I read a lot about it. On the other hand, popping up the password dialog is no longer unique to Ubuntu. Fedora does the same. The only difference is that they prompt for the root password rather than your own password.

So Fedora is more secure *because* it prompts for the root password instead of the user password? When a Fedora (or even Debian!) system asks for a user password? What is the difference that the system trains the user to distinguish? The answer: a Fedora user prompts for the user password only for (1) login, and (2) change user password. The system thus trains the user to distinguish system access and login/password changing. What a good deal... even the worst naive idiot can distinguish them! Bottom line, if a home user using Ubuntu can be tricked to type his own password and install a malicious .deb package, the same user having switched to Fedora can be tricked to type the root password to install an equivalent malicious .rpm package.

My belief is that the system design should distinguish two types of activities that the user can be expected to do: (1) those that the users are expected to do from time to time and are easy to do, and (2) those that are hard enough to do that the user will never do casually. (1) should be safe enough that the action cannot jeapodize the system at all; and (2) should be rare enough that a casual user need not use them at all. Since Ubuntu (Debian, Fedora, whatever) is a system that allows third party packages, and their target is to make it easy, it is in class (1), so it means they should be rock solid. This is perhaps a big dream, but having a dream is better than having no dream.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds