You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2005/07/01 05:25:48 UTC
[Bug 4445] New: Insecure dependency .. .SpamAssassin/PerMsgStatus.pm line 2119
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
Summary: Insecure dependency .. .SpamAssassin/PerMsgStatus.pm
line 2119
Product: Spamassassin
Version: 3.0.4
Platform: PC
OS/Version: Linux
Status: NEW
Severity: major
Priority: P5
Component: spamc/spamd
AssignedTo: dev@spamassassin.apache.org
ReportedBy: jdow@earthlink.net
error: Insecure dependency in eval while running setuid at
/usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/PerMsgStatus.pm line 2119._
, continuing
Ayup - another one of those horrid problems.
I am running 3.04 with spamd and spamc. I get this on "full" rules.
However, I do not get it all the time. I get it when email traffic
cues up several messages at once. I am running with spamd options
"-d -c -m5 -Hi -A 192.168.XX.,127. --max-conn-per-child=15". I am
running with per user rules enabled:
===8<---
# This is the right place to customize your installation of SpamAssassin.
#
# See 'perldoc Mail::SpamAssassin::Conf' for details of what can be
# tweaked.
#
###########################################################################
#
rewrite_header Subject *****SPAM***** _SCORE(00)_ **
# report_safe 1
clear_trusted_networks
# trusted_networks 212.17.35.
trusted_networks 192.168.XX/24 127/8 207.217.121/24
internal_networks 192.168.xx/24
# lock_method flock
use_auto_whitelist 0
#dns_available yes
dns_available test: wizardess.wiz
bayes_auto_learn 0
bayes_auto_expire 0
bayes_auto_learn_threshold_spam 20.0
bayes_auto_learn_threshold_nonspam 0.1
allow_user_rules 1
===8<---
There is a local dns available.
I developed a trap for the problem in procmail. My .procmailrc includes
this recipe (or something relatively close.):
:0 fw
* ^X-NTRACK: Before SA
{
:0 fw
* !^X-Spam-Checker-Version:
{
:0 fw
| nice -n 1 /usr/bin/spamassassin
# :0 fw
# | Formail -A "X-JdowMissed: SpamAssassin checks bombed first time.
:0 fw
| sed -e 's/Subject:/Subject: [ZZ Missed]/'
}
}
I find that the rule results in markups on both spam and ham. It is
marked in such a manner as to make alphabetical searches in
OutlookDepress quite asy at the moment. This is how I can trace the
underlying problem hitting both ham and spam.
"grep PerMsgStatus.pm /var/log/mail/info" shows that only line 2119
is hitting. Removing all my user_prefs "full" rules ends the problem.
This is, however, not a satisfactory solution. The backup run of raw
spamassassin is also an inelegant solution to the problem. However, if
it is the only fix this should be documented. Per user rules are entirely
too useful in the face of threats customized for specific users. This
includes obfuscated base64 encoded email addresses within messages, and
the like.
If more information is needed, some mail logs, or some of the actual
messages which hit the trap above are needed they, too, can be provided
for your amusement. However, there seems to be no discernable pattern
to the messages other than that they seem to hit only when traffic is
"high" with high being two or three messages to process in one once per
minute fetchmail run on my Earthlink pop3 server.
{^_^}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
------- Additional Comments From spamassassin@dostech.ca 2005-12-13 03:15 -------
I don't see anything in 3.0.5 that would have fixed it.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
------- Additional Comments From lwilton@earthlink.net 2005-07-08 10:24 -------
This seems to be a duplicate of bugs 3838 and 3966.
While they are older, most of the useful discussion is here, so suggest marking
them as duplicates of this bug rather than the other way around.
I've now seen this occur in both 2.63 and 3.0x, but it is MUCH more frequent in
3.0. At a guess, some 5% of my spam is making it into my inbox by this method.
I've seen this failing in both full rules and body rules. I expect in the next
few days (now that I'm paying some attention to the log) that I'll see it in
rawbody and possibly header rules also.
The reason for the 'insecure dependency' message seems to vary by reporter. In
our case we are seeing 'no such file or directory'.
It is clear that this is some sort of totally random occurance. Running any
failing message thru SA again (or spamd again) will most always work
correctly. I suspect this may mean this is a perl bug, but I'm not sure.
It also isn't clear to me why this warning from the eval is causing SA to
fail. I haven't been able to determine so far if SA even continues beyond the
eval, or if this warning is actually blowing it out of the water right there.
At the moment I'm guessing that the eval succeeds, but then when an attempt is
made to call the generated rules a few lines later SA blows up. However, there
is nothing at all in the log indicating why SA fails to mark the message as
spam.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
------- Additional Comments From jdow@earthlink.net 2005-06-30 22:08 -------
Let me ammend that last. At present I have it trapped in a procmail script. If
it happens it goes into a niced spamassassin. That MIGHT accountfor the:
===8<---
....
From: "Dora Sheets" <Cl...@email.com>
User-Agent: The Bat! 1.96
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: imex21@earthlink.net
Subject: Hot-Stock-tip for Savvy investors detour neon
Content-Type: multipart/related;
boundary="------------6117780567137114"
X-Spam-Status: No, hits=-6.00 required=5.00 tests=COMES_FROM_TRUSTED_SOURCE
version=3.2
X-Spam-Level:
X-Spam-Checker-Version: SpamAssassin 3.1 (1.3) on email.com
X-ELNK-AV: 0
X-TAG: Scanned
X-Jdow: user procmail
X-IMAPbase: 1119863107 4115
X-UID: 4112
Content-Length: 45551
===8<---
That message sailed right though without any new markups. So it may have been
this bug hitting twice on the same message, once via spamc and once via
spamassassin itself.
{^_^}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
------- Additional Comments From jdow@earthlink.net 2005-12-13 02:45 -------
Can't. Loren and I need different rules. There are similar rules in the various
configuration files within the /etc/mail/spamassassin directory. They do not
trigger the problem. I've taken out the "offending" rules for testing and the
problem went away. I put the rules back because they were effective. I suppose
this test is as effective as the test you wanted. The rules are more or less
adapted clones of existing SARE rules at the time.
Typical rules are or have been:
full JD_INVALID_ZIP /UEsFBgAAAAAAAAAAAAAAAAAAAAAAAA\=\=/s
describe JD_INVALID_ZIP Invalid - empty - zip file.
score JD_INVALID_ZIP 5
full JD_TABLES /table cellpadding\=\"0\" cellspacing=\"0\"border=\"0\"/i
describe JD_TABLES table cellpading=0 and so forth
score JD_TABLES 2.50
===8<---
There should be a way to get the actual rule that caused the error dumped out
to a log without dumping everything.
I've folded in the 3.0.5 changes. So if 3.0.5 "should have this fixed" it
probably is fixed. I'll reenable by trap to check for it. But that will not
tell us the rule that actually failed. I suspect that migh tbe important.
I have rules for "rawbody" and "full" that trigger two of the places the error
can hit. I believe there are three places in the code that use this kind of
evalstr.
Loren and I tried to hack on 3.0.4 and get the failed evalstr to at least print
out. Neither of us is enough of a perl hacker to achieve that goal.
{^_^}
{^_^}
{^_^}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
------- Additional Comments From jdow@earthlink.net 2005-12-13 22:39 -------
Confirmed that the problem still exists.
I need to know precisely what is in the evalstr that fails. Then maybe I can do
something about further diagnosis. Until then I am stuck.
Past removal of the rawbody and full rules eliminated the problem. No rawbody
or full rules in /etc/mail/spamassassin seem to trigger the problem.
{^_^}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
------- Additional Comments From jdow@earthlink.net 2005-06-30 22:03 -------
(In reply to comment #1)
> so, it requires allow_user_rules, that's a given;
> it's intermittent, not on every mail;
Indeed - 2119 is where "full" rules are parsed. And if I comment out all
my "full" user_prefs lines the problem seems to go away.
> and it requires "full" rules (I presume you have other types and they're
working
> ok).
See above.
> does it reproducably happen with certain mails? ie. if it happens
> once with that message it'll happen again?
That is what is most amusing. No, id does not always happen. I note it is worse
now that I have Loren on this spamd server as well as me. I cannot reliably
recreate the problem either by feeding through "procmail <test" or "spamc
<test". SO at first I started wondering, "Am I really seeing this?" It took a
fair amount of additional history to note that messages with the 2119 error, as
I'll call it for short, also appear to bypass spamassassin EVEN THOUGH the log
mentions a spam value.
> this could be tricky :(
You win the golden star prize for the best understatement of the day. I usually
manage to cook up some doozies.
{^_-}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
jm@jmason.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|Insecure dependency .. |allow_user_rules permits
|.SpamAssassin/PerMsgStatus.p|mails to get past unscanned
|m line 2119 |
------- Additional Comments From jm@jmason.org 2005-06-30 21:47 -------
so, it requires allow_user_rules, that's a given;
it's intermittent, not on every mail;
and it requires "full" rules (I presume you have other types and they're working
ok).
does it reproducably happen with certain mails? ie. if it happens
once with that message it'll happen again?
this could be tricky :(
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
------- Additional Comments From spamassassin@dostech.ca 2005-12-13 01:49 -------
Have you tried moving your rules to the site configuration? That is, are you
sure this only happens with user rules?
If you haven't, could you?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
------- Additional Comments From lwilton@earthlink.net 2005-12-14 12:10 -------
Until proven otherwise its my belief that this is caused by the Perl bug
described elsewhere where global variables get tainted randomly, and thus cause
random failures at later places. I believe one of the bugs referenced in this
thread had a suggested workaround that would work "most of the time".
Someone that knows more Perl than I do should be able to try it, or at least
make the necessary changes that we could try it.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
Bob@Menschel.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.1.1
------- Additional Comments From Bob@Menschel.net 2005-07-16 11:20 -------
Triage: See also bug 3838
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4445
------- Additional Comments From jdow@earthlink.net 2005-07-09 03:46 -------
I just noticed something interesting in the log. These reports cluster in pairs
on our system. This is a typical cluster.
===8<---
Jul 8 13:07:07 morticia fetchmail[19393]: awakened at Fri 08 Jul 2005 01:07:07
PM PDT
Jul 8 13:07:08 morticia spamd[10683]: error: Insecure dependency in eval while
running setuid
at /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line 1718,
<GEN361> line 71._ No such file or directory, continuing
Jul 8 13:07:08 morticia sendmail[12435]: j68K6wXU012426:
to=<wi...@morticia.wizardess.wiz>, delay=00:00:10, xdelay=00:00:10,
mailer=local, pri=86865, dsn=2.0.0, stat=Sent
Jul 8 13:07:11 morticia fetchmail[19393]: 1 message for jdow at
smtp.earthlink.net (10189 octets).
Jul 8 13:07:11 morticia fetchmail[19393]: reading message
jdow@smtp.earthlink.net:1 of 1 (10189 octets)
Jul 8 13:07:12 morticia sendmail[12457]: j68K7BR5012457: from=<linux-kernel-
owner+jdow=40earthlink.net-S262861AbVGHUEM@vger.kernel.org>, size=10042, class=-
60, nrcpts=1, msgid=<BA...@phx.gbl>,
bodytype=8BITMIME, proto=ESMTP, daemon=MTA, relay=localhost.localdomain
[127.0.0.1]
Jul 8 13:07:12 morticia fetchmail[19393]: flushed
Jul 8 13:07:12 morticia spamd[10702]: connection from localhost.localdomain
[127.0.0.1] at port 53960
Jul 8 13:07:12 morticia spamd[10702]: info: setuid to jdow succeeded
Jul 8 13:07:12 morticia spamd[10702]: processing message <BAY20-
F1980D736F5F72579794A3DC4DB0@phx.gbl> for jdow:500.
Jul 8 13:07:16 morticia spamd[10702]: error: Insecure dependency in eval while
running setuid
at /usr/lib/perl5/site_perl/5.8.6/Mail/SpamAssassin/PerMsgStatus.pm line
2140._ , continuing
Jul 8 13:07:23 morticia fetchmail[19393]: sleeping at Fri 08 Jul 2005 01:07:23
PM PDT
Jul 8 13:07:23 morticia sendmail[12458]: j68K7BR5012457:
to=<jd...@morticia.wizardess.wiz>, delay=00:00:11, xdelay=00:00:11,
mailer=local, pri=148236, dsn=2.0.0, stat=Sent
===8<---
Line numbers above are not quite standard. The normal locations will be at
the "eval $evalstr" line above the report by a couple lines. Loren tried adding
some extra debugging that did not work.
Messages take an average of about 1.75 seconds to get through spamassassin via
spamc. We are running with spamd options:
-d -c -m5 -Hi -A 192.168.xx.,127. --max-conn-per-child=15
I get the suspicion that two instances are trying to use the same file name at
the same time. Can this file name be controlled in some manner?
{^_^}
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
spamassassin@dostech.ca changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
------- Additional Comments From spamassassin@dostech.ca 2006-04-09 06:46 -------
*** This bug has been marked as a duplicate of 3838 ***
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4445] allow_user_rules permits mails to get past unscanned
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4445
felicity@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.1.1 |3.1.2
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.