You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Stuart Johnston <st...@ebby.com> on 2004/12/17 23:04:32 UTC
Plugins Can't be Enabled by Users
I have been having a difficult time getting URIDNSBL to work and I
finally figured out why. I was trying to do the loadplugin in a
user_prefs file in order to test out a new configuration.
The problem is that the builtin plugins can not be enabled from
user_prefs because the default rules (25_uribl.cf, etc) will be run
earlier and contain ifplugin conditionals. When the plugin is loaded by
user_prefs it will be too late and the rules will never get loaded.
I can see equal arguments for this being considered a feature or a bug
so I mention it mostly in case it helps someone else avoid the
frustration that it caused me.
Stuart Johnston
Re: Plugins Can't be Enabled by Users
Posted by Stuart Johnston <st...@ebby.com>.
Michael Parker wrote:
> On Fri, Dec 17, 2004 at 05:00:14PM -0600, Stuart Johnston wrote:
>
>>Yes, quite. I double checked just to be sure and I notice that the
>>'debug: plugin' line comes after the user_prefs is loaded even if it is
>>loaded by init.pre. Never the less, if I remove the loadplugin line
>>from init.pre and keep it in user_prefs, the plugin is still loaded. If
>>I remove it from both, it does not load.
>>
>
>
> Please open a bug in Bugzilla (http://bugzilla.spamassassin.org/) for
> this.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4041
Re: Plugins Can't be Enabled by Users
Posted by Michael Parker <pa...@pobox.com>.
On Fri, Dec 17, 2004 at 05:00:14PM -0600, Stuart Johnston wrote:
>
> Yes, quite. I double checked just to be sure and I notice that the
> 'debug: plugin' line comes after the user_prefs is loaded even if it is
> loaded by init.pre. Never the less, if I remove the loadplugin line
> from init.pre and keep it in user_prefs, the plugin is still loaded. If
> I remove it from both, it does not load.
>
Please open a bug in Bugzilla (http://bugzilla.spamassassin.org/) for
this.
Thanks
Michael
Re: Plugins Can't be Enabled by Users
Posted by Stuart Johnston <st...@ebby.com>.
Michael Parker wrote:
> On Fri, Dec 17, 2004 at 04:41:01PM -0600, Stuart Johnston wrote:
>
>>I certainly don't disagree with the security problems with allowing
>>users to load plugins. The problem is that in fact, user_conf CAN load
>>a plugin and does quite certainly execute its code, despite what the
>>documentation says. It just doesn't do any good because the default
>>rules will not be loaded. Of course, that wouldn't matter to an attacker.
>>
>>If spamassassin had given me a warning from the loadplugin line in my
>>user_conf instead of:
>>
>>debug: config: read file /home/stuart/.spamassassin/user_prefs
>>debug: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC
>>debug: plugin: registered
>>Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xa14a0d8)
>>
>>Then it would have been quite obvious what the problem was.
>>
>
>
> Are you sure it isn't just in your init.pre file?
Yes, quite. I double checked just to be sure and I notice that the
'debug: plugin' line comes after the user_prefs is loaded even if it is
loaded by init.pre. Never the less, if I remove the loadplugin line
from init.pre and keep it in user_prefs, the plugin is still loaded. If
I remove it from both, it does not load.
And I just tried from a different computer with the same results.
Stuart Johnston
Re: Plugins Can't be Enabled by Users
Posted by Michael Parker <pa...@pobox.com>.
On Fri, Dec 17, 2004 at 04:41:01PM -0600, Stuart Johnston wrote:
>
> I certainly don't disagree with the security problems with allowing
> users to load plugins. The problem is that in fact, user_conf CAN load
> a plugin and does quite certainly execute its code, despite what the
> documentation says. It just doesn't do any good because the default
> rules will not be loaded. Of course, that wouldn't matter to an attacker.
>
> If spamassassin had given me a warning from the loadplugin line in my
> user_conf instead of:
>
> debug: config: read file /home/stuart/.spamassassin/user_prefs
> debug: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC
> debug: plugin: registered
> Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xa14a0d8)
>
> Then it would have been quite obvious what the problem was.
>
Are you sure it isn't just in your init.pre file?
Michael
Re: Plugins Can't be Enabled by Users
Posted by Stuart Johnston <st...@ebby.com>.
Matt Kettler wrote:
> At 05:04 PM 12/17/2004, Stuart Johnston wrote:
>
>> I have been having a difficult time getting URIDNSBL to work and I
>> finally figured out why. I was trying to do the loadplugin in a
>> user_prefs file in order to test out a new configuration.
>>
>> The problem is that the builtin plugins can not be enabled from
>> user_prefs because the default rules (25_uribl.cf, etc) will be run
>> earlier and contain ifplugin conditionals. When the plugin is loaded
>> by user_prefs it will be too late and the rules will never get loaded.
>>
>> I can see equal arguments for this being considered a feature or a bug
>> so I mention it mostly in case it helps someone else avoid the
>> frustration that it caused me.
>
>
> personally, consider it a very severe, server security compromising bug
> if user_prefs COULD load a plugin.... Remember.. plugins are perl code
> loaded into SA. They can do anything a perl program can, should they
> care to.... And the loadplugin command can load *any* perl code anywhere
> on the system if you specify a path...
>
>
> This particular behavior is pretty well documented in the manpage for
> Mail::SpamAssassin::Conf.. loadplugin is listed in the "Administrator
> Settings" section.. With the following header:
>
>>
>> ADMINISTRATOR SETTINGS
>>
>>
>>
>> These settings differ from the ones above, in that they are considered
>> 'more privileged' -- even more than the ones in the PRIVILEGED
>> SETTINGS section. No matter what allow_user_rules is set to, these can
>> never be set from a user's user_prefs file.
>
>
>
> In general everything in that section could be abused by a user to gain
> privileges as some other user, or facilitate DoS attacks on SA. Hence,
> why they aren't allowed in user_prefs.. ever.
>
I certainly don't disagree with the security problems with allowing
users to load plugins. The problem is that in fact, user_conf CAN load
a plugin and does quite certainly execute its code, despite what the
documentation says. It just doesn't do any good because the default
rules will not be loaded. Of course, that wouldn't matter to an attacker.
If spamassassin had given me a warning from the loadplugin line in my
user_conf instead of:
debug: config: read file /home/stuart/.spamassassin/user_prefs
debug: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC
debug: plugin: registered
Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0xa14a0d8)
Then it would have been quite obvious what the problem was.
Stuart Johnston
Re: Plugins Can't be Enabled by Users
Posted by Matt Kettler <mk...@evi-inc.com>.
At 05:04 PM 12/17/2004, Stuart Johnston wrote:
>I have been having a difficult time getting URIDNSBL to work and I finally
>figured out why. I was trying to do the loadplugin in a user_prefs file
>in order to test out a new configuration.
>
>The problem is that the builtin plugins can not be enabled from user_prefs
>because the default rules (25_uribl.cf, etc) will be run earlier and
>contain ifplugin conditionals. When the plugin is loaded by user_prefs it
>will be too late and the rules will never get loaded.
>
>I can see equal arguments for this being considered a feature or a bug so
>I mention it mostly in case it helps someone else avoid the frustration
>that it caused me.
personally, consider it a very severe, server security compromising bug if
user_prefs COULD load a plugin.... Remember.. plugins are perl code loaded
into SA. They can do anything a perl program can, should they care to....
And the loadplugin command can load *any* perl code anywhere on the system
if you specify a path...
This particular behavior is pretty well documented in the manpage for
Mail::SpamAssassin::Conf.. loadplugin is listed in the "Administrator
Settings" section.. With the following header:
>
>ADMINISTRATOR SETTINGS
>
>
>
>These settings differ from the ones above, in that they are considered
>'more privileged' -- even more than the ones in the PRIVILEGED SETTINGS
>section. No matter what allow_user_rules is set to, these can never be set
>from a user's user_prefs file.
In general everything in that section could be abused by a user to gain
privileges as some other user, or facilitate DoS attacks on SA. Hence, why
they aren't allowed in user_prefs.. ever.