On 7/23/19 9:08 AM, Japheth Cleaver wrote:

Lereta Email Checkpoint: External email. Please make sure you trust this source before clicking links or opening attachments.

---

Just an FYI. When I updated my CentOS 7 xymon server by building from source, it refused to include the openssl libraries until I installed the libtirpc-devel package. Not sure why it is necessary.

-- Stephen

On 7/24/19 6:39 PM, Japheth Cleaver wrote:

On 7/24/2019 7:01 AM, Stephen Carville (xymon list) wrote:

...

On 7/23/19 9:08 AM, Japheth Cleaver wrote:

...

Just an FYI.? When I updated my CentOS 7 xymon server by building from source, it refused to include the openssl libraries until I installed the libtirpc-devel package.? Not sure why it is necessary.

Thanks, I'll make a note of that on the RPM site. The underlying reason here is that GCC's rpc interface was removed after a long deprecation, in favor of libtirpc. It was easier to simply test for that and move forward on use. This will also be necessary for 4.4 (IPv6) and was the main cause of the recent Fedora FTBFS's.

OK. It makes sense now. Thank you.

https://fedoraproject.org/wiki/Changes/SunRPCRemoval

Regards, -jc

-- Stephen

Probably also in all the following: -bash-4.1$ find . -type f -exec grep pragma {} + ./xymonnet/xymonnet.c: #pragma GCC diagnostic push ./xymonnet/xymonnet.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./xymonnet/xymonnet.c: #pragma GCC diagnostic pop ./lib/holidays.c: #pragma GCC diagnostic push ./lib/holidays.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/holidays.c: #pragma GCC diagnostic pop ./lib/acklog.c: #pragma GCC diagnostic push ./lib/acklog.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/acklog.c: #pragma GCC diagnostic pop ./lib/tree.c:#pragma GCC diagnostic push ./lib/tree.c:#pragma GCC diagnostic ignored "-Wunused-result" ./lib/tree.c:#pragma GCC diagnostic pop ./lib/htmllog.c: #pragma GCC diagnostic push ./lib/htmllog.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/htmllog.c: #pragma GCC diagnostic pop ./lib/stackio.c: #pragma GCC diagnostic push ./lib/stackio.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/stackio.c: #pragma GCC diagnostic pop ./lib/timefunc.c: #pragma GCC diagnostic push ./lib/timefunc.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/timefunc.c: #pragma GCC diagnostic pop ./lib/misc.c: #pragma GCC diagnostic push ./lib/misc.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/misc.c: #pragma GCC diagnostic pop ./lib/eventlog.c: #pragma GCC diagnostic push ./lib/eventlog.c: #pragma GCC diagnostic ignored "-Wformat-truncation" ./lib/eventlog.c: #pragma GCC diagnostic pop

On Jul 24, 2019, at 08:46, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:

gcc prior to 4.6 gives the errors:

acklog.c: In function ?do_acklog?: acklog.c:129:12: error: #pragma GCC diagnostic not allowed inside functions acklog.c:130:12: error: #pragma GCC diagnostic not allowed inside functions acklog.c:132:12: error: #pragma GCC diagnostic not allowed inside functions

Discussion of other software with a similar problem suggests a gcc version test for those. Or just comment out those lines, for those who don't want to install a newer gcc and don't want to wait for a version test to be added.

...

On Jul 23, 2019, at 12:11, Japheth Cleaver <cleaver at terabithia.org> wrote:

On 7/23/2019 8:57 AM, Japheth Cleaver wrote:

...

Hello all,

Xymon 4.3.29 has been released to Sourceforge and should be propagating to mirrors as I write this. Along with an assortment of bug fixes and compilation compatibility fixes for recent glibc systems, this version contains several fixes for security vulnerabilities within some CGI parsing. Although some of these overflows are not exploitable, others, including an XSS vulnerability are. Fixes beyond these CVEs have been made throughout the library, web, and network code to help reduce the likelihood of similar issues in other areas. As a result, all users are encouraged to upgrade.

The specific CVEs in question are: CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473, CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486

For clarification, the above CVEs only affect the *server* side of the Xymon monitoring system. Xymon clients are not affected.

-jc

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

On 7/24/2019 6:54 AM, Axel Beckert wrote:

Hi,

On Tue, Jul 23, 2019 at 08:57:49AM -0700, Japheth Cleaver wrote:

...

Although some of these overflows are not exploitable, others, including an XSS vulnerability are. [... ? CVE-2019-13451, CVE-2019-13452, CVE-2019-13455, CVE-2019-13473, ? CVE-2019-13474, CVE-2019-13484, CVE-2019-13485, CVE-2019-13486 Can either you or Graham get a bit more into the details regarding the impact of any of these vulnerabilities ? or point out a posting where they are explained in more detail? So far I wasn't able to dig up any posting or similar, e.g. by the Cambridge CSIRT or Graham.

Currently the severity as well as the actual impact of these issues is quite unclear ? also because the CVE-IDs all still say "RESERVED".

  Regards, Axel

CSIRT may still have a write-up pending on these, but it is believed that the only impact are segfaults when passed in invalid/overflow input. This is typically a hostsvc being parsed and assigned to a PATH_MAX-sized variable via sprintf rather than snprintf. The buffer overflow occurs, but it is not being passed unprocessed to a shell. In some cases passed parameters are passed through html quoting, thereby exceeding intended size through " " -> " " inflation, which leads to a buffer overflow when (unsafely) assigning to error output.

There was an initial concern about unparsed input being handed to xymongen during report generation, however this is passed as a single execv argument rather than via shell processing. This could lead to erroneous xymongen resource use by anyone with access to /xymon-seccgi/report.sh, however the same could be said for any (legitimate) access here.

The XSS (CVE-2019-13274) is trivially exploitable by attempting to pass javascript through the db parameter to csvinfo.sh.

Beyond the CVE's, we wanted to try to remove a large number of sprintf uses (especially in the web and lib code) to help potentially reduce future issues.

Regards, -jc