Re: FW: Virus alert
On Fri, 29 Aug 2003 19:30:44 CDT, David Frascone [EMAIL PROTECTED] said: 'course, I probably get 25 e-mails a day telling me that I sent someone Sobig, which would be pretty impressive, since I run Suse :) I should be so lucky. I'm averaging almost that many AV-scanner alerts bouncing to me an *hour*. And inbound Sobig-F are above 1 per minute. I still say we should have put this in the security considerations in RFC1341: If you think you know how to secure active objects in e-mail, you are probably very mistaken. There be serious and nasty dragons here. (with apologies to the authors of 'xterm'). On the other hand, maybe we didn't do THAT badly - I can only think of one vendor that really didn't pay attention pgp0.pgp Description: PGP signature
Re: FW: Virus alert
Can't we just hack the mailman configs to dump mails with X-sender value of outlook or outlook express? That would solve the problem, no;) Scott On Fri, 29 Aug 2003 [EMAIL PROTECTED] wrote: On Fri, 29 Aug 2003 19:30:44 CDT, David Frascone [EMAIL PROTECTED] said: 'course, I probably get 25 e-mails a day telling me that I sent someone Sobig, which would be pretty impressive, since I run Suse :) I should be so lucky. I'm averaging almost that many AV-scanner alerts bouncing to me an *hour*. And inbound Sobig-F are above 1 per minute. I still say we should have put this in the security considerations in RFC1341: If you think you know how to secure active objects in e-mail, you are probably very mistaken. There be serious and nasty dragons here. (with apologies to the authors of 'xterm'). On the other hand, maybe we didn't do THAT badly - I can only think of one vendor that really didn't pay attention sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: FW: Virus alert
On Thu, 28 Aug 2003 22:14:26 EDT, shogunx said: Can't we just hack the mailman configs to dump mails with X-sender value of outlook or outlook express? That would solve the problem, no;) Well, the only problem with that idea is that we explicitly do *NOT* have a Your clue must be -THIS- tall to ride the IETF list policy... ;) pgp0.pgp Description: PGP signature
Re: FW: Virus alert
I still say we should have put this in the security considerations in RFC1341: It's pretty difficult to miss the ones that are already there - which certainly would have been sufficient to stop Sobig had they been heeded.
RE: FW: Virus alert
Can't we just hack the mailman configs to dump mails with X-sender value of outlook or outlook express? That would solve the problem, no;) Well, the only problem with that idea is that we explicitly do *NOT* have a Your clue must be -THIS- tall to ride the IETF list policy... ;) The Sobig worm includes its own SMTP code, and places arbitrary values in the header fields. The source address is forged, and so are various other fields, including X-Mailer. The worm finds target source and destination addresses by reading files on the user's disk, not by using a specific Outlook or OE API. It propagates by social engineering, when users open some executable attachments. User can do click on attachments with many mailers, not just Outlook and OE. In fact, the latest versions of Outlook automatically strip such attachments. -- Christian Huitema
Criminals
User can do click on attachments with many mailers, not just Outlook and OE. Note that any mailer that does this violates the MIME specifications, which specifically warn against the presentation of content-types not known to be safe, against a mail reader implementing the ability to present arbitrary content via a content-type parameter (e.g. filename), and recommends that the most that should be done with unknown content-types is to offer to save the content to a file. The working group that produced MIME went to a lot of effort to research the hazards associated with transmission of arbitrary content by email, and to craft a series of recommendations that would minimize the harm done. One vendor in particular deliberately ignored those recommendations. It also produced mail readers that didn't properly label content on outgoing mail and ignored the content-type parameter on incoming mail, instead looking at the suffix of a nonstandard filename parameter (which was only intended for use with application/octet-stream). When I was on IESG, a program manager with that company (in charge of an email product) assured me that this decision was deliberate, as it was thought that it would maximize their company's penetration in the market. Obviously, it did serve that end, and other vendors of mail readers for that platform were forced to emulate (to some degree) the nonstandard and dangerous behavior of the market leader's products. This decision has cost the network billions of dollars, including significant costs to people who do not use that company's software products (and who therefore aren't bound by its EULAs). Words that come to mind to describe this include: Willful, Criminal, and Negligence. Another word that comes to mind: Prison. As in some people need to spend a lot of time there.
RE: FW: Virus alert
On Fri, 29 Aug 2003, Christian Huitema wrote: Can't we just hack the mailman configs to dump mails with X-sender value of outlook or outlook express? That would solve the problem, no;) Well, the only problem with that idea is that we explicitly do *NOT* have a Your clue must be -THIS- tall to ride the IETF list policy... ;) The Sobig worm includes its own SMTP code, and places arbitrary values in the header fields. You mean to say that there is a full MTA tucked away in there? The source address is forged, and so are various other fields, including X-Mailer. Perhaps you misunderstood my intentions. My intentions accociated with this post had nothing to do with the worm. The worm finds target source and destination addresses by reading files on the user's disk, not by using a specific Outlook or OE API. It propagates by social engineering, when users open some executable attachments. Since when is social engineering a desktop activity. The last time I checked, social engineering was along the lines of thank you for the shiny new job, now i'm going to hide a rouge server on your network. User can do click on attachments with many mailers, not just Outlook and OE. In fact, the latest versions of Outlook automatically strip such attachments. I'm glad I don't have to click on my mail. -- Christian Huitema sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: Criminals
Keith; MIME developers are. MIME is too much e-mail centric. Whether one use content-type or file name is irrelevant to mail security, just as whether one use uuencode or base64 is irrelevant, on both of which MIME developers wasted a lot of time. It also produced mail readers that didn't properly label content on outgoing mail and ignored the content-type parameter on incoming mail, instead looking at the suffix of a nonstandard filename parameter (which was only intended for use with application/octet-stream). On most OSes, including but not limited to UNIX, that's the way to designate content types of files. MIME should have followed the practice and IANA could be the central authority to register filename extensions with their possible security holes. Instead, MIME developers arrogantly claimed that OSes should be modified to support MIME content-type (and even that text files on OSes should use MIME format to support other tags such as charset). Rest of us righteously ignored it. Words that come to mind to describe this include: Willful, Criminal, and Negligence. Exactly. But, see above. Masataka Ohta
Re: where the indirection layer belongs
On vrijdag, aug 29, 2003, at 23:06 Europe/Amsterdam, Keith Moore wrote: It's not uncommon to see a FQDN point to several IP addresses so that the service identified by the FQDN can be provided either by (a) multiple hosts, or (b) a host with multiple addresses. No. A client can't tell whether multiple addresses associated with an DNS name indicate multiple hosts or multiple addresses for the same host. Right. And a session can't jump from one address to another either. So when we implement the latter, we also address the former. As a member of the multi6 design team that works on a (b) solution I'm convinced that such a solution will provide many benefits and should be developed and implemented. And I'm equally convinced that a solution that assumes (b) is a nonstarter. There is already too much practice that conflicts with it. To be more precise: the idea is to have transport sessions move from one address to another when there is a rehoming event. Obviously there will be changes to the process of publishing additional addresses. It would make sense to create something new that sits between the transport(s) and the application, and delegate some tasks that are done by applications today, most notably name resolution. This allows us to implement new namespaces or new address formats without any pain No it doesn't. What it allows us to do is impose subtle changes in the behavior of lower layers, and introduce new failure modes, without giving applications any way to deal with them. Well if we make a new API that allows applications to set up sessions based on FQDNs, and then later we decide that the next version of IP really needs variable length addresses where the address length in bits is a prime number, existing applications _should_ continue to work. Experience shows there are always cases where things aren't as simple as all this in practice, but I don't see how this can be worse than being 100% positive that the applications won't work and must be changed to support the new address format. But the real question here is: does this new thing have to be a layer? It depends on which thing you are talking about. New API and/or mechanisms to distribute operations over multiple hosts. For the L3-L4 thing, it's either a new layer or a change to an existing layer. Agree: both ends must cooperate, so a layer (new or modifications to an existing one) makes sense. If you have both the L4-L7 thing and the L3-L4 thing, the former is either a new layer or (my personal opinion) a new API that knowledgable apps call explicitly. Right, and API != layer.
Re: Virus alert
On Fri, Aug 29, 2003 at 07:23:29PM -0400, [EMAIL PROTECTED] wrote: On Sat, 30 Aug 2003 00:10:50 +0200, A. Kremer [EMAIL PROTECTED] said: --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19-8-2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19-8-2003 And every single copy of Sobig-F goes out with the header: X-MailScanner: Found to be clean What's wrong with this picture? Well, as the group that made MailScanner, we take the presence of that line as a great compliment by the virus writer :) Aside: MailScanner (which is open source and free) is one of few gateway spam/virus detectors that can cater for those virii that forge email From: headers so that warnings do not erroneously go back to the forged sender. See www.mailscanner.info if you're interested. Tim
Re: where the indirection layer belongs
To be more precise: the idea is to have transport sessions move from one address to another when there is a rehoming event. Obviously there will be changes to the process of publishing additional addresses. I'm also interested in ways of doing this. I just don't think it's appropriate to use FQDNs as the identifiers. Keith
Re: Criminals
On Sat, 30 Aug 2003 15:26:38 +0859, Masataka Ohta said: MIME is too much e-mail centric. For an E-mail centric protocol, it's worked pretty well on port 80 On most OSes, including but not limited to UNIX, that's the way to designate content types of files. But it's not *universally* true, so you have to come up with some sideband way of conveying information. And in fact, even if two systems both support extensions as a *mandatory* flagging, you can still run into trouble - what if the two systems don't use the *same* extension for a filetype that should be portable? Should a postscript file end in .PS, .ps, .PST? Should a VisualBasic script be .VB or .VBS? Is a image/jpeg file a .JPG or .JPEG? And if extensions are non-mandatory, it's just a mess. Think about the security implications of Here's an executable called foo.JPG (Microsoft didn't - that's the basic cause of MS03-032). Instead, MIME developers arrogantly claimed that OSes should be modified to support MIME content-type (and even that text files on OSes should use MIME format to support other tags such as charset). No. This claim is right up there with SMTP developers arrogantly claimed that OSs should be modified to support network-standard EOL. And of course they didn't. They merely insisted that the user agent at either end convert to/from the local format. pgp0.pgp Description: PGP signature
RE: FW: Virus alert
Can't we just hack the mailman configs to dump mails with X-sender value of outlook or outlook express? That would solve the problem, no;) Well, the only problem with that idea is that we explicitly do *NOT* have a Your clue must be -THIS- tall to ride the IETF list policy... ;) The Sobig worm includes its own SMTP code, and places arbitrary values in the header fields. You mean to say that there is a full MTA tucked away in there? Yes. Maybe not a full MTA, but definitely enough to format messages and execute SMTP. The common assumption is that Sobig was written by one or several criminals, with the purpose of installing a network of mail relays zombies, and then to sell the services of this network of zombies to spammers. The same SMTP agent is probably also used to send spam from the zombies. If you compare the headers of mail generated by the worm and those of random spam, you will find that they are very similar. There is another link between Sobig and spam. It appears that these networks of zombies are used in denial of service attacks against anti-spam services. By the way, the worm does not only include its own SMTP service. It seems to also include its own DNS code, probably in order to get the MX records of its targets. This DNS agent is parameterized to start any look-up at the A-root, with the side effect of overloading this root server. -- Christian Huitema
Re: FW: Virus alert
Christian Huitema wrote: By the way, the worm does not only include its own SMTP service. It seems to also include its own DNS code, probably in order to get the MX records of its targets. This DNS agent is parameterized to start any look-up at the A-root, with the side effect of overloading this root server. Does this mean we can stop the virus and associated spam just by switching off the A root? -zefram
RE: FW: Virus alert
By the way, the worm does not only include its own SMTP service. It seems to also include its own DNS code, probably in order to get the MX records of its targets. This DNS agent is parameterized to start any look-up at the A-root, with the side effect of overloading this root server. Does this mean we can stop the virus and associated spam just by switching off the A root? I would suggest that you engage in serious testing before trying anything like that! -- Christian Huitema
RE: FW: Virus alert
From: Christian Huitema [EMAIL PROTECTED] ... Yes. Maybe not a full MTA, but definitely enough to format messages and execute SMTP. ... What do you mean by execute SMTP? Does it interpret and respond to SMTP response codes to its SMTP commands or just open a TCP connection and send a largely constant handful of lines of text before the first header line? The samples I've captured have pretty rudimentary SMTP envelopes. ... By the way, the worm does not only include its own SMTP service. It seems to also include its own DNS code, probably in order to get the MX records of its targets. ... That would be far more impresssive, although given the many resolver libraries available, nothing to write home about. Vernon Schryver[EMAIL PROTECTED]
Testing Root A going away
Didn't J Postel run a test similar to that once G... On a side note, how would you go about testing something like this ? What would be considered pass/fail metrics - well written applications vs. people doing silly and stupid things (ie. Would it be consisdered a failrue that sobig fails because it was incorrectly written ?) Bill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christian Huitema Sent: Saturday, August 30, 2003 11:13 AM To: Zefram; [EMAIL PROTECTED] Subject: RE: FW: Virus alert By the way, the worm does not only include its own SMTP service. It seems to also include its own DNS code, probably in order to get the MX records of its targets. This DNS agent is parameterized to start any look-up at the A-root, with the side effect of overloading this root server. Does this mean we can stop the virus and associated spam just by switching off the A root? I would suggest that you engage in serious testing before trying anything like that! -- Christian Huitema
RE: Testing Root A going away
Didn't J Postel run a test similar to that once G... On a side note, how would you go about testing something like this ? Obviously, cutting of the A root would have some pretty drastic consequences. On the other hand, there are many computers that have no business contacting directly the root servers. For example, in many enterprises and campuses, computers are suppose to send their DNS traffic to a configured relay. What would be considered pass/fail metrics - well written applications vs. people doing silly and stupid things (ie. Would it be consisdered a failrue that sobig fails because it was incorrectly written ?) Looking at bugs in worms and using these bugs to squash the worms is fair game. Another known bug is the SMTP Hello line always contains a single token host name, instead of an FQDN. However, it is very likely that such bugs will be corrected in a next release -- say, Sobig.G. The better question for the IETF is whether we should do something to SMTP to make it less easy to send spoofed mail. -- Christian Huitema
RE: Testing Root A going away
The better question for the IETF is whether we should do something to SMTP to make it less easy to send spoofed mail. what, so one couldn't telnet in and send arbitrary mail? include a reversedns lookup in SMTP? good luck on widespread implementation. -- Christian Huitema sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
Re: Testing Root A going away
On zaterdag, aug 30, 2003, at 21:28 Europe/Amsterdam, Christian Huitema wrote: Obviously, cutting of the A root would have some pretty drastic consequences. If that is the case then some people have been reading the relevant RFCs with their eyes closed. The only consequence should some sporadic short delays when a resolver asks the A but there is no answer so there is a timeout and one of the other root servers must be consulted. On the other hand, there are many computers that have no business contacting directly the root servers. For example, in many enterprises and campuses, computers are suppose to send their DNS traffic to a configured relay. How would that make a difference, other than that a central resolver can cache more efficiently? If a host needs a domain in a not-yet-cached TLD resolved, then someone somewhere has to ask one of the root servers for the information about this TLD, whether this is the host that needs the information or some other system working on behalf of this host. The better question for the IETF is whether we should do something to SMTP to make it less easy to send spoofed mail. Well, draft-fecyk-dsprotocol-04.txt is in the RFC editor queue and this seems like a fair step in the good direction, without heaving read it in detail. So unless this is no good it should be shipped as and RFC and then the ball is in the vendors' court.
RE: Testing Root A going away
On Sat, 30 Aug 2003, Christian Huitema wrote: [snip] Obviously, cutting of the A root would have some pretty drastic consequences. On the other hand, there are many computers that have no business contacting directly the root servers. For example, in many enterprises and campuses, computers are suppose to send their DNS traffic to a configured relay. not realy. If 'A' stops answering you'll just ask questions of the others. The issue is not if 'A' goes off the air, there are always other servers to talk to. -rick
Re: FW: Virus alert
On Fri, 29 Aug 2003, David Frascone wrote: With the current virii usually forging the from field with random addresses from its victim's address book, I turned off my virus scanner's warning to the senders . . I only send a polite note to the intended recipient. Don't do that. That is quite likely what the Virus writer wants you to do: Stop notifying people about infections. The worst that happens is that people get notifications, and update their anti-virus, which finds nothing. The best that happens is that the headers included in such a notification reveal the IP address of an infected zombie. Also, in the current cases, I don't think the addresses aren't taken from address books. I'm getting responses to addresses that haven't been used for email and addresses that haven't been used in years. Certainly, these aren't in anyone's address book. In one case, the address is on a little used web site (but even spammers rarely spam it, and in another, its in a reasonably public area, but not used) The Virus writer obviously went to some trouble to pick valid addresses. It stands to reason that they expect that someone is getting mail to these addresses. It also stands to reason that the abuser expects those persons to get Virus notifications. Most probably, virus notifications tend to frustrate the purposes of the Virus operator, since the infected will not stay infected. It seems possible that the virus operators are trying to manipulate people to stop sending or responding to virus notifications. In past cases, the forged from address was the target of the abuse: the abuser hoped to have people block mail with the common from address, thus getting some measure of revenge on that person. Most people have filtering on From: addresses for this reason. The best thing to do in response to such an attack is to do things that frustrate purposes the abuser, catch the abuser, or nothing at all. Never succumb to what might be a desired manipulation--That only encourages more abuse. --Dean
Re: FW: Virus alert
On Sat, 30 Aug 2003, Dean Anderson wrote: How beautiful to be immune behind an open-source kernel;) The rest of the world worries. I eat a sandwich. Scott On Fri, 29 Aug 2003, David Frascone wrote: With the current virii usually forging the from field with random addresses from its victim's address book, I turned off my virus scanner's warning to the senders . . I only send a polite note to the intended recipient. Don't do that. That is quite likely what the Virus writer wants you to do: Stop notifying people about infections. The worst that happens is that people get notifications, and update their anti-virus, which finds nothing. The best that happens is that the headers included in such a notification reveal the IP address of an infected zombie. Also, in the current cases, I don't think the addresses aren't taken from address books. I'm getting responses to addresses that haven't been used for email and addresses that haven't been used in years. Certainly, these aren't in anyone's address book. In one case, the address is on a little used web site (but even spammers rarely spam it, and in another, its in a reasonably public area, but not used) The Virus writer obviously went to some trouble to pick valid addresses. It stands to reason that they expect that someone is getting mail to these addresses. It also stands to reason that the abuser expects those persons to get Virus notifications. Most probably, virus notifications tend to frustrate the purposes of the Virus operator, since the infected will not stay infected. It seems possible that the virus operators are trying to manipulate people to stop sending or responding to virus notifications. In past cases, the forged from address was the target of the abuse: the abuser hoped to have people block mail with the common from address, thus getting some measure of revenge on that person. Most people have filtering on From: addresses for this reason. The best thing to do in response to such an attack is to do things that frustrate purposes the abuser, catch the abuser, or nothing at all. Never succumb to what might be a desired manipulation--That only encourages more abuse. --Dean sleekfreak pirate broadcast world tour 2002-3 live from the pirate hideout http://sleekfreak.ath.cx:81/
RE: Testing Root A going away
On Fri, 29 Aug 2003, shogunx wrote: The better question for the IETF is whether we should do something to SMTP to make it less easy to send spoofed mail. what, so one couldn't telnet in and send arbitrary mail? include a reversedns lookup in SMTP? good luck on widespread implementation. Reverse DNS lookups tell one nothing about the legitimacy of the email being sent. This has been hashed over on both namedroppers and DNSOP. I also recently hashed out the Information Theoretic problems with suppressing spam with a group of PhDs from one of my old companies. After a great deal of arguing about the definition of Covert Channel (in particular whether cooperation was required or not), it was determined (to a high degree of confidence--but not to a formal proof) that spam is indeed a covert channel, and therefore subject to the axiom that one cannot prove there are no covert channels. I should note that during the course of research I made to on the topic, which included reading a number of original papers on the subject of Covert Channels, Side Channels, and like concepts, I could find no written proof of this axiom, but neither was it challenged as being untrue. This confirms the intuition that digital signature schemes, and cost schemes and other such suppression schemes cannot succeed. Spam is essentially dependent on the will of the sender, and given viruses, that will can be subverted for many senders no matter what suppression scheme is used. Spam can be detected, and stopped after detection, but it cannot be made impossible to send. The question is really whether SMTP has sufficient identification information to track down an abuser, or infected user. The answer to this question is yes. Even with an open proxy, the SMTP information will identify the open proxy. The anonymity offered by the open proxy is completely independent of SMTP. However, to identify the abuser, one may need law enforcement authority, or be willing to undertake a civil action at some expense. This is consistent with the PSTN, in which the identify of a user can't generally be determined by another end user, but can usually be determined using law enforcement authority. Indeed, as with the PSTN, some anonymity is appropriate. One would probably not want to allow end users to be able to identify another end user against their will without a court order of some sort or some evidence of a criminal act. --Dean
Re: FW: Virus alert
Open source kernels aren't immune. They just aren't at focus this time. Have fun with the sandwich. ;-) --Dean On Fri, 29 Aug 2003, shogunx wrote: On Sat, 30 Aug 2003, Dean Anderson wrote: How beautiful to be immune behind an open-source kernel;) The rest of the world worries. I eat a sandwich. Scott
Re: Solving the right problems ...
On Wednesday, August 27, 2003, at 01:25 PM, Iljitsch van Beijnum wrote: On woensdag, aug 27, 2003, at 18:48 Europe/Amsterdam, Tony Hain wrote: but if that only applied to apps using a new stabilization layer, there wouldn't be as much complaint because those would see a clear benefit. So when will vendors recompile their apps for multihoming? Right after they're done recompiling them for IPv6? It might be useful to start thinking about what we can do in the long term if we don't care about supporting existing applications, but this won't solve any of today's or tomorrow's problems. Well since a lot of people are still looking for a good reason to move to IPv6, and this might be one of them ... simon -- simonwoodside.com -- openict.net -- 99% Devil, 1% Angel
