Security
mod_spambot
It has been known for years that spammers harvest web sites for email addresses to add to their lists. Various sites have responded by hiding or obfuscating email addresses found on their pages; some people go to extreme measures to keep their address from ever appearing on a page. One wonders what they are worried about; your editor only receives a mere 3-4000 spams per day to his highly-public email address, after all.Suffice to say that without SpamAssassin LWN would likely have collapsed under the flood years ago.
Some folks have decided that it is time to take a more active stance against the harvesting of email addresses from web pages. The result is an Apache module called mod_spambot; version 0.47 was recently released. The idea behind this module is to detect accesses by address harvesters and shut them down. Unfortunately, the approach this module takes is too simplistic to work in many situations.
mod_spambot is essentially a traffic throttling module. If a given site pulls down too many pages in a given time period (default is 100 pages in one hour), its access is cut off. There is also a "honeypot" option which will, instead, feed the (presumed) harvester a set of pseudo-random pages with bogus email addresses in them. This approach may well cut off some spammers, but anybody who has maintained a busy web site can see a few problems fairly quickly:
- This approach will also cut off others who may be grabbing large
numbers of pages from the site. Search engines come to mind, as do
archive sites or anybody wanting to mirror a portion of a site.
Cutting off people who thoughtlessly run a recursive wget to
grab an entire site has some appeal; "download the site" operations
account for a substantial part of LWN's bandwidth usage. But most
site operators do not want to pull the plug on search engines and the
like. mod_spambot allows the administrator to construct a whitelist,
but who wants to figure out how to whitelist every possible search
engine of interest?
- There are some very large networks out there hiding behind a
massive router and a single IP address. Traffic which looks like it
originates from a single host may, in fact, be generated by hundreds
of individual readers.
- Increasingly large amounts of traffic are generated by robots whose sole purpose is to get a referrer URL onto a "top referrers" page somewhere on the site. Purveyors of Internet gambling experiences and particular types of imagery appear to like this approach to marketing. The interesting thing is that these accesses come simultaneously from a large number of IP addresses. These people, clearly, are using a network of zombie machines for their attacks. Spammers already use zombies to deliver their mail; it is hard to believe that they would not use those machines for address harvesting as well.
So throttling robots based on IP address will miss some attackers while blocking legitimate users of the site. It would be nice to prevent one's web site from being used as a resource by spammers, but this approach is not, yet, the way to that end.
Brief items
Update on RFID passports
Bruce Schneier looks at current plans for RFID-enabled U.S. passports; it seems that things are headed in the right direction. "The most important feature they've included is an access-control system for the RFID chip. The data on the chip is encrypted, and the key is printed on the passport. The officer swipes the passport through an optical reader to get the key, and then the RFID reader uses the key to communicate with the RFID chip. This means that the passport-holder can control who has access to the information on the chip; someone cannot skim information from the passport without first opening it up and reading the information inside. Good security."
Greasing the wheel with Greasemonkey (SecurityFocus)
Here's a SecurityFocus column on how the recent GreaseMonkey vulnerability was handled. "If we must continue the discussion to encompass the model of open source, then I have to say that the approach Greasemonkey took shows what makes open source great: openness. Throughout the whole painful process, information was available to those who needed it: developers, IT folks, users, and security pros. No one was kept in the dark, and all the details -- code, communications, thought processes, and so on -- were always available so that interested parties could make decisions based on facts instead of promises and conjecture."
New vulnerabilities
gaim: buffer overflow
| Package(s): | gaim | CVE #(s): | CAN-2005-2103 | ||||||||||||||||||||||||||||||||
| Created: | August 10, 2005 | Updated: | February 27, 2006 | ||||||||||||||||||||||||||||||||
| Description: | Gaim suffers from a heap-based buffer overflow which can be exploited via a hostile "away message" to execute arbitrary code. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
sysreport: insecure temporary file
| Package(s): | sysreport | CVE #(s): | CAN-2005-2104 | ||||||||||||
| Created: | August 9, 2005 | Updated: | November 11, 2005 | ||||||||||||
| Description: | Bill Stearns discovered a bug in the way sysreport creates temporary files. It is possible that a local attacker could obtain sensitive information about the system when sysreport is run. | ||||||||||||||
| Alerts: |
| ||||||||||||||
ucd-snmp: denial of service
| Package(s): | ucd-snmp | CVE #(s): | CAN-2005-2177 | ||||||||||||||||||||||||||||||||
| Created: | August 9, 2005 | Updated: | January 27, 2006 | ||||||||||||||||||||||||||||||||
| Description: | A denial of service bug was found in the way ucd-snmp uses network stream protocols. A remote attacker could send a ucd-snmp agent a specially crafted packet which will cause the agent to crash. | ||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||
xpdf: denial of service
| Package(s): | xpdf kpdf | CVE #(s): | CAN-2005-2097 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Created: | August 9, 2005 | Updated: | August 2, 2006 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description: | A flaw was discovered in Xpdf in that could allow an attacker to construct a carefully crafted PDF file that would cause Xpdf to consume all available disk space in /tmp when opened. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Page editor: Jonathan Corbet
Next page:
Kernel development>>