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 kmself@ix.netcom.com. 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 (adam@flounder.net) 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 <soc@visca.com>
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 <sn@heise.de>
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.
Attachment:
pgpQ088wQaHvs.pgp
Description: PGP signature