Posted on 11/28/2001 1:28:10 PM PST by Don Joe
A vulnerability in the most widely used FTP server program for Linux has left numerous sites open to online attackers, a situation worsened when Red Hat mistakenly released information on the flaw early, leaving other Linux companies scrambling to get a fix out.
"Other vendors didn't have a patch," said Alfred Huger, vice president of engineering for network security information provider SecurityFocus. The company has been working with vendors to fix the vulnerability after computer security company Core Security Technologies alerted them to the problem Nov. 14.
"The fix is not rocket science," Huger said. "But we weren't working at a breakneck pace to get a patch out, because everyone was working together."
The software flaw affects all versions of wu-FTP, a program originally created at Washington University at St. Louis for servers running FTP (file transfer protocol) functions for transferring files over the Internet.
While the exact number of active FTP servers on the Internet is not known, the software is the most commonly installed file server and accompanies most major Linux distributions, including those from Red Hat, SuSE, Caldera International, Turbolinux, Connectiva, Cobalt Networks, MandrakeSoft and Wirex.
The problem, known in security circles as the wu-FTP Globbing Heap Corruption Vulnerability, allows attackers to get remote access to all files on a server, provided they can access the FTP service. Since most such servers provide anonymous access to anyone on the Internet, a great number will be vulnerable.
Huger called the flaw "serious."
The impact of the software vulnerability was exacerbated because many Linux software companies were caught flat-footed by a surprise early release of information regarding the vulnerability.
While the group that discovered the flaw, Core ST, informed Linux software companies and the open-source group that manages development for wu-FTP of the flaw, Red Hat mistakenly released a security advisory to its customers on Tuesday.
Normally, an advisory is a good thing, but other Linux software sellers had expected any advisories to be published Dec. 3, giving them time to work on fixes. Instead, the surprise announcement left the customers of other companies' products vulnerable.
"We were releasing some advisories on the same day, and an overzealous administrator pushed this out as well," said Mark Cox, senior engineering director for Red Hat. The company is adding new safeguards to its publishing system to avoid similar problems in the future, he said.
"We put a stop to this," Cox said. "This will not happen again. It was a bad mistake."
Easy come, easy go.
"DJ, now you're talking. Do some open source work. You'd probably love it : )"
Does source code that's published -- with explanatory text -- in a deadtree magazine qualify as "open source"?
"I'll keep my expectations as low as possible."
Good; hopefully you'll be able to keep up with yourself.
Even after having their doctrinaire, rigid, wrongheaded binary choice pointed out, these guys persist in it, like Mike the Headless Chicken making the barnyard run.
One big difference, though, is that Mike's "gifts" were harder to scrape off the ground.
The HD I used to check the (infected) 440BX motherboard came out of storage. It was the first "clean" HD I tested to determine if the motherboard was infected. The HD and 440BX had been zeroed out and in storage for 11 months as my prior post indicated. I first tested the HD on the 440BX when both the motherboard and the HD were clean. Both the MB and HD initially checked out up through '98 installs. I then put a wiped but infected HD on the 440BX and loaded OSs to see their HD-vector virus corruption. The OSs were corrupted with the driver. I then went to the clean HD to see if the infection had carried-over from the infected HD to the motherboard. The fresh HD booted with the driver present in every OS I installed so imo that indicated bios flashing.
As for the vulnerability of bios as long as the bios is flashed at an address range that is not critical to system operation the machine will still boot. It doesn't have to be a full or normal flash both of which delete the old information as they flash new information. That wouldn't work for a virus since it would have to be chipset specific. In the case of a virus it just executes a flash to a non-critical, industry standard address range, overwriting existing data with its own. As long as it remains in that address range it will be booted with the system.
On my newer boards the bios was soft-set to "Disable Bios Updating" but this does not exclude access to the bios shadowing address ranges, some of which were enabled. However, this may not prevent the virus access to other bios memory ranges because the motherboard uses a soft setting. More below.
On the 440BX-2 it was jumpered to normal (vs. Maintenance) mode and it was similarly infected. I did not test the 440BX-2 at jumper set to Off for bios updating because I tested it to detect if it's bios could be infected by an infected HD. And it was. The board was clean, having come out of storage. That was how I confirmed the virus was flashing bios. My worry was the i815EP motherboard which only had soft settings and got infected with a 'Bios Updating' disabled setting.
Yes, the virus does locate on a HD's 13h handler because that becomes unreadable/"not present" on an infected HD but diagnostics checking will indicate it has more than 2MBs of data in it. The bigger issue is that installing a known-clean HD onto an infected MB will infect the drive as described.
The greatest concearn I had was how could it get into bios if I had the i815's updating disabled. It did and I confirmed it after getting it cleaned (CMOS + Bios) once and disabling updating and shadowing. It seemingly went right thru it. This is why I suspect CMOS because the only way to get rid of it was to pop the CMOS at the poweroff following a bios flash. If the CMOS was left in the flashed bios would come back with the driver. I've only tested that once though so I can't say definitively it's in CMOS. I'm pretty sure though cuz I wouldn't have popped CMOS if the flashes had taken.
It's either in CMOS or is unaffected by a bios flash, -which is unlikely. In any event the powering off after a bios flash and popping CMOS rid the infection. That's good enough for me.
I started Mandrake at the 8.1 betas and didn't see it. I searched the 8.1 release disc the other day and didn't find it. I haven't seen it on the others either.
Oh, so now you're into "customer perceptions"?
Hey, gimme me a bump when you start talking about parallel universes and aroma therapy.
LOL!!
Like the retail boxes of Mandrake 8.1 I saw today at Walmart, displayed in the middle of the MS products?
Ok, now I see it browsing the CD. It's in the same place in 8.1, a slightly different file though, wu-ftpd-2.6.1-11mdk.i586.rpm. I wonder if 2.6.1 is patched. Probably not. I went thru 8.1's installation options during an install and didn't see it listed as an FTP option. In any event it's not the default FTP -but it is there.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.