Bug 2269 - AWL should igbnore 192.168.*.* and 10.* reserved (internal) nets
Summary: AWL should igbnore 192.168.*.* and 10.* reserved (internal) nets
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Learner (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All All
: P3 normal
Target Milestone: 2.60
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-07-28 12:25 UTC by Vicki Brown
Modified: 2003-07-30 15:34 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
fix for this bug patch None Justin Mason [HasCLA]
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Vicki Brown 2003-07-28 12:25:34 UTC 
We have been receiving Spam which AWL is marking as OK. For example, the mail from which this 
set of headers was clipped should have had a spam score of 8.333; instead it had a score of -6.3. 
The only thing I see that can account for the lower score is AWL which is not a "rule" for which a 
simple "score" can be modified.

  X-Spam-Status: No, hits=-6.3 required=2.3
	tests=AWL,BIG_FONT,FROM_AND_TO_SAME_5,HTML_FONT_COLOR_RED,
	      HTTP_USERNAME_USED,LARGE_COLLECTION,SPAM_PHRASE_05_08,
	      WEB_BUGS
	version=2.43
  X-Spam-Level:

score BIG_FONT                              0.335
score FROM_AND_TO_SAME_5        1.314
score HTML_FONT_COLOR_RED       0.315
score HTTP_USERNAME_USED         1.526
score LARGE_COLLECTION              0.203
score SPAM_PHRASE_05_08            1.640
score WEB_BUGS                             3			# set higher in my user_prefs


At 23:07 -0700 2003-07-27, Justin Mason wrote:
>The AWL in this case, works on the From addr and the top 2 octets of the
>sending IP (or at least the very earliest IP in the Received lines).
>Could the spammer have added a forged Received line containing your
>IP address?  What do the Received lines look like?  

This is, apparently, exactly what is happening:

Received: from cfcl.com ([211.97.79.169])
	by cfcl.com (8.12.6/8.11.1) with ESMTP id h6R4mhj3075754
	for <vlb@cfcl.com>; Sat, 26 Jul 2003 21:48:44 -0700 (PDT)
	(envelope-from vlb@cfcl.com)
Received: from server [192.168.1.1] by cfcl.com with MailMXPro(2195.5532);
	Sun, 27 Jul 2003 12:48:48 +0800

Another one I got had similar headers

Received: from cfcl.com (ANice-204-1-5-22.w81-51.abo.wanadoo.fr [81.51.142.22])
	by cfcl.com (8.12.6/8.11.1) with ESMTP id h6R2t1j3072647
	for <vlb@cfcl.com>; Sat, 26 Jul 2003 19:55:08 -0700 (PDT)
	(envelope-from vlb@cfcl.com)
Received: from crazyman [192.168.0.100] by cfcl.com with MailMXPro(2195.5503);
	dim., 27 juil 2003 04:50:29 +0200


Unfortunately, 192.168.*.* is specifically an internal IP address; it's not a possible IP address on 
the Internet. If they are spoofing the 192.168 net (or the 10.net) that would look internal.

The external IP address for cfcl is 24.221.172.174. Our internal addresses (NAT addresses) are all 
192.168.254.2* . But if SpamAssassin is only looking at the top two octets (it really should look at 
the top three; that's a class C) then 192.168.0.100 and 192.168.1.1 are going to _appear_ "local" 
to SA, regardless of "true" origin.

Anyone running a NAT is going to be on (some portion of) either the 192.168.*.* net or the 10.* 
net. Checking these nets doesn't assure local origin. Worse, spammers using (or spoofing) those 
addresses will look "internal" tothe current AWL for a _lot_ of LANs... 

Ouch.
Comment 1 Theo Van Dinter 2003-07-28 12:36:57 UTC 
2.43 is an ancient release.  2.55 has been out for a while, and 2.60 is coming out soon.

if you can reproduce this issue with either 2.55 or 2.60, we can reopen the ticket.
Comment 2 Justin Mason 2003-07-28 12:57:32 UTC 
Theo, I'm pretty sure CVS is still vulnerable -- the code looks like this:

    my $rcvd = $self->get('Received');
    my $origip;

    if ($rcvd =~ /^.*[^\d](\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/s) {
      $origip = $1;
    } elsif (defined $rcvd && $rcvd =~ /\S/) {
      $rcvd =~ s/\s+/ /gs;
      dbg ("failed to find originating IP in '$rcvd'");
    }

ie. it takes the very last IP found in the Received headers, regardless of
whether it is reserved or not.  I've just tested it and yes, it's still active
in CVS.

mind you, Vicki, 2.55 would definitely be recommended anyway for other
reasons.
Comment 3 Justin Mason 2003-07-28 12:57:41 UTC 
Theo, I'm pretty sure CVS is still vulnerable -- the code looks like this:

    my $rcvd = $self->get('Received');
    my $origip;

    if ($rcvd =~ /^.*[^\d](\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})/s) {
      $origip = $1;
    } elsif (defined $rcvd && $rcvd =~ /\S/) {
      $rcvd =~ s/\s+/ /gs;
      dbg ("failed to find originating IP in '$rcvd'");
    }

ie. it takes the very last IP found in the Received headers, regardless of
whether it is reserved or not.  I've just tested it and yes, it's still active
in CVS.

mind you, Vicki, 2.55 would definitely be recommended anyway for other
reasons.
Comment 4 Vicki Brown 2003-07-28 13:03:59 UTC 
How difficult can it be for someone on the project to LOOK at SA to see if AWL is still considering 
192.168.* as 'internal"?

I suppose, given that this is Open Source, I should feel "honored" to be asked to reprodice the 
problem, but my primary concern is to not get Spam. I've turned off auto-whitelisting.  I'm gone.

I have no problem with downloading and upgrading to the newest version, but I'm not going to sit 
around waiting for "jenny bear" to send me more X-rated email.  This issue doesn't need 
"reproducing" ... all it takes is a look at the code. Someone _on the project team_ ahould be able to 
do that.

sigh.

Open Source projects... grumble... sometimes I wonder why I support the idea... :(
Comment 5 Theo Van Dinter 2003-07-28 13:46:44 UTC 
Subject: Re: [SAdev]  AWL should igbnore 192.168.*.* and 10.* reserved (internal) nets

On Mon, Jul 28, 2003 at 01:08:04PM -0700, bugzilla-daemon@bugzilla.spamassassin.org wrote:
> How difficult can it be for someone on the project to LOOK at SA to see if AWL is still considering 
> 192.168.* as 'internal"?

Because I have better things to do with my time then see if a bug that
was in an old version of code could still be in the current version?
Comment 6 Daniel Quinlan 2003-07-28 14:27:20 UTC 
p> How difficult can it be for someone on the project to LOOK at SA to see if
> AWL is still considering 192.168.* as 'internal"?

It's not a question of difficulty, but of time.  There are only a few people
actively working on the code and Theo is one of them.  We have literally
hundreds of minor bugs and enhancement requests and yours is but one of them.

It is more efficient and, we believe, not too much to ask users to do a little
legwork.  You are under no obligation to do so, but we make the same request of
everyone and bugs with more information will get fixed first because we can
improve SA the fastest this way.  Most people have no problem with it either
(if most people responded the way you have, I'd probably go back to being a
system administrator when the only angry users I ever had to deal with at least
worked at the same company).

> I suppose, given that this is Open Source, I should feel "honored" to be asked
> to reprodice the problem, but my primary concern is to not get Spam. I've
> turned off auto-whitelisting.  I'm gone.

We weren't trying to bestow some honor, just get work done and make SA better.

> I have no problem with downloading and upgrading to the newest version, but
> I'm not going to sit  around waiting for "jenny bear" to send me more X-rated
> email.  This issue doesn't need "reproducing" ... all it takes is a look at
> the code. Someone _on the project team_ ahould be able to do that.

This is true, but we don't have a QA team.  We have a few developers and way
more bugs than we have time.  Users are our QA team and that's why open source
works.  Do you think you could actually get a closed-source company to fix your
bug?

> sigh.
>
> Open Source projects... grumble... sometimes I wonder why I support the
> idea... :(

I could really do without the sarcasm and attitude.  What did we do to deserve
such derision from you?
Comment 7 Daniel Quinlan 2003-07-28 14:36:20 UTC 
Talked to Justin... looks like we should fix this in 2.60 if possible due
to the vulnerability.  We can fix this anytime before release.  I am
assigning this a 2.60 milestone, shift to 2.61 if 2.60 is finished first.
Comment 8 Justin Mason 2003-07-29 20:07:15 UTC 
Created attachment 1193 [details]
fix for this bug

here's the fix -- it now uses the relays_trusted and relays_untrusted stuff.
Comment 9 Theo Van Dinter 2003-07-29 20:11:13 UTC 
+1 looks good to me. :)
Comment 10 Justin Mason 2003-07-30 23:34:03 UTC 
ok, applied...