Control: severity -1 important

Hi,

Christoph Berg wrote:
> Re: Axel Beckert
> > "critical" is indeed clearly wrong. I'd have rather said "important"
> > only as the claim of being a "root hole" is wrong. But ok.
> 
> I only moved it off "critical" which it really is not. If you think
> important (or wishlist?) makes more sense, go ahead.

For me, "important" seems appropriate. If the security team disagrees,
I'm fine with their opinion on this issue as I might be a bit biased
here as I use and value the feature in question.

> > I'm though not sure if this is acceptable for stable updates as it is
> > a rather invasive change IMHO.
> 
> It would be ok if we buy the security part.

There is some security impact by this feature, yes. But IMHO the
impact is moderate at most as the client only executes code which it
requested explicitly from the server (but does that by default which
this bug-report is about) and exploiting would require one of these
conditions:

* Compromising a router (or routing in any other way) inbetween to
  modify the response by the monitoring server — which are usually all
  in the same perimeter.

* Compromising the monitoring server itself.

* Using DNS hostnames on the client (which is explicitly not
  recommended for reliability reasons) in combination with a DNS
  spoofing attack, spoofing the server's DNS record and redirecting
  logfetch to fetch code from the wrong server.

Hint for the security team: Xymon currently does not use TLS for
monitoring checks unless you build that yourself with stunnel.

Reliability might be one of the reasons here, but I suspect more a
lack of upstream developer resources to be the reason.

Anyway, I'll prepare an update of Xymon for Unstable changing the
default setting to "logfetch --noexec" and then we'll see if more
(like stable updates or so) is needed.

                Regards, Axel
-- 
 ,''`.  |  Axel Beckert <a...@debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Attachment: signature.asc
Description: PGP signature

Reply via email to