Insecure Default Config leads to security issue

[Roman Schließmeyer]

The default configuration file delivered with package tntnet prior to version 2.2.1 allows unauthenticated remote attackers to obtain critical system information. At least Ubuntu 10.04 and 12.04 - both still supported and not yet EOL - are still affected. This issue should also be considered with urgency „high“ and fixed immediately.

How to reproduce:

1) Install tntnet: apt-get install tntnet
2) Browse to: http://<IP-of-server>///etc/passwd

System used to reproduce:

Description: Ubuntu 12.04.5 LTS
Release: 12.04

tntnet:
  Installed: 2.0+dfsg1-2
  Candidate: 2.0+dfsg1-2

See also:

https://launchpad.net/debian/+source/tntnet/+changelog

[Launchpad Janitor (janitor)]

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

[Marc Deslauriers (mdeslaur)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Christian Hertel (ch-m)]

As requested, I have created a debdiff (my first debdiff so far) which seems to fix this issue in our case.

[Jonas Platte (jplatte)]

That will probably still allow paths like "/../../etc/passwd". That's why tntnet has the documentRoot setting, which should be available in tntnet 2.0, but should also already be set in the default configuration: https://github.com/maekitalo/tntnet/blob/tags/2.0/tntnet/etc/tntnet/tntnet.xml.in#L59

[Marc Deslauriers (mdeslaur)]

Thanks for the debdiff. I've subscribed the "ubuntu-security-sponsors" group for review.

[Christian Hertel (ch-m)]

@Jonas:

Upstream seems to be based on the following sources:
http://www.tntnet.org/download/tntnet-2.0.tar.gz

The default configuration in this packages is not xml format and therefor different to the one where all the patches in the existing tntnet source deb package were built on.

I chose to adjust the existing patches in the most possible minor way.
We also thought this would still expose the systems files if an attacker would use URLs like "/../../etc/passwd", but found no way to get it working, tntnet always returned "error".

[Christian Hertel (ch-m)]

Sorry, I was unable to find a way to edit my last posting:

> The default configuration in this packages is not xml format and therefor different to the one where all the patches in the existing > tntnet source deb package were built on.

I meant the default configuration file (etc/tntnet/tntnet.conf.in) is not in XML format, and the existing patch was based on this default configuration, and changes other lines as well.

Maybe it is also possible to take the xml format default configuration (the one you have linked above), however I preferred to adjust the existing patch with as little changes as possible to avoid breaking other things.

[Jonas Platte (jplatte)]

Oh, wait a second. The DocumenRoot was already set in the upstream .conf.in file, but was removed by the original debian patch! What?? I would seriously recommend you to find out why it was removed originally, and restore it. The DocumentRoot setting is specifically made for this purpose, and prepending a path like what you did is never a good idea!

[Christian Hertel (ch-m)]

Jonas,

for sure the suggested change is not the perfect solution and without any doubt there are many better ways to achieve the goal.
Unfortunately I do not have the time to evaluate all possible options, I just wanted to suggest a change to provide a default configuration (which is as close to the one debian provides) which does not expose files outside from /var/www.

Just take it as a suggestion and feel free (or someone other) to provide a better solution.

[Jonas Platte (jplatte)]

Allright, there is probably some reason this was removed in the original patch. If you don't want to do anything beyond what you've done already, that's fine by me. I won't fix this because I hate Launchpad with a passion; I just seem to have subscribed to tntnet bugs here somewhen, that's why I got involved.

As another option you could maybe contact the tntnet maintainer and ask him how to best fix this: <email address hidden>

[Steve Beattie (sbeattie)]

Okay, thanks for the comments. Unless someone is willing to prepare a debdiff with a better fix, I'm going to sponsor the one that Christian provided.

Christian: for the record, for updates targeted towards a security pocket, please target RELEASE-security, not just RELEASE. Also, "closes: #bugnumber" is for closing closing debian bugs, use "LP: #bugnumber" to reference launchpad bugs. I've made those adjustments to your debiff.

Thanks again.

[Launchpad Janitor (janitor)]

This bug was fixed in the package tntnet - 2.0+dfsg1-2ubuntu0.1

---------------
tntnet (2.0+dfsg1-2ubuntu0.1) precise-security; urgency=high

  * SECURITY UPDATE: Fixed default configuration to prevent exposing
    files from /. (LP: #1430750)
 -- Christian Hertel <email address hidden> Wed, 11 Mar 2015 16:07:14 +0100

[Christian Hertel (ch-m)]

Jonas:

I will send a mail to Kari Pahula, which seems to be maintaining the tntnet package
for Debian, and point him to this launchpad bug.
Maybe he will give us some insights on why he changed the default configuration
that way, review my changes and either adapt it to fix the tntnet Debian squeeze
package as well or even provide a better fix, which we can adapt for Ubuntu.

Steve:

> Christian: for the record, for updates targeted towards a security pocket,
> please target RELEASE-security, not just RELEASE. Also, "closes: #bugnumber"
> is for closing closing debian bugs, use "LP: #bugnumber" to reference
> launchpad bugs. I've made those adjustments to your debiff.

ah, thank you. I'm new to launchpad and the tutorial I followed to made the changes
to the package was from the Debian guys, so I wasn't aware of the differences to
launchpad. Thank you for clarification.

[Christian Hertel (8-ubuntv-d)]

Just for completion:

I just got a short answer from Kari Pahula pointing me to the corresponding Debian bug report:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724746

Looks like the issue has been already fixed there in the same way I fixed it.
Until now I accidentally that thought Debian security fixes will automatically get adapted by Ubuntu, too...