First note: ISP mailbox overflow due to Sobig.F knocked me off a few Debian lists, I've just resubscribed. I've got a partial copy of this thread thanks to a friend who forwarded it to me. I've also been following the discussion in the d-d archives and BTS.
Thanks to all who've commented on this topic. Interesting reading. Adam: my email is [EMAIL PROTECTED] I've set the $EMAIL environment variable 'bug' uses. General response to those who've suggested that general distaste for software is sufficient cause for a grave bug filing. Specious. The current response is on mark: behaviour which doesn't maliciously affect other users or third parties should be exempted. _Bugs_ which can be exploited to do same would be grounds. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03635.html General response to those noting that there is software which _can_ be configured in such a way that users shoot themselves or others in the foot. A configuration concern, but not necessarily a bug. If this isn't a design intent, or isn't a default configuration, then a grave bug is unwarranted. Warning documentation, or an "important" debconf screen requiring input along the lines of "Yes, I understand that this setting may cause grave harm and accept full responsibility" might be (and probably is) appropriate. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03637.html General response to those who claim that user interest is sufficient to include a package in Debian. Above and beyond comments by Joey Hess, there is this to consider: including a package in Debian both offers the support and infrastructure Debian, SPI, and various sponsoring organizations provide, _and_ puts these entities at risk for malfeasance which may be conducted, intentionally or otherwise, as a result of this package. Which is a damned good reason for Debian not to package viruses and spam mailers. Or tools which can be readily subverted as such. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03680.html on Wed, Aug 27, 2003 at 01:34:53PM -0700, Adam McKenna ([EMAIL PROTECTED]) wrote: > On Wed, Aug 27, 2003 at 07:49:27PM +0100, Colin Watson wrote: > > On Wed, Aug 27, 2003 at 12:30:07PM -0400, Joey Hess wrote: > > > Adam McKenna wrote: > > > > The arguments are facile and specious, I do not intend to waste my > > > > precious time responding to them. > > > > That's a shame. I don't believe Karsten to be in the habit of putting > > forward specious arguments. > > Well, let's see, I'll try to be brief: An admission: the "Considered Harmful" essay is a general argument against C-R systems, not specifically TMDA. TMDA does share some, though not all faults. Not all of these should be considered grave. Some are. > #0, #1, #2 and #11 are basically opinion and rhetoric. Karsten has > stated that he has a 'religious' objection to CR, and I'm not willing > to have a debate about it. I've already noted some of the places that > Karsten can go if he wants a debate. #0 (Weak verification) is a statement of established fact: SMTP headers are readily forged, as is adequately discussed in this thread. #1 (Mistaken interpretation) is a statement of opinion, but weighs strongly on other factors, in particular #2 and #4. #2, I'll get back to. #11 (techno-economic underpinnings) is largely irrelevant to the current discussion, though it weighs on the merits of pain and harm created through C-R systems, relative to the benefits, and existence of currently feasible alternatives. > #3 blames CR for actions taken by an ISP (IOW, user configuration error). (Privacy violation) Subpoenability or other data leakage of personal communications data which is enabled by virtue of a systems design (C-R's requirement that a whitelist be maintained online or nearline at the SMTP server for proper operation) is a risk in both the United States and other countries under current legal doctrine. While not a grave bug, it warrants a warning in documentation. Better would be a requirement to notify users in an ISP situation of this risk, though I'm not sure this can be mandated under DFSG software licenses. For a related issue of security and logs, see: http://cryptome.org/no-logs.htm In a broader sense, for "configuration errors" which are made by a large class of users, blame cannot be laid entirely on them. There was a tradition in the early industrial age to blame "accidents" -- as acts of God -- either on, well, God (He didn't seem to mind) or workers. This until principles of scientific management (Taylorism) and statistical process control were developed, and it could be shown that accident rates in different situations varied wildly. Bog-obvious now, but a big leap at the time. Today, a major issue in computer security and administration are the plague of ills launched forth from Microsoft platforms. We've seen the Internet brought to its knees three times this year, twice in a week. And the blame is on users who don't install security updates (and related EULA changes and spyware), and on virus writers who exploit the capabilities so generously laid before them. I don't buy it. Don't blame your users for not being able to avoid harmful configuration settings. Design so that they can't (at least not without major effort). > #4 claims that CR is less effective without giving any empirical data > to back up that claim. (Less effective) Irrelevant to the current discussion though highly relevant to the ultimate effectiveness of C-R. Note thought that C-R filtering is inherently based on a component which cannot be accommodated in software: the human response to the challenge mailing. I've also posted efficacy and accuracy statistics based on my own SpamAssassin + whitelist system, and there are statistics available from third parties. This system is _insensitive_ to the respons(es) of my correspondents. Because of the human interaction component of C-R filtering, a true test cannot be run in a lab but must take into account responses from the population at large. This makes accurate measurement difficult. Anecdotal evidence among at least a class of users to include members of debian-devel, debian-user, and the Kuro5hin readership shows a marked antipathy toward C-R challenges in general. I'll also note that responses from C-R proponents in this regard vary from transrational, to denial, to (occasionally) acknowledgement. For a typical response among recent communications I've had, see: http://lists.debian.org/debian-user/2003/debian-user-200308/msg00431.html Particularly note: "I don't see this point." "I don't see the third party." "I don't know anything about this." > #5 claims a high false positive rate without giving any empirical data to > back up that claim. (type II error) See above. Of course, I'd welcome contradicting evidence in an independent non-lab trial as specified above. > #6 singles out CR for a DOS attack that all autoresponders and > vacation programs, as well as some MTA's are vulnerable to. In > addition, the effect of such an attack would still identify the > original sending machine through the headers of the quoted message, so > it would basically be equivalent to mailbombing someone from your own > machine. (Joe-job) The behavior is wrong, regardless of how many other software packages exhibit it. C-R's potential mass-market popularity makes it a potent threat. The traditional Unix vacation program, as configured by default, sends a single message in a 30 day period, per destination user. Typically it's used with filter rules to respond only to personal mail. Experience with popular consumer-grade equivalents is frankly depressing (and was noted in the earlier d-u thread). Reading the tmda-user mailing list archive from March of this year, we find a message from Jason Mastaler (TMDA's developer): TMDA will send no more than 50 auto-responses (configurable) to the same address in one day. http://mla.libertine.org/tmda-users/2003-03/msg00019.html That's about 49 too many for a month. One suggested remedy is to configure maximum messages to 1 per month. > #7 does not apply to TMDA (Deadlock) Granted. > #8 does not really make any sense at all. It seems like he is saying that > spammers might start to send out fake confirmation requests in order to > harvest e-mail addresses. This seems far-fetched at best. (integration into spam email harvest) This factors into the social perception of C-R systems in general, and will likely diminish the utility of such systems if C-R grows in popularity, and as it is co-opted by spammers. This isn't a bug of itself but should be noted in user warnings. > #9 just sounds like a threat. (C-R messages blacklisted/spamfiltered) It's practice among several people I've communicated with. Specific to my own experience: over half the C-R challenges (TMDA or otherwise) I've received have been for mail I didn't send. I expect this trend to increase in both magnitude and percentage. I'm likely to either ignore messages or filter them with other spam. For an indication of how bad this gets with current email trends, for which I'll freely admit I'm guestimating wildly, though values are within estimates I can find: - 600m valid human email addresses worldwide (personal conversation, Dan Quinlan of SpamAssassin). - Spam ~40% of email (widely reported statistic) - Dorman AOL account receives 25 spams/day (http://www.tesp.com/UBETotalRate.htm) - Daily mail load = 60 messages (25 spam, 35 ham). - 7 trillion emails delivered annually. This is within range of various estimates I've found http://www.cisco.com/warp/public/779/govtaffs/factsNStats/internetusage.html Let's further suppose that all C-R systems have 1% penetration. That is, there are 6m C-R users worldwide. Each receives an average of 25 spams, with spoofed headers, daily. Each sends 35 challenge requests. A total of 150m challenge requests are mailed daily. Assuming an even distribution of spoofed headers, I will see a challenge request for mail I didn't send, on average, once every 4 days. By contrast, I might see a valid request once a month or so. Adjust values up or down as you like. C-R rapidly becomes a nuisance, and moreso as it becomes more popular. As with the boy who cried wolf, a rapid value deflation sets in with overuse. Requests that all other users fix their systems to accommodate C-R users (say, by tracking and matching outgoing mail with inbound C-R requests) are specious, not to mention ill-formed in a world where I might mail you from my cell phone, respond from my PC, drop a note from my PDA, and follow up with a machine-generated message from a webserver. Again, this affects the social component of C-R, in ways that cannot be programmatically compensated. > #10 blames CR for user configuration errors (failing to set up a proper > whitelist) (Mailing list) See response to #3. If one searches assiduously, it's possible that an example of this behavior might even be found. #2, Misplaced burden, is the reason for the 'grave' severity. At best, C-R systems, TMDA included, take the viewpoint that the sender, not the recipient, is best placed to judge the worthiness of a particular communication. Regardless of trust relationships this implies, the situation works only if the request isn't sent to an innocent third party. I checked my email stats earlier this evening. Between 19 and 25 August, I received 134 responses of various nature to Sobig.F mails I most assuredly did not send. Over the same period, my sent folder lists 65 messages. That is, for this time period, mails falsely claiming to be mine outnumbered those which genuinely are mine by more than a factor of two. The assumption that an emails headers accurately represents its true sender is demonstrably false for this period. It's even probabilistically unlikely, with a predictive value of 0.35. Granting that this is an unusual timespan, even during "normal" periods of late, I'm receiving a number of spoofed responses weekly. While I'm not familiar with TMDA's configuration, it appears that it is not uncommon to configure it such that it challenges Sobig.F viral mails. As with many such viruses, this spoofs sender. One such instance is documented on the tmda-users list: Welcome to Spamcop! Lou Hevly <[EMAIL PROTECTED]> Tue, 26 Aug 2003 03:25:04 +0100 http://mla.libertine.org/tmda-users/2003-08/msg00171.html The Spamcop report shows that Lou was reported not once, but twice. Presumably he challenged more than two Sobig.F mails, though we don't know how many there were. http://spamcop.net/w3m?action=checkblock&ip=216.216.32.170 This seems to me to be a legitimate Spamcop filing. The response of Jason Mastaler is "SpamCop is way too trigger-happy". http://mla.libertine.org/tmda-users/2003-08/msg00172.html More chillingly, other users post Sobig.F stats: TMDA and Sobig.F virus - praise Sven Neuhaus <[EMAIL PROTECTED]> Thu, 21 Aug 2003 17:04:09 +0200 http://mla.libertine.org/tmda-users/2003-08/msg00120.html In the last 3 days, I received more than 4000 copies of the Sobig.F virus. Thanks to TMDA, I didn't even notice it until today (when I noticed the 330megs in my pending folder). That's 4,000 innocent parties spammed with C-R challenges, if I'm interpreting what the meaning of 330 MiB in the pending folder is. For a worse-case scenario, a friend reports that a major California research university tracked over 500,000 copies of Sobig.F through Friday evening last week, not uncommon for a large installation. Had even a small fraction of these resulted in C-R challenges, the entire campus could have found itself untangling spam blocks for weeks. As the count occurred in mid-August, with most functions shut down, it would likely have been many times worse during the school year. This is an unacceptable level of collateral damage. Even if it is largely hypothetical, it is entirely foreseeable. The fallout on the Debian project, SPI, sponsors, and hosting providers would likely be most unpleasant. It is for this reason that I will be re-escalating severity for this bug to 'grave', based on the following definition from the BTS: 3) Dangerous bug. Makes the package in question unusable by anyone or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. The unauthorized access is to system mail services, in a manner that is externally testable (for intentional exploit) or foreseeable unintentional access when the next Microsoft email virus strikes. This situation isn't beyond mitigation. Adam indicates that TMDA ships by default with C-R disabled. This is a mild benefit, though I suspect that among the core reasons TMDA is installed is for its touted C-R functionality. The problem of false challenges (challenges sent to spoofed headers) is non-trivial. It's largely this problem that C-R serves to solve: the premise of C-R is that if an email address is deliverable and a human responds, the address is valid. So solving the "is this a valid address to test" problem is to an extent reflexive. As an example, my own address is "kmself@ix.netcom.com". My MTA is guildenstern.dyndns.org. The netblock this emerges from is an NTL cable line located in the UK. I myself am on the west coast of the USA. This is my current "correct" mail setup. The problem can be mitigated. The question is whether or not this mitigation is sufficient: - TMDA can be seeded with whitelisted domains and addresses. As pointed out, this isn't without its own problems. See: http://lists.debian.org/debian-devel/2003/debian-devel-200308/msg03750.html - Virus mails can be filtered out. This eliminates a large percentage of the spoofed headers. clamav is the only DFSG free scanner I find for Debian, though there are proprietary alternatives. - Spam messages above a reasonable threshold can be filtered out. This then leaves a small number of messages daily to be assessed -- they are not viruses, spam, or on an existing whitelist. My question at this point is: why not simply look at the damned mail and figure out for yourself whether or not it's worth reading? We're probably talking something like a couple of items, a few times a week. However, if we want to consider C-R, let's set some guidelines. A goal would be no challenges to spoofed mails. Given that this is nontrivial, we could accept a small number of false positives. SpamAssassin achieves a false-positive rate (non-spam reported as spam) of 5% with a default threshold of 5. This can be dramatically improved using a whitelist, to ~98% in my experience. This is not the best performance of all filters, so makes a somewhat generous threshold. http://www.spamassassin.org/dist/rules/STATISTICS.txt http://freshmeat.net/articles/view/964/ So a spam-reduction system user would at worst see a typical rate of 2% of spam to be manually disposed of. Should this then be an acceptable cutoff of spoof challenges -- no more than 2% of challenges be spoofed? In my response to #4 I showed that I could expect an unnecessary C-R challenge every four days. The 2% threshold would reduce this to once every 200 days, about 6.5 months. This might be tolerable. Remedies: My suggested remedies are as follows: - TMDA should be configured, by default, with C-R disabled. This appears to be the case currently. - TMDA should carry a warning to the user about possible consequences of activating the C-R mechanism, including sending spam, risking blacklisting or registration in spam-reduction services such as SpamCop, and a likelihood that some, and perhaps a majority of challenges will not be responded to. The warning should require the user to assume full responsibility for doing so. - Challenges should only be sent as a last resort. - Configuration templates for C-R challenges _must_ incorporate virus and spam filtering, _prior_ to issuing a C-R challenge. Preferably, tests against obvious header spoofing, if possible, should be performed. Debian tmda packages _must_ depend on corresponding spam and virus filters, if this functionality isn't built into TMDA. - Additional strong validation mechanisms, including RFC 2015 PGP signed mail and S/MIME signatures, _must_ be used to validate sender, including use of web of trust to identify a reasonable probability of trusted user status. - If possible, TMDA should be moved to SMTP-time filtering, so that mail rejection occurs at SMTP time. As SMTP doesn't offer a protocol for challenge-response, this introduces interesting challenges for TMDA's developers. - TMDA's performance _must_ be independently validated and the target maximum of 2% challenges to spoofed addresses be confirmed. I'm not going to pretend that these are easy fixes. I'm not a user of this package. I _am_ negatively impacted by it, however, and if it continues to display similarly poor consideration of security, abuse, and adverse side effects, I fear for Debian, SPI, and the generosity of our sponsors. I do feel the remedies are necessary and advised. They should be communicated upstream, naturally. Peace. -- Karsten M. Self <kmself@ix.netcom.com> http://kmself.home.netcom.com/ What Part of "Gestalt" don't you understand? Data corrupts. Absolute data corrupts absolutely. -- Ed Self's corollary of Atkinson's Law.
pgpCCRdJIBBuc.pgp
Description: PGP signature
