Slashdot Mirror
New Linux Worm
mspeedie writes "Seems Linux has very much arrive judging by the number of nasty virus starting to pop up. Check out the latest at:
Lion Worm Virus on Linux
" This is not a virus, its a worm that exploits a vulnerable bind to install a rootkit. Regardless, you should have tripwire or something running anyway.
Tripwire? If you were a real admin you would look at the source for BIND, declare it garbage, and run djbdns instead.
Run BIND on production servers? Not if my life depended on it. djbdns runs chroot()'d, non-root by default and even then the author still puts up a $500 reward for anyone who can find a security hole.
I'm so glad we modern admins have a choice. djbdns is a real, safe, fast, and well documented alternative to BIND and if I were your boss I'd fire you for not switching.
Friends don't let friends run BIND!
First of all... This is a linux problem and not just a Bind problem becuase bind gets installed in a lot of distributions by default. It's the same people who talk about linux taking over the desktop who later say that it's the user's fault that they should know what their machine is doing.
If linux is just for hackers, then fine. BUT, if you have ever expressed that you want linux to be the default instead of Mac, Windows or whatever then you owe it to yourself to be realistic about why most people use computers. It's probably different than why you do, and it's probably because they just want software that does a job for them. They don't care how it works and they shouldn't have to. We don't make fun of people who don't know what happened when their car breaks. Sure... it's respectable to know why, but it's not a sin not to.
And second...
Regardless, you should have tripwire or something running anyway
That is a total cop-out! I'm sure every one here knows that a windows user would get absolutly jumped on if they said something like that about windows security. "Security hole in windows? you should be running antivirus software. It's your own fault."
flame on.
-pos
The truth is more important than the facts.
The truth is more important than the facts.
-Frank Lloyd Wright
There are way to many machines running full services when only one or two listening processes are really needed, if that.
I do not deploy Linux. Ever.
Both Sendmail and BIND suffer from the same basic problem- they are huge monolithic programs that must be executed as root to perform their intended duties.
From the Qmail web site:Why is qmail secure? The reason I started the qmail project was that I was sick of the security holes in sendmail and other MTAs. Here's what I wrote in December 1995:
As it turned out, fourteen security holes were discovered in sendmail in 1996 and 1997.I followed seven fundamental rules in the design and implementation of qmail:
sendmail treats programs and files as addresses. Obviously random people can't be allowed to execute arbitrary programs or write to arbitrary files, so sendmail goes through horrendous contortions trying to keep track of whether a local user was ``responsible'' for an address. This has proven to be an unmitigated disaster.
In qmail, programs and files are not addresses. The local delivery agent, qmail-local, can run programs or write to files as directed by ~user/.qmail, but it's always running as that user. (The notion of ``user'' is configurable, but root is never a user. To prevent silly mistakes, qmail-local makes sure that neither ~user nor ~user/.qmail is world-writable.)
Security impact: .qmail,
like .cshrc and .exrc and various other files,
means that anyone who can write arbitrary files as a user can execute
arbitrary programs as that user. That's it.
A setuid program must operate in a very dangerous environment: a user is under complete control of its fds, args, environ, cwd, tty, rlimits, timers, signals, and more. Even worse, the list of controlled items varies from one vendor's UNIX to the next, so it is very difficult to write portable code that cleans up everything.
Of the twenty most recent sendmail security holes, eleven worked only because the entire sendmail system is setuid.
Only one qmail program is setuid: qmail-queue. Its only purpose is to add a new mail message to the outgoing queue.
The entire sendmail system runs as root, so there's no way that its mistakes can be caught by the operating system's built-in protections. In contrast, only two qmail programs, qmail-start and qmail-lspawn, run as root.
Even if qmail-smtpd, qmail-send, qmail-rspawn, and qmail-remote are completely compromised, so that an intruder has control over the qmaild, qmails, and qmailr accounts and the mail queue, he still can't take over your system. None of the other programs trust the results from these four.
In fact, these programs don't even trust each other. They are in three groups: qmail-smtpd, which runs as qmaild; qmail-rspawn and qmail-remote, which run as qmailr; and qmail-send, the queue manager, which runs as qmails. Each group is immune from attacks by the others.
(From root's point of view, as long as root doesn't send any mail, only qmail-start and qmail-lspawn are security-critical. They don't write any files or start any other programs as root.)
I have discovered that there are two types of command interfaces in the world of computing: good interfaces and user interfaces.
The essence of user interfaces is parsing: converting an unstructured sequence of commands, in a format usually determined more by psychology than by solid engineering, into structured data.
When another programmer wants to talk to a user interface, he has to quote: convert his structured data into an unstructured sequence of commands that the parser will, he hopes, convert back into the original structured data.
This situation is a recipe for disaster. The parser often has bugs: it fails to handle some inputs according to the documented interface. The quoter often has bugs: it produces outputs that do not have the right meaning. Only on rare joyous occasions does it happen that the parser and the quoter both misinterpret the interface in the same way.
When the original data is controlled by a malicious user, many of these bugs translate into security holes. Some examples: the Linux login -froot security hole; the classic find | xargs rm security hole; the Majordomo injection security hole. Even a simple parser like getopt is complicated enough for people to screw up the quoting.
In qmail, all the internal file structures are incredibly simple: text0 lines beginning with single-character commands. (text0 format means that lines are separated by a 0 byte instead of line feed.) The program-level interfaces don't take options.
All the complexity of parsing RFC 822 address lists and rewriting headers is in the qmail-inject program, which runs without privileges and is essentially part of the UA.
Keep It Simple, Stupid
I do not deploy Linux. Ever.
You probably shouldn't be running bind (or anything else). Linux's security problems are almost always created by people leaving stuff up/on/open when they don't need to.
If you're a newbie, here's a partial list of things you don't need to install or have running on your new workstation: bind/named, any form of mail server (esp. sendmail), atd, smbd/nmbd (samba), inetd, any form of ftp daemon (wuftpd, et al.), NFS/NIS/portmap, basically anything that provides a service to the outside world. Machines on "always-on" connections and not behind firewalls are of course the most vulnerable...
The best policy is offering nothing, and only selectively opening up services as you need to. If you do have a machine that needs to provide a service, try to understand the service and the idiosyncracies of the server program before you offer it, and keep tabs on updates...
Insert standard "wish-the-distros-would-wise-up-and-ship-closed-by -default-installations" thought here...
--
News for geeks in Austin: www.geekaustin.org
News for Geeks in Austin, TX