View Issue Details

IDProjectCategoryView StatusLast Update
0003893unrealircdpublic2010-09-20 02:34
ReporterR-TypeEman Assigned Toohnobinki  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version3.2.8 
Fixed in Version3.2.9-RC1 
Summary0003893: Firefox XPS IRC Attack
DescriptionUnreal is vulnerable to the following attack:

http://encyclopediadramatica.com/Firefox_XPS_IRC_Attack
TagsNo tags attached.
3rd party modules

Relationships

child of 0003776 resolvedsyzop Unreal3.2.9 TODO 

Activities

syzop

2010-02-28 17:53

administrator   ~0016037

Is that the same as 0003862 ?
And does the suggested module therein help against this ?
(As you can see I was happy to do something about it, but got no feedback at all. If it's the same issue, that is.)

syzop

2010-02-28 18:09

administrator   ~0016038

Last edited: 2010-02-28 18:10

Seems so. Thanks for the heads up.
I'll enhance my module a bit (it was just proof-of-concept) and make it more public ;)

EDIT: btw, it should be mentioned that enabling NOSPOOF protects against this attack. Well, the clients will take up unknown connections, of course...

R-TypeEman

2010-02-28 19:29

reporter   ~0016039

that module seems to do the trick

thanks

syzop

2010-02-28 19:36

administrator   ~0016040

Ok :)
I've posted it on the website / news section: http://forums.unrealircd.com/viewtopic.php?t=6458
I wasn't paying too much attention to generic IRC news for the past 6 weeks or so, and nobody informed me until now about this.. so thanks again.

syzop

2010-07-14 17:07

administrator   ~0016164

ohnobinki: what do you think, I have my free module and such, I feel like it can be quite important for ircds to have...
Shall I just throw it in the unreal tree?

Another question is, should I call it like m_<whatever>, and make it included in commands.so too? That way, each ircd will run it. If I don't then many won't use it.
Feels like a good idea..

ohnobinki

2010-07-16 01:24

reporter   ~0016203

I think the module should be accepted as official (and thus shipped with unrealircd-3.2.9).

I'm not sure if it's necessary to have it compiled into commands.so. 3.2.9 will have NOSPOOF enabled by default now -- perhaps that is enough. But, yes, I don't know why an IRCd wouldn't want to have this. (it doesn't look like my uncertainty here is of any help ;-) ).

syzop

2010-07-16 14:52

administrator   ~0016211

hehehe
ok, let's put it in then. and yeah link it in commands.
perhaps name it m_something too so loadmodule m_*.so will include them if someone doesn't use commands.so.

still, have to think about the default settings. some users reported an annoying amount of notices regarding bots (webspiders) going to their ircd. hmmmm.

chotaire

2010-09-09 15:28

reporter   ~0016353

Same here, why is this important module not in the modules database?

ohnobinki

2010-09-09 15:31

reporter   ~0016354

Because the modules ``database'' is un-modifiable.

syzop

2010-09-09 19:20

administrator   ~0016356

ARGH.. same note as the other bug.

ohnobinki

2010-09-15 18:25

reporter   ~0016364

Committed:

- Add the m_nopost module written by syzop and compile it into
commands.so. This module was written to help IRCd maintainers deal
with some sort of ``XPS'' attack in which javascript-initiated HTTP
POST form submissions were able to act as dummy IRC bots. These
simple bots were the cause of much spam. (0003893)
- Add a modules section to the documentation. This was created to put
all documentation specific to the m_post module in one, easy to find
place. The documentation on m_post is likely incomplete, however.

As I wrote in the commit message, I should probably really revisit the documentation. Also, syzop, if the creation of a new documentation section makes no sense or anything, just tell me and I'll refactor that documentation so that m_post is treated as a core functionality.

I just wanted to commit this as this had been sitting in my checkout for a week or two without being touched :-/

syzop

2010-09-19 23:46

administrator   ~0016370

One of the translators told me the order (sequence) of the chapters is screwed up, could you check? *lazy*

ohnobinki

2010-09-20 02:34

reporter   ~0016371

Oops, reordered.

Issue History

Date Modified Username Field Change
2010-02-28 17:35 R-TypeEman New Issue
2010-02-28 17:53 syzop Note Added: 0016037
2010-02-28 18:09 syzop Note Added: 0016038
2010-02-28 18:09 syzop Note Edited: 0016038
2010-02-28 18:09 syzop Note Edited: 0016038
2010-02-28 18:10 syzop Note Edited: 0016038
2010-02-28 19:29 R-TypeEman Note Added: 0016039
2010-02-28 19:36 syzop Note Added: 0016040
2010-07-14 17:07 syzop Note Added: 0016164
2010-07-14 17:07 syzop Relationship added child of 0003776
2010-07-14 18:01 syzop QA => Not touched yet by developer
2010-07-14 18:01 syzop U4: Need for upstream patch => No need for upstream InspIRCd patch
2010-07-14 18:01 syzop U4: Upstream notification of bug => Not decided
2010-07-14 18:01 syzop U4: Contributor working on this => None
2010-07-14 18:01 syzop Status new => confirmed
2010-07-14 18:01 syzop View Status private => public
2010-07-16 01:24 ohnobinki Note Added: 0016203
2010-07-16 14:52 syzop Note Added: 0016211
2010-09-06 15:05 ohnobinki Status confirmed => assigned
2010-09-06 15:05 ohnobinki Assigned To => ohnobinki
2010-09-09 15:28 chotaire Note Added: 0016353
2010-09-09 15:31 ohnobinki Note Added: 0016354
2010-09-09 19:20 syzop Note Added: 0016356
2010-09-15 18:25 ohnobinki Note Added: 0016364
2010-09-15 18:25 ohnobinki Status assigned => resolved
2010-09-15 18:25 ohnobinki Fixed in Version => 3.2.9-RC1
2010-09-15 18:25 ohnobinki Resolution open => fixed
2010-09-19 23:46 syzop Note Added: 0016370
2010-09-20 02:34 ohnobinki Note Added: 0016371