Slashdot Mirror
Don't Forget That Worms Happen Everywhere
friday2k writes "Securityfocus has a nice column on Worms and their origin in 1988. It explains what everybody should never forget. We have dealt with *NIX worms (Sadmind, li0n, ...) and they will come back again. Maybe then the MS fanatics will laugh and say: didn't we always tell you Open Source is insecure (too?) ..."
Maybe then the MS fanatics will laugh and say: didn't we always tell you Open Source is insecure (too?)
I once had an MCSE ask me, in all seriousness, why he couldn't type a fully-qualified hostname to choose a DNS server. It's a paper qualification; it implies no real skill or insight into the system's operation, or any sort of reasoning into consequences of limited design. Pass the test, get the certificate. Therefore, I consider MS fanatics to be, for the most part, a self-limiting reaction. They go away on their own. They kinda drop off the 'Net (maybe because of all the "Server Not Found" errors...). But with all the community colleges and business schools, they breed like bunnies.
As for worms, yeah, of course, any operating system has vulnerabilities. And if they're common and documented well enough, a worm or virus would be trivial for the right person to develop.
I think the more relevent question is with regards to the operating system's track record. With the exception of the recent blight of Red Hat 7.0, Linux has probably had far less documented bugs, and because of the UNIX user permissions model, the damages are minimum.
Compare this to Windows. Bugs all over the place, some more serious than those in Linux, some less serious. Where most machines are running 9x/Me with *no* user/process security whatsoever, malicious code can run rampant. NT/2000 is an improvement, but it's not designed into every aspect of the operating system's historical architecture. Windows has been one patch to DOS 1.0 after another, and the final result is such a kludge and so many processes are running with full administrative priviledges that the task of exploiting a bug remains trivial. Running Windows 2000 on my desktop is farcical - half my software won't work properly if I don't give my user account admin priviledges. It amazes me how many allegedly Windows 2000 compatible programs decide that they're going to attempt to store temporary information in the system registry instead of the roving user registries.
The single system registry is dangerous, too. Imagine, in your *NIX /etc/ directory, the file everything.conf, with the permissions -rw-rw-r--. What if you decide that you don't want Joe User to see your firewall configuration? Make everything.conf readable only to sys admins? Then, all of a sudden, all of the daemons have to have admin priviledges just to see their configuration. Urk. Kludge. Messy, dangerous kludge.
It makes me wonder what Microsoft was planning back when they designed the registry scheme. Sure, a centralized configuration database is a great idea, but not one if you're planning on building an operating system for the security risks of running it on the broader Internet. Yet, forgive me if I'm wrong here, but Windows NT 3.51 was the first M$ operating system to get away from /etc/-style distinct text configuration files (WIN.INI, SYS.INI, etc.), and they did that in 1994 with a badly flawed vision of the registry.
Contrast this to Linux or any other UNIX variant, the whole model and concept of which was designed with user and process security and isolation from the ground up.
As a bonus, the added complexity of administering multiple accounts to the average user is a pain in the butt. They want point-and-drool, everything clean and simple and familiar.
The beauty of the complexity of Linux/UNIX versus Windows is that it weeds out the chaff who aren't capable of managing a box.
I'm sure the programmers and architects at M$ see the problems and comparisons I'm drawing. To be designing an operating system, you must love computers and a sense of a job well done, so I'm sure it pains them that they have to deal with such kludges day in and day out. I'm sure they'd dump the whole thing and fix it if they could, but the marketing guys won't let them implement it.
Fire and Meat. Yummy.
It tests a limited and well defined check list of skills, most having to do with installation and configuration. Only with the Windows 2000 series did the tests begin to measure planning and design skills.
Installation and configuration, huh?
I had another one - employed at a major international airport, no less - ask me how to solve a BSoD on a FIDS computer. Note that this is one of several hundred displays running Windows 95 (I don't want to get into why).
I had to lead him through all the steps. The fault was in VMM.VxD, so it looked right off the bat like bad hardware. Of course, his reflex instinct - reinstall Windows - will automagically repair a bad transistor on the address decode logic of a RAM chip.
Step one, check that the fans are spinning properly. Two, check that the cards, processor and memory are properly seated. Three, run a good memory test. The machine was removed from the suspended ceiling about the flight display monitors it served.
Step Three caused the problem. I gave him a DOS troubleshooting program, and told him that he had to create a system disk and run it without any extended memory drivers loaded. I specifically told him to open a command prompt, stick in the diskette, type "sys a:", then dump the contents of the ZIP file I gave him onto the disk.
Of course, he ignored my instructions, and used the Add/Remove Programs - Create Startup Disk feature in Windows, then dumped the ZIP to it.
Predictably, when the machine started up, HIMEM.SYS was loaded, and trying to start the memory testing program caused only error messages.
He came back to me, walking all the way from the International Departures area to Domestic Arrivals, telling me that it didn't work. Note that, including code-shares, that airport handles over 2,000 flights a day - big airport, long walk. When I saw why it didn't work, I had to remind him that HIMEM.SYS was being loaded because he didn't follow my instructions.
"So, uhh, I have to format the disk and start over?"
Intrigued like a witness to a particularly gruesome lawnmower accident, I led him through a series of questions. How do you control real-mode drivers loaded during startup of DOS and legacy Windows? (CONFIG.SYS, he didn't know)
How do you ensure that no real-mode drivers are loaded up? (Delete CONFIG.SYS, or REM them all out)
Will DOS run without CONFIG.SYS? (Yes, he said no.)
If you edit CONFIG.SYS to remove the line that refers to HIMEM.SYS, will Troubleshooter stop complaining that there's an extended memory driver loaded? (Yes, but he answered no.)
What's another quick and dirty way to stop HIMEM.SYS from loading? (Delete or rename it. Blank, confused stare.)
He eventually deleted it and got it working, but he looked pretty scared at a command prompt. Rather than trusting him to interpret the results of the memory test, I told him to save them to a log file on the diskette. Intermittently bad memory, and knowing what SIMMs were in the machine and doing a bit of quick calculation, I blew him away by even telling which bank had the bad RAM. Oddly enough, Windows was right for once - one of the addresses in the BSoD's core dump was the same as Troubleshooter gave.
Configuration, huh? AUTOEXEC.BAT, CONFIG.SYS and HIMEM.SYS are pretty much the foundations of everything which has happened since. I would pay money to see him sitting in front of the Windows 2000 Recovery Console.
Now, you will, of course, forgive me for feeling superior to an MCSE.
Fire and Meat. Yummy.
Seems to me like Cmdr Taco is getting fed right up with Slashdot filling up with OSS and Linux anklebyters. Good to see. Slashdot's slowly turning into 'propaganda for nerds. Two Minutes Hate that matter.'
Vintage computer games and RPG books available. Email me if you're interested.