Unrealircd & Anope services - join segmentation fault in operserv.c

[Lethalman]

If an admin say this command: '/msg operserv raw
:nickserv join #chan' NickServ join in that chan, ok.
If the command was: '/msg operserv raw : join #chan'
ircd go to SEGFAULT. Why?
Case 1: operserv ordine to a nick (NickServ) to join #chan
Case 2: operserv ordine to server to join #chan
Ircd go to SEGFAULT because it don't find that nick
(eg. hub.server.net).
In fact, if you say: '/msg operserv raw : privmsg #chan
bye' the nick is hub.server.net and not OperServ.
Solutions?
Filter operserv.c in function do_raw or filter ircd
function m_join in s_user.c

Lethal Lab Member (Lethalman)

[Sean Kelly]

--Nq2Wo0NMKNjxTN9z
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 08, 2003 at 07:14:22AM -0000, Lethalman wrote:
> If an admin say this command: '/msg operserv raw
> :nickserv join #chan' NickServ join in that chan, ok.
> If the command was: '/msg operserv raw : join #chan'
> ircd go to SEGFAULT. Why?

According to you, the IRC server crashes because ": " is expanded (or,
rather, interpreted) as the name of the server. This causes the server to
crash, since servers can't join channels and so forth.

My question is why any sensible administrator would actually use the RAW
command on Services to send such a command to an IRC server. The RAW
command does just as it says; it transmits the raw parameter string to the
uplink server. This can only be done by Services administrators, who are
supposed to be responsible enough not to send strings to the IRC server
which will crash it.

This "exploit" only seems like it would be usable after the server->server
authentication/link process has completed, and therefore presents no risk
=66rom users who you do not trust.

Your advisory is akin to telling somebody not to stab his friend in the
chest with a pitchfork.

> Case 1: operserv ordine to a nick (NickServ) to join #chan
> Case 2: operserv ordine to server to join #chan
> Ircd go to SEGFAULT because it don't find that nick
> (eg. hub.server.net).
> In fact, if you say: '/msg operserv raw : privmsg #chan
> bye' the nick is hub.server.net and not OperServ.
> Solutions?
> Filter operserv.c in function do_raw or filter ircd
> function m_join in s_user.c
>=20
> Lethal Lab Member (Lethalman)

--=20
Sean Kelly | PGP KeyID: D2E5E296
smkelly@zombie.org | http://www.zombie.org

--Nq2Wo0NMKNjxTN9z
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/CvjTPm7A9NLl4pYRAmG4AKCgPTMtaJ6PoeM2jhye3IBy4uB87A CfeJc6
wk9g2XELFxFVosbvZBblgAI=
=ppj+
-----END PGP SIGNATURE-----

--Nq2Wo0NMKNjxTN9z--

[Rob]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 08 July 2003 8:14 am, Lethalman wrote:
> If an admin say this command: '/msg operserv raw
>
> :nickserv join #chan' NickServ join in that chan, ok.
>
> If the command was: '/msg operserv raw : join #chan'
> ircd go to SEGFAULT. Why?
*snip*

Anope's FAQ file (included with all .tar.gz's and on the CVS server) clearl=
y=20
stats:

30. When I used the OperServ RAW command, Anope and/or my network
crashed, or did weird things! Please fix this bug!

"That's not a bug, it's a feature."

Have you ever typed /msg OperServ HELP RAW? It's clearly stated
there that this command is dangerous and that its use may result
in very bad things.

And that's why this command has been disabled by default. If you
enabled and used it, YOU'RE ON YOUR OWN. All help requests will
be ignored, even if the problem happens not immediately.


And the example.conf file in both Anope 1.4.x and 1.5.x series have the=20
following directive included by default:

# DisableRaw [RECOMMENDED]
#
# Disables the highly destructive OperServ RAW command.

DisableRaw


Even with this command enabled, its use is limited to services admins, who=
=20
need to be both /oper'ed with the ircd, and identified to services before=20
they can issue a command. On a side note, there is also a config option to=
=20
wallop the use of RAW to all other opers on the network, and its use is=20
always logged in the log files. =20

This "issue" can only be issued after a server has successfully connected t=
o a=20
network - passing all the authentication checks in the ircd - in this case=
=20
Unreal - as such, it is not completely unreasonable for the ircd to assume =
it=20
can "trust" the format of the messages, as user input is identified in the=
=20
messages, as laid out in the RFC. =20

I don't really see a big problem in ircd's saving some processing power by=
=20
trusting messages from already authenticated server.

As for the solutions offered, its highly unlikely Anope will be filtering R=
AW=20
commands, the whole point of them is to send a raw un-filtered message=20
directly to the ircd. We already make it close to impossible for someone t=
o=20
have RAW enabled and not know it could be destructive...=20

p.s. - if you had contacted Anope at all before posting this, we could have=
=20
told you this, and saved you the trouble of posting at all..... still=20
notifying developers, at all, before a public announcement must be out of=20
fashion this season or something ;-)

=2D --=20
Rob - Anope developer=20
irc.anope.org #anope

GnuPG key: 1024D/309586CA
=46ingerprint: 952A 4EB9 CC81 F30A 35CF D473 BF12 FD80 3095 86CA
Key available at http://pgp.mit.edu

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD4DBQE/CzhAvxL9gDCVhsoRAjTUAJiGsDaHekSfQsj8UQoCj5RhHS3uAK DNRyq8
v1AEzuGCYNO8AnGjB+Xz+g=3D=3D
=3DXACj
=2D----END PGP SIGNATURE-----