LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityBackscatter increase clogs inboxes Backscatter, also known as blowback, is the result of a spammer forging the sender address on an email that is sent to a non-existent address. Many mail servers do not reject invalid addresses when they receive the email and instead generate a bounce message sometime later. The unfortunate victim, then, is the one whose address was forged as the sender. Sometimes, hundreds or thousands of bounce messages can be generated which flood the inbox of an innocent bystander. Backscatter seems to be on the rise recently, the LWN inbox has seen a huge increase in the number of bounces over the last week or so. There may be some connection to some Google domains contributing to the problem, but that cannot explain all of it. One basic problem is that many mail servers are generating the bounce messages after accepting mail for invalid addresses, rather than rejecting it while the SMTP transaction is still in progress. When a mail server gets a connection from a sending machine, it gets several pieces of information about the email in addition to its contents. Both a "from" and "to" address are included in this extra information, which is usually called the envelope, for obvious reasons. After receiving each piece of the envelope, a mail server has the opportunity to reject the message. Typically this isn't done for valid-looking sender addresses, except in limited blacklist situations, but it certainly can and should be done when the recipient address is invalid. Due to a variety of mail server configuration issues, many mail servers do not avail themselves of rejecting mail for invalid senders. Instead, they defer their decision until sometime later. Servers that relay mail will not know whether some of the addresses they relay are valid, while other servers (qmail for example) separate the SMTP conversation program from the local delivery program for security reasons and thus do not have that information available. Other valid or semi-valid reasons exist, but once the mail has been accepted, the proper means of indicating a bad address is no longer available. In the days before spam—remember those?—a mail server could generally trust that the sender address in the envelope was the real sender. So an incorrectly addressed email could be bundled up in a bounce message and sent to the sender. If the sender address is valid, it is very little different than a bounce that is generated by the sender's machine when the mail gets rejected at SMTP time. Unfortunately, the majority of sender addresses these days are forged. But spammers don't want to use just any forged address, they want to use something that is valid or appears valid. Mail servers have gotten better at testing sender addresses for validity before accepting mail from them. So, where does an enterprising spammer get a valid email address? They pick one at random from their list of "500,000 guaranteed opt-in email addresses" that they bought from some other miscreant. They use those lists to send their spam to as well as using them to choose sender addresses to use. As might be guessed, the SpamAssassin mailing lists have been discussing the problem recently, especially trying to find ways to reduce the amount received. SpamAssassin does have the VBounce plugin to recognize bounce messages. By default, it doesn't increase the score of bounces by much as it is meant to be used with procmail to put bounces in a separate place from spam. Another idea floated on the list is to use SPF or DKIM records for a domain. The belief is that spammers avoid using those domains because it is likely to cause their message to be immediately classified as spam. Anecdotal evidence seems to indicate that backscatter can be significantly reduced in this way.
Security news Bruce Schneier reviews Access Denied Bruce Schneier takes a look at Access Denied, a new book on internet censorship from the MIT Press. "Today, things are very different. Internet censorship is flourishing. Organizations selectively block employees' access to the Internet. At least 26 countries -- mainly in the Middle East, North Africa, Asia, the Pacific and the former Soviet Union -- selectively block their citizens' Internet access. Even more countries legislate to control what can and cannot be said, downloaded or linked to. 'You have no sovereignty where we gather,' said Barlow. Oh yes we do, the governments of the world have replied."
New Massive Botnet Twice the Size of Storm (Dark Reading) Dark Reading reports from the RSA conference on an enormous botnet that is currently active with roughly 400,000 bots. "The so-called Kraken botnet has been spotted in at least 50 Fortune 500 companies and is undetectable in over 80 percent of machines running antivirus software. Kraken appears to be evading detection by a combination of clever obfuscation techniques, including regularly updating its binary code and structuring the code in such a way that hinders any static analysis, says Paul Royal, principal researcher at Damballa."
OpenPacket.org 1.0 Is Live From Richard Bejtlich's weblog comes the news that OpenPacket.org is open for business. "The mission of OpenPacket.org is to provide quality network traffic traces to researchers, analysts, and other members of the digital security community. One of the most difficult problems facing researchers, analysts, and others is understanding traffic carried by networks. At present there is no central repository of traces from which a student of network traffic could draw samples. OpenPacket.org will provide one possible solution to this problem."
Security reports Freezing More Than Bits: Chilling Effects of the OLPC XO Security Model A paper that will be presented at the USENIX Usability, Psychology and Security (UPSEC) conference takes a look at the OLPC Bitfrost security model [PDF]. "In this paper, we discuss Bitfrost, the security model developed by the One Laptop Per Child project for its XO laptop computers. Bitfrost implements a number of security measures intended primarily to deter theft and malware, but which also introduce severe threats to data security and individual privacy. We describe several of the technical provisions in Bitfrost, outline the risks they enable, and consider their legal ramifications and the psychological impact posed for children and society."
New vulnerabilities alsaplayer: arbitrary code execution
audit: privilege escalation
comix: arbitrary code execution
flash-plugin: multiple vulnerabilities
gnome-ssh-askpass, openssh: privilege escalation
konversation: arbitrary code execution
m4: execution of arbitrary code
nx nxnode: multiple vulnerabilities
otrs: SOAP command execution
pdns-recursor: DNS cache poisoning
pecl-apc: arbitrary code execution
PolicyKit: authentication bypass
silc-toolkit: buffer overflow
wireshark: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||