Xmltooling 1.4.6
Ambra Piszczek
I'm trying to install the prerequisites for the Shib 2 SP but I can't manage to get xmltooling to build. When I run ./configure --with-log4shib=/usr/lib64 --prefix=/usr/local/shibboleth-sp -C, I receive this output:checking for log4shib-config... no
configure: WARNING: log4shib-config not found, may need to use --with-log4shib option
configure: WARNING: will look for original log4cpp library
checking for log4cpp-config... no
configure: error: log4cpp-config not found, may need to use --with-log4cpp optionI can confirm that the log4shib modules are located in /usr/lib64. I was forced to install log4shib from an RPM, since it fails to build from source and I can't rebuild the source RPM.
The place to solve these problems is config.log, but the reason it failed is
that you're pointing at the lib directory, not the root. If you install to
/usr, you don't have to use any options, it will find it for you. But /usr
is the appropriate location to specify, not a lib directory. That goes for
anything.
The problem that I have with using the RPMs is that a lot of these packages fail to find their dependencies, even after I've installed them (either via RPM or compiled from source). It's just a big mess of dependency issues. OpenSAML fails to install due to libxml-security. Libxml-security can't install as an RPM but works from source. Etc...Eric
As Peter said, this is not the case, which means you're possibly doing
something incorrectly that will probably affect you no matter how you try to
do this.All of the necessary RPMs are there, in source form and in binary form for
the supported platforms. Anything that's not there is part of your OS and
can be installed from its package set. The real problem would be if it was
there *and* part of your OS, which would lead to conflicts.You never identified your OS, so my guess is the root of your problem is
that it's not a supported platform, but even so, on most (not all) RPM-based
systems rebuilding the SRPMs is trivial and is also documented in the wiki.-- Scott
More out of curiosity (we're on RHEL only for a few months now, so I
certainly don't know all the pitfalls):* er...@njit.edu [2008-07-31 20:32]:
>/usr/lib/gcc/x86_64-redhat-linux/4.3.0/../../../../include/c++/4.3.0/cmath:99:
^^^^^^^^^^^^^^^^^^^
I would expect from this that you're on a supported platform -- the
wiki explicitly mentions "CentOS (Red Hat Enterprise) 4 and 5 (x86_64)".Any idea, why the official binary RPMs would not install?
What's the actual error message from trying to install log4shib?for RHEL5:
_64/RHE/5/log4shib-1.0-1.x86_64.rpmfor RHEL4:
_64/RHE/4/log4shib-1.0-1.x86_64.rpmCheers,
I've seen that, perfectly well explained the compile errors (as well
as any errors rebuilding the SRPMs). But does not explain why rpm
-ivh'ing binary packages would fail (but them I'm boneheaded).
-peter
Oh, that's just dependencies, I'm sure. Libraries with the wrong sonames
(openssl's tend to be made up out of whole cloth), or just a different
libcurl than the one Red Hat ships, that kind of thing. Doesn't take much to
blow them up.-- Scott
This doesn't match what happens on any Fedora box I know of, so that's why I
think you have more problems coming and wouldn't trust your build. I've done
a build of the RPMs on Fedora 9 and it was nothing unusual. I had to use the
branch, of course, because of the compiler issues.There's also the fact that the crypto there is broken now, but if you built
your own libcurl, that should get around that problem. If not, you'll have
to. This is why Fedora isn't supported.
Switch to RHEL or CentOS, wait until next week for 2.1, pull the branches of
each project, or find the bugs in svn that reference gcc 4.3 and look at the
checked-in revisions for the patches.-- Scott
That was also separately reported and fixed a while ago, just include
.Unless you have a real need for this before next week, I suggest you just
wait for 2.1. Even if you do need it now, I'd pull the branches. I'm not
frozen, but for all intents and purposes, nothing is changing between now
and 2.1.-- Scott
Over the past few weeks, vulnerabilities in proprietary Ivanti products, in particular Ivanti Connect Secure, Policy Secure, and ZTA gateways, have been making headlines for their active exploitation in the wild.
Last month, U.S. CISA issued its first emergency directive for 2024 asking federal agencies to promptly mitigate Ivanti zero-days, primarily in response to mass exploitation of these vulnerabilities by different threat actors. After all, just as of last week, Shodan listed upwards of 22,000 internet-exposed Ivanti devices, and Shadowserver tracked more than 460 compromised Ivanti VPNs as of January 30, 2024. Threat actors continue to target vulnerable devices as of today.
It might be a little known fact that one of the high severity zero-days found in Ivanti devices is actually present in an open source component that the company has deployed in its products. The average modern application contains anywhere between 128 and 500 open source dependencies, and Ivanti's proprietary products, that also use OSS components, are no exception.
Tracked as CVE-2024-21893, the Server-Side Request Forgery (SSRF) vulnerability in the SAML component used by Ivanti Connect Secure, Policy Secure, and ZTA gateways can be exploited by threat actors to access restricted resources without authentication.
Shibboleth's official advisory notes that the flaw can be exploited by threat actors including malicious content in the KeyInfo element of the input XML that gets parsed by the library. The problematic URI, in such a case, will get resolved by the shibd process resulting in either Denial of Service (DoS) and possibly "more serious vulnerabilities."
A Proof-of-Concept (PoC) exploit shared by Rapid7, for example, demonstrates how this SSRF flaw can be leveraged by threat actors who may additionally chain it with other vulnerabilities to obtain unauthenticated remote code execution (RCE) on vulnerable Ivanti Connect Secure appliances:
Shibboleth patched CVE-2023-36661 in xmltooling v3.2.4 and above last year, but warned at the time that "this issue is not specific to the V3 XMLTooling software and is believed to impact all versions prior to v3.2.4."
The project has addressed the flaw by restricting resolution of unsafe URIs present in the XML input by adding a "BlockingXSECURIResolver" class as a part of the fix, that should thwart exploits like the one shown above.
Note, fixed v3.2.4 and higher of the XMLTooling (C++) library do not (yet) exist on the Fedora/EPEL repository. As such, it may be wiser for users relying on the repository for the xmltooling component to manually incorporate the fix commit (where applicable) provided on the upstream repository to patch the flaw. According to the project, the commit may also be "in general terms applicable to V2 of the library."
Upgrading the component on Linux and similar platforms will additionally require restarting the shibd process to mitigate the flaw. Shibboleth's Service Provider Windows software v3.4.1.3 and higher also contain patched version of the library.
Security expert Will Dormann further unveiled dated open source components used by Ivanti VPN appliances as recent as 2023, hinting at other known vulnerabilities that may be exploitable in these devices.
"This is just a spot check of a few execuables on the system. I didn't even look at any of the libraries," writes Dormann. "If customers knew what they were purchasing, do you think they'd go through with the purchase? Imagine a complete SBOM for everything on the box..."
Sonatype Lifecycle users can rely on our products to ensure they receive most up to date guidance and mitigation advice on vulnerabilities impacting open source software, and keep their software development life cycle (SDLC) safe.
Ax is a Staff Security Researcher & Malware Analyst at Sonatype with a penchant for open source software. His works and expert analyses have frequently been featured by leading media outlets including the BBC. Ax's expertise lies in security vulnerability research, reverse engineering, and cybercrime investigations. He has a passion for educating a wide range of audiences through writing and vlogs.
Limit to suite:[buster][buster-updates][buster-backports][bullseye][bullseye-updates][bullseye-backports][bookworm][bookworm-updates][bookworm-backports][trixie][sid][experimental]Limit to a architecture: [alpha] [amd64] [arm] [arm64] [armel] [armhf] [avr32] [hppa] [hurd-i386] [i386] [ia64] [kfreebsd-amd64] [kfreebsd-i386] [m68k] [mips] [mips64el] [mipsel] [powerpc] [powerpcspe] [ppc64] [ppc64el] [riscv64] [s390] [s390x] [sh4] [sparc] [sparc64] [x32] You have searched for source packages that names contain xmltooling in all suites, all sections, and all architectures.Found 1 matching packages.
When logging into horizon there is an "xmltooling::IOException" error if the user tries to login with SAML Federation towards our university's Shibboleth portal. When we bypass the haproxy in the file /etc/shibboleth/shibboleth2.xml in the keystone container we do not get the error. We've had this error ever since Xena and are now on ZED.
c80f0f1006