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/09/01 19:16:18 UTC
[Bug 4566] New: Double redirect fools URI parsing
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
Summary: Double redirect fools URI parsing
Product: Spamassassin
Version: 3.0.4
Platform: All
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: Rules
AssignedTo: dev@spamassassin.apache.org
ReportedBy: rosenbaumlm@ornl.gov
Spam received today contains the following URI (quoted-printable):
<A href=3D"http://www.emerald-energies.com/r=
edirect.php?action=3Durl&goto=3Dwww.emerald-energies.com/redirect.php%=
3faction=3Durl%26goto=3Dnextermest%252ecom">
The URI is a redirect that first goes back to the redirector and then to
"nextermest.com". Although nextermest.com is listed in both SURBL(SC) and
URIBL(black), the rules don't catch it.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
------- Additional Comments From rosenbaumlm@ornl.gov 2005-09-02 10:27 -------
(In reply to comment #1)
> Bug #4558 appears to be the pattern mentioned here.
There are two differences I see. First of all, in this case it is going through
the redirector site twice (Redirector -> Redirector -> Spammer). Secondly, the
final period is double encoded:
nextermest%252ecom (%25 translates to %)
nextermest%2ecom (%2e translates to .)
nextermest.com
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
------- Additional Comments From wtogami@redhat.com 2005-09-02 01:35 -------
Bug #4558 appears to be the pattern mentioned here.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
------- Additional Comments From sidney@sidney.com 2005-09-05 06:24 -------
Created an attachment (id=3113)
--> (http://bugzilla.spamassassin.org/attachment.cgi?id=3113&action=view)
Test spam edited to contain the redirected url
I've attached a test case I made by inserting the example redirected URL
In svn trunk nextermest.com was not detected before I updated to get the patch
for bug 4558 and was detected after I updated.
I'm closing this as a dup of 4558.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
sidney@sidney.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |DUPLICATE
------- Additional Comments From sidney@sidney.com 2005-09-05 06:25 -------
*** This bug has been marked as a duplicate of 4558 ***
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
------- Additional Comments From jgmyers@proofpoint.com 2005-09-02 14:25 -------
The redirect decoder should iterate if and only if the output is shorter than
the input.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4566] Double redirect fools URI parsing
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4566
------- Additional Comments From sidney@sidney.com 2005-09-02 14:04 -------
This demonstrates a general problem with any URI obfuscation that will be
recursively decoded by the browser. A correct solution would iteratively apply
the unredirection but would have a way of not getting tricked into processing
that keeps looping for a long time given input that is not very long.
As long as we are sure that parsing a redirection produces results that have to
be much shorter than the original, there is no problem with iterating until no
redirection is found.
If we do that, does it make sense to recognize when there are two or more levels
of indirection and have a rule for it? Is it a good or a bad idea to
pre-emptively catch a spammer technique that we are only beginning to see with
this example?
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.