[MIR] anope

[LaMont Jones]

After a careful review of https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, I believe that anope should be included in main. Our evaluation of IRC daemons led us to anope as the only set of IRC services that is actively maintained and sane.

Package: anope

Availability:
Present in a useful form as of wily.

Rationale:
We currently have no IRC daemon in main. This package represents the
best available IRC daemon for largescale deployment.

Security:
No known security reports. Anope seems to be the only IRC services
package that is currently being developed and packaged.

QA:
I am not recommending that this be installed by default. The package
documentation makes configuring it relatively straight forward.

Issue tracking:
https://bugs.debian.org/anope
https://bugs.launchpad.net/ubuntu/+source/anope
https://bugs.anope.org/view_all_bug_page.php

Dependencies: all in main

Standards: meets standards

Maintenance: Dominic Hargreaves <email address hidden>

Background information:

Historically, we have used UnrealIRCd, which has a relatively poor
security track record. After evaluation of alternatives, we determined
that inspircd was the best candidate for our irc needs, with anope
providing services.

Security history:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=anope
==> nothing

http://secunia.com/advisories/search/?search=anope
==> nothing

http://people.canonical.com/~ubuntu-security/cve/universe.html
no entries

Security relevant binaries:
No setuid/setgid binaries
Delivers binaries in /usr/sbin, and starts services.
An apparmor profile has been written, and a bug requesting inclusion
submitted.
No privileged ports are used.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Matthias Klose (doko)]

is this still relevant?

[Paul Collins (pjdc)]

This is the services daemon Canonical IS uses for irc.canonical.com, so we would certainly be glad to see it included in main.

[Robie Basak (racb)]

> Check for security relevant binaries. If any are present, this requires a more in-depth security review

I think the nature of this package means that it certainly needs an ack from the security team.

[Robie Basak (racb)]

It looks like bug 1473231 hasn't been addressed. It needs forwarding upstream and/or adding/maintaining as a delta to Ubuntu.

[Robie Basak (racb)]

The Apparmor profile bug remains open in Debian. It looks like it's feasible to drive that to resolution in Debian. Failing that the security team will probably ask for it to be included in a delta in Ubuntu.

In general the packaging looks to be good quality. I can look more thoroughly later, but I think it's likely that I won't have any objection to main inclusion in Ubuntu once the few minor things have been addressed. I think it makes sense to request a security review next, as that's the biggest question mark for this package as it's particularly security sensitive.

[Jamie Strandboge (jdstrand)]

Per https://wiki.ubuntu.com/UbuntuMainInclusionRequirements, "All packages must have a designated "owning" team, regardless of complexity, which is set as a package bug contact."

It isn't clear (to me anyway) who the owner of this package will be. The requester no longer works for Canonical. Is this something the server team is committed to? I'm going to assign Robie to answer this question, but please reassign/unassign as desired. If an owning team is assigned, please feel free to assign back to ubuntu-security.

Thanks!

[Robie Basak (racb)]

Passed on to Josh.

[Joshua Powers (powersj)]

Subscribed ubuntu-server to the bugs due to the usage of this project by Canonical IS.

Marking this bug as new and removing myself.

[Eduardo Barretto (ebarretto)]

I reviewed anope version 2.0.6-1 as checked into cosmic.
This shouldn't be considered a full audit but rather a quick gauge of
maintainability.

Anope is a set of services for IRC networks. It allow users/admins to
manage their nicks/channels/networks and more.
Quick list of services:
 - NickServ
 - ChanServ
 - MemoServ
 - BotServ
 - OperServ
 - HostServ

- No CVEs registered against anope.
- Build-depends:
 - debhelper (>= 10),
 - cmake,
 - default-libmysqlclient-dev,
 - libldap2-dev,
 - libpcre3-dev,
 - libgnutls28-dev,
 - libsqlite3-dev
- postinst and post/pre rm automatically added
- init script: /etc/init.d/anope
  - Has a: chown irc /var/run/anope (not recursive)
- No systemd services
- No dbus services
- No setuid bit
- Binaries in PATH: /usr/sbin/anope
- No sudo fragments
- No udev rules
- No tests
- No cron jobs
- Some lintian warning/error. The permission warning I would ignore,
0700 permission looks better than 0755 for db backups.
  E: anope changes: bad-distribution-in-changes-file unstable
  W: anope: non-standard-dir-perm var/lib/anope/db/backups/ 0700 !=
0755
  W: anope: binary-without-manpage usr/sbin/anope
  N: 12 tags overridden (12 warnings)

- Lack of input sanitization:
  ./modules/extra/m_regex_pcre.cpp:36: return pcre_exec(this->regex,
NULL, str.c_str(), str.length(), 0, 0, NULL, 0) > -1;
  ./modules/extra/m_regex_tre.cpp:38: return regexec(&this->regbuf,
str.c_str(), 0, NULL, 0) == 0;
  ./modules/extra/m_regex_posix.cpp:37: return regexec(&this->regbuf,
str.c_str(), 0, NULL, 0) == 0;

  None of those regex engines do input sanitization, and there is no
sanitization on anope's code. We reported it to upstream, see more
information at the bottom of this comment.

- Processes spawned:
  ./src/main.cpp:212: execve(Anope::ServicesBin.c_str(), av, envp);
  ./src/config.cpp:681: this->fp = (this->executable ? popen(this-
>name.c_str(), "r") : fopen((Anope::ConfigDir + "/" + this-
>name).c_str(), "r"));
  ./src/mail.cpp:30: FILE *pipe = popen(sendmail_path.c_str(), "w");

  Although they look dangerous, we understood that the input come from Anope's
configuration file, which is under administrator control, so probably fine.

- There are many file IO operations and memory management operations in
the project. After spending some time I couldn't find any trivial way
to trigger an overflow/underflow, but more time would be required in
order to be truly sure.

- Logging looks ok

- Make use of the following environment languages: LANGUAGE e LANG.
Looks safe.
./src/language.cpp:104: setenv("LANG", lang, 1);
./src/language.cpp:105: setenv("LANGUAGE", lang, 1);
./src/language.cpp:115: unsetenv("LANGUAGE");
./src/language.cpp:116: unsetenv("LANG");

- Anope make use of the following privileged functions. All of them are
used in the same function setuidgid(), which is executed during Anope's
initialization.
The setgid and setuid will only be triggered if the user specifies a
specific user and group on anope's config file. The chown will be
executed on every initialization to set the owner of the log files to
either the specified user (if defined in the config file) or to the
current user that is running Anope.
./src/init.cpp:27...

[Eduardo Barretto (ebarretto)]

Anope developers finally replied that Anope is still being maintained, despite the lack of replies on the ticket that I've opened.
I believe they will take a closer look to the reported issues in the near future.
And if anyone is interested, PRs can be send to them to fix any of those issues.

Security team ACK for promoting anope to main.

[Robie Basak (racb)]

Seed change committed.

[Matthias Klose (doko)]

Override component to main
anope 2.0.6-1 in disco: universe/misc -> main
anope 2.0.6-1 in disco amd64: universe/net/optional/100% -> main
anope 2.0.6-1 in disco arm64: universe/net/optional/100% -> main
anope 2.0.6-1 in disco armhf: universe/net/optional/100% -> main
anope 2.0.6-1 in disco i386: universe/net/optional/100% -> main
anope 2.0.6-1 in disco ppc64el: universe/net/optional/100% -> main
anope 2.0.6-1 in disco s390x: universe/net/optional/100% -> main
7 publications overridden.