Like many people, I suspect, I felt just a little smug when it became apparent that there was a new worm affecting windows boxes and Linux seemed unaffected.
I was also very grateful for the fact that I could use Unix boxes we have at work including Linux without risk of getting this worm - useful in communicating and dealing with the worm.
I do think though, that we need to look at how this worm came to spread lest we should become complacent and fall into the same traps as M$ seem to have done.
Thinking back to Code Red, the first of the recent worms that have caused so much trouble, this exploited a buffer overflow in IIS. Buffer overflows are sloppy coding but M$ are not alone in publishing code with exploitable buffer overflows, there has been much code for Unix-like systems that has had the same problem including some programs that have been used in typical Linux distributions.
One difference between free software and proprietry in this respect is that with proprietry code you can hide sloopy coding which makes it attractive if it helps to meet a deadline. With free or open source software it is there for anyone to see, and someone who takes pride in his work would not want to seen to be so lax.
The above difference may account for fewer bugs in free software but I suspect it is not the major factor in a smaller number of successful attacks. I suspect the lower number of successful attacks is due to these:
1. Lower installed base for Linux. 2. Fast time to fix when security related bugs are found. 3. More savy admins who keep the systems up to date with fixes.
The next vulnerability, and the one exploited by Nimda to gain access to web servers, was one in which a program could fool the web server into accessing a file outside the designated web space. Add to this ability to tell the web server to execute a program to fullfill the request (specified by the client) and hand that program an exact set of arguments and you have the way open for the Nimda worm to tell the server to TFTP a copy of itself to the server and then execute it!
There are two separate issues here:
1. The bug that allows paths outside the web space. 2. Allowing a program which was not specifically written as a web program to be used from the web server unmodied.
I think this vulnerability demonstrates not only a sloppy implementation, but also a flawed approach to security. It would seem that whenever there is the choice of giving developers a chance to control the user, or implementing some sensible security, M$ do the former.
Now we come to the bug(s) in Internet Explorer. M$ Outlook calls IE to display HTML e-mail and does so in the cause of the mallicous e-mail that carries the virus. IE is tricked into executing the mallicous code and the infection is underway. M$ have a very poor track record in protecting their customers against mallicous code - they would rather developers can make everything unecessarily flash.
In this case it is time that IE (and e-mail programs) deliberately made it hard to execute code downloaded from the net rather than making it easy - that would ensure people didn't so it unwhittingly and the software didn't do it by mistake. The consequences are too serious to be playing around.
So, back to MJR's email in which he says these are windows problems. I beg to differ. I think these are M$ problems and if M$ dained to write software for Linux it would be fraught with all the same issues.
Comments?
Steve.