Ignoring my own advice because I think the communication point is important for all linux advocates.
Adam Bower abower@thebowery.co.uk writes:
Imaging my surprise when I heard that there was another iis worm doing the rounds! I didn't actually pay any attention to the reports of "another iis worm, that is going to destroy the internet" as there is a new one every week. [...]
It's not an IIS worm for two reasons:
1/ it uses javascript page modifications on broken IIS boxes and email via Outlook to trick OE and IE to infecting machines who receive data from the infected box;
2/ most Windows users don't know what IIS is anyway, so calling it an "IIS worm" doesn't get the point across.
It's a Microsoft Windows Virus. Let's make the mud start sticking.
This one after a bit of reading looks as though it is rather nasty and explains quite alot, I have heard of one person reporting that his apache server has been probed nearly 10,000,000 times in less than a day.
My estimate from logs at UEA is that between 10 and 20% of web traffic on the UEA network is this virus, although mostly from outside now that iTCS have slapped the compromised machines on campus. I expect more as students in networked rooms plug in, though. It really is a active bugger, this one!
Well I think we have a strong case to prove that Windows is criminally broken, I wonder if people with rooted iis boxen will finally see the light when they get the bandwidth bills at the end of the month?
You have to remember that the bandwidth bills are also hitting innocents, both because of scans of random IPs, but also because the ISPs will want to pass their costs on. People using Microsoft products are now costing us all money, even if we bought our computers without Windows.
This has to stop.
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.
on Fri, Sep 21, 2001 at 07:33:36PM +0100, Steve Fosdick scribbled:
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.
This is true, to an exent. The problem is, it assumes someone looks at the code. Unless your project is widely used, or someone is specifically asked to do so, the probability of someone auditing your code at all thoroughly is unlikely. WireX are about to launch a site that addresses code auditing, it sounds quite neat. (or they were, I can't find the email just at the moment..) Basically, it's the sourceforge of code auditing, with auditors ratings, projects, etc.
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:
- Lower installed base for Linux.
- Fast time to fix when security related bugs are found.
- More savy admins who keep the systems up to date with fixes.
4. Different security model. I have not used 2k/NT a lot, but I've worked with admins on them and have never seen them either: 1. Log in as a user who isn't a local administrator. 2. Used a simple utility like su or sudo to temporarily increase their privileges for a task. 5. Less understanding and in depth experience of unix in general amongst the virus making community.
There are two separate issues here:
- The bug that allows paths outside the web space.
How many people have apache chroot()d? How many still have a parent process running as root with all available (posix.1e) capabilities enabled? Or even, how many people use suexec?
Under nix, the ability to close this is in place, but it is not used much because it's tricky and can make things more awkward or the user is just ignorant of the facilities. Security needs to be the default and it needs to be documented and easy.
- Allowing a program which was not specifically written as a web program to be used from the web server unmodied.
I like this feature. To stop it you potentially have to look at code signing, different binary formats, different syscall/api call systems, trusted path execution, etc. all of which are messy and in the end, avoidable.
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.
Yes, it's the old security vs. usability argument alas.
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.
Why not run certain applications in a sandbox? Or at least with reduced privileges. eg. web browser can *only* write to home_directory/.web/ and also has certain system calls disabled, like the ability to execute anything outside some trusted path (because users want helper applications like flash, telnet, email, etc)
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.
I also think they are programmer problems. Arguments are made saying it's the language the programmer uses. For example: "c has buffer overflows, use perl/whatever!", but once you take out buffer overflows you end up with the inability of programmers to create a decent authentication system. (Think hotmail, banks, etc)
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.
I agree security is very important. However the general user of Microsoft products knows little about security and these problems. And further more they aren't interested (general mac users are the same). They want a box to use MS Office on. Also MS doesn't seem interested in informing people of problems with their software (already mentioned on this list a few times)
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.
Good luck. Ease of use over security always wins with MS. If MS made secure and correct programs, it would kill off a major part of the computer support industry.
Ashley
Dr. Ashley T. Howes PhD www.ashleyhowes.com Programmer
"When he sees the dream he seeks, he will sleep"
-
ahayes＠ntlworld.com -
Ashley T. Howes -
MJ Ray -
Steve Fosdick