Dear Maintainer,

after upgrading to jessie, an XMPP client application written in Perl
failed to start with

| Insecure dependency in eval while running setuid at /usr/share/perl5/Net/XMPP/Protocol.pm line 1007.

The offending line

| eval "\$obj = new $NEWOBJECT{$tag}(\$tree);";

isn't something I'd call good Perl style. Replacing it with

| eval { $obj = new {$NEWOBJECT{$tag}}($tree); };

made the woes go away. This code still exists in stretch.

    Christoph

Hi,

Christoph Biedl wrote:

There is a new upstream release available which also changed that
code, but differently:

https://metacpan.org/source/DAPATRICK/Net-XMPP-1.05/lib/Net/XMPP/Protocol.pm#L1302

| eval "\$obj = $NEWOBJECT{$tag}->new(\$tree);";

Likely the relevant changelog entry is this one:

| Replace indirect object notation with direct invocation notation

		Regards, Axel

Hi Christoph,

Axel Beckert wrote:

Can you give me some example code which triggers this issue so that I
can test if it's fixed with the new upstream release? The upstream
test suite of the upstream release currently in Debian doesn't seem to
trigger such warnings.

		Regards, Axel

Axel Beckert wrote...
following code as root after adjusting the server information and
credentials, login must succeed to trigger the error. Discussion
follows.

======================================================================
#!/usr/bin/perl

use 5.010;
use strict;
use warnings;

use Net::XMPP;

$> = 65534;

my $Connection = Net::XMPP::Client->new ();
my $status = $Connection->Connect (
    'hostname' => 'server.example.com',
    'port' => 5222,
) or die;
my @result = $Connection->AuthSend (
    'username' => 'user',
    'password' => 'pass',
    'resource' => 'whatever',
);
======================================================================

This might raise the question why somebody would want to do run such a
script setuid. The proper answer however was to question why anyone of
upstream, packagers and otherwise Perl related folks would want to bar
them from doing so.

This is a political question, and it's not limited to libnet-xmpp-perl
in any way: Are Perl modules expected to work in stricter environments,
where the runtime enforces rules it usually does not, like taint mode
or when running setuid like here? In my opinion "yes" but it's a tough
job to identify all the places in the code, and sometimes fixing them
isn't easy either. So this should be decided on a big scale, as a
release goal, at debian-devel and/or DebConf, and libnet-xmpp-perl
might not be the right place to exercise this beforehand.

However, in my case the answer is a bit different. The client code is a
daemon that relays messages received via XMPP. It gets started using
start-stop-daemon, then drops privileges. Instead of using
POSIX::setuid this was done manually by setting $> but not $<, and
things went downhill from there. In other words, running setuid was not
intended anyway and that code has been fixed now.

Long story short: Feel free to lower severity. Using code in eval "..."
is evil. Upstream's recent change did not remove the error.

    Christoph

Hi Christoph,

Christoph Biedl wrote:

Thanks a lot!

Will try it as soon as I get the new upstream release to build
properly.

		Regards, Axel

Hi Christoph,

Christoph Biedl wrote:

I'm sorry, but I failed to get that script working.

I tried with:

* My own server (cacert certificate, Net::XMPP::Client can't seem to
  pass ssl_ca_path to XML::Stream)
* Upstream's test server (connection refused despite I used the same
  data as in their own test scripts)
* locally installed jabberd2 (gave nothing 500 server error after I
  had it purged and installed again)
* locally installed prosody (connection timeout).

I see currently two options:

a) you try to checkout
https://anonscm.debian.org/cgit/pkg-perl/packages/libnet-xmpp-perl.git
   and build the package from there to test it.

b) I'll upload the new upstream release without fixing this issue, you
   try it afterwards in Sid oder Testing and I either close this issue
   retroactively or try to fix it based on your feedback.

		Regards, Axel

It's getting interesting ...

Axel Beckert wrote:

The easiest way for me to get an XMPP server running was to install
prosody, lua-sec, and libdigest-hmac-perl. Beware of #748721, edit
the certificate name in /etc/prosody/prosody.cfg.lua. Then use
prosodyctl to create an account.

If it's of any help, I can provide a root account on a test machine
for you, with a running prosody server. Send me your public ssh key.
But ... see below.
Additionally, this raises new warnings (three times):

| WARNING: debug file () does not exist
|          and is not writable by you.
|          No debug information being saved.

This also happens without any setuid quirks, the messages are
generated by

* /usr/share/perl5/XML/Stream.pm:401 (one time)
* /usr/share/perl5/XML/Stream/Parser.pm:135 (two times)

and I have no idea why. Good luck :)
are more problems on the political layer: If you run my small script
in Perl's taint mode, it will croak in other places:

| Insecure dependency in eval while running with -T switch at /usr/share/perl5/Authen/SASL/Perl.pm line 58.
|  at /usr/share/perl5/XML/Stream.pm line 2155.

So a can of worms is waiting to be opened ...

AND: While I managed to reproduce the issue in my usual test systems,
I failed to do so in a fresh, plain jessie install, the one I could
easily grant you access to. So I still cannot make you see it with
your own eyes.¹ At first, I really should find the differences between
these two installations. I'll get back to you then.

    Christoph

¹ At least the new "WARNING"s show up, though.

Axel Beckert wrote...

Well perhaps I've messed it up. Try again with

| $< = 65534;
( Seems I've swapped $< and $>)

Does that change things?

    Christoph

Hi Christoph,

Christoph Biedl wrote:

Thanks for the update.

I'll check later with a local prosody again. Your last mail gave
enough hints about prosody so that I know at least a few things I did
wrong or didn't try with prosody.

		Regards, Axel