It is Tom Ferris turn to receive the BigDiscovery Award for this week. He was the one that found out that Firefox (and Netscape and Mozilla) have a small problem with the handling of IDN URLs that contain the 0xAD character in the domain name. This can be exploited to cause a heap-based buffer overflow.
(Monty Python Moment: Quick cut to the elite Microsoft PR Open Source Taunting Force being airlifted to Firefox HQ and parachuting in for a session of placard-waving taunts insulting Firefox and Mozilla heaps, their overflowing buffers, and the programmers that work on them.)
Secunia (which rated the threat as highly critical) reports that the vulnerability has been confirmed in Firefox version 1.0.6 and is reported to affect versions prior to 1.0.6, and version 1.5 Beta 1.
If the exploit succeeds, it can crash Firefox and allow code execution. DDoS and injected code. Nasty.
For Mozilla, the vulnerability has been confirmed in version 1.7.11. Prior versions are reportedly also affected.
In Netscape, the vulnerability has been confirmed in versions 8.0.3.3 and 7.2. Other versions may also be affected.
Theres a social engineering element to all of this, however. The target of the attack must be induced to either read in a specially crafted HTML file or visit a malicious Web site.
Hmmm. Well, that explains why the workaround issued by Netscape is to view only trusted Web sites. Abstinence does prevent all sorts of bad things from happening. For that matter, so does unplugging the computer from any Internet access. Sometimes you dont know that you shouldnt have trusted a Web site until after you view it, though, do you? And how is Auntie Edna going to decide whether or not an HTML file is specially crafted? She cant, so it doesnt seem to be a good idea for her to use Netscape right now either.
There is a more direct mediation in Mozilla/Firefox, however. The vendor recommends setting the preference “network.enableIDN” to false. This can be done in the “prefs.js” file or using “about:config”. By not parsing the IDN URL, one can get upstream of the problem fairly simply rather than react after the problem occurs. This seems a reasonably robust way for Mozilla or Firefox to deal with this situation. Good coding, guys.
Link that system
If you have a Linksys WRT54G Wireless-G Broadband Router, Greg MacManus found that it can be exploited by those evil malicious people who can connect to the routers Web management software to bypass certain security restrictions, cause a DoS (Denial of Service), or compromise a vulnerable system. Secunia called it only moderately critical, so no prize this week, Greg. Try again later.
The vulnerability has been reported in firmware version 3.01.3, 3.03.6 and 4.00.7. All versions prior to 4.20.7 may also be affected.
There are a few problems in the devices software, including the POST method freaking out and dying on negative Content-Length values—a problem in upgrade.cgi that can be exploited by an unauthenticated user to upload arbitrary firmware onto the router, as well as a design error in restore.cgi that can be exploited by an unauthenticated user to upload arbitrary configuration settings to the router that will not take effect until the router is rebooted.
Also, there exists a boundary error in apply.cgi when sending a POST request to a page that has a content length longer than 10,000 bytes. This error can then be exploited to crash httpd and cause the Web management interface to become unavailable, and may allow code execution with root privileges.
Anyway, update the routers firmware to version 4.20.7 to fix all this.
Larry Loeb was consulting editor for BYTE magazine and senior editor of WebWeek. He serves as a subject matter expert for the Department of Defenses Information Assurance Technology Analysis Center, and is on the American Dental Associations WG-1 and MD 156 electronic medical records working groups. Larrys latest book is “Hackproofing XML,” published by Syngress (Rockland, Mass.). If youve got a tip for Larry, contact him at nospamloeb-pbc@yahoo.com.
