On 1/19/26 1:21 AM, Robert Howard wrote:
On 1/18/26 9:32 AM, G.W. Haywood wrote:
Hi there,
On Sat, 17 Jan 2026, jbk wrote:
... thoughts / questions on the zlib CVE.
Can we be specific about which CVE?
There are two path's of vulnerability for the BackupPC
server. One
is the distro installed zlib and the other is the zlib
bundled in
BackupPC to date.
Assuming that you're restricting your consideration of
vulnerabilities
to those in zlib and the zlib bundled by BackupPC, then
yes. Although
the subject is "BackupPC-XS ...", to date not only
BackupPC-XS but the
original rsync and rsync-bpc *also* bundle zlib. So, I
gather, do a
number of other packages. As far as rsync-bpc is
concerned I'm in the
midst of dealing with it - see below.
The distro installed zlib supposedly will be patched
soon, not as of
yet. Anyone who has access to this server could avail
themselves of
the vulnerability till it is patched.
Are all the big distros not all up to speed with zlib
patches? That
may beg the questions (a) which distro? and (b) to whom
do you permit
what kinds of access to your backup server?
Once it is patched then the only users who have access
to the
bundled zlib are those trusted BackupPC admin users.
The client
users shouldn't have direct access to the bundled zlib,
correct?
I'm not sure that I follow.
To make use of flaws in the bundled zlib library, direct
access to the
bundled library is not a requirement. If (and *only* if)
(1) BackupPC
is linked with the vulnerable library and (2) there's
some way for an
attacker to get a vulnerable function called, all the
attacker must do
is somehow arrange for BackupPC to pipe through zlib data
which our
attacker has somehow contrived to cause BackupPC to make
a call to the
vulnerable function (and for this call to do something of
use to the
attacker, but that's his problem).
In the case of BackupPC I'm not sure how easy it would be
to arrange
for these conditions to be met, but it could
theoretically be achieved
by getting BackupPC to back up or recover a crafted
file. (If users
can e.g. run a compiler on the server they can
alternatively download
vulnerable code (any vulnerable code, not just zlib) and
build it.
Then they can do what they like with it. I've done that
for example
to hack into a Debian box when the owner forgot the root
password.
Just trying to get an idea of the risk level for the
bundled zlib.
In my view, if you're running a vulnerable zlib it's low
if you're
(otherwise) sane - but since compiling the bundled zlib
in the first
place is optional, avoiding the risk seems trivial.
FWIW I think I'm very close to releasing rsync-bpc
version 3.4.1.0rc1,
which is hopefully going to put this one to bed at last
for BackupPC.
The new version will use both the system zlib and the
system popt and
will bundle neither.
The CVE is https://www.cve.org/CVERecord?id=CVE-2026-22184
and marked disputed. See also
https://www.openwall.com/lists/oss-security/2026/01/06/5
This was patched very quickly by some distributions even
though the problem is not in zlib. This is a bug in a
*contibuted reference program* demonstrating how to use
zlib. This is not a problem in zlib itself.
See the thread at https://github.com/madler/zlib/issues/1142
Ged,
I didn't really know how to craft a concise question but
your response put things in context for me. The CVE I was
refering to was linked in R. Shaw's email that you responded
to up thread, but that linked to RHEL's global response to
all it's zlib related package maintainers which quoted a
portion of the original CVE on zlib.
Per R. Howard's post here it appears not to be an issue at all.
I did try to hunt for that function call in the bundled zlib
source and I couldn't find it and now I know why.
--
Jim KR
_______________________________________________
BackupPC-users mailing list
[email protected]
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: https://github.com/backuppc/backuppc/wiki
Project: https://backuppc.github.io/backuppc/
