Insecure Temporary Files

[topimiettinen]

Libqb creates files in world-writable directories (/dev/shm, /tmp) with rather predictable file names (e.g. /dev/shm/qb-usbguard-request-7096-835-12-data in case of USBGuard). Also O_EXCL flag is not used when opening the files. This could be exploited by a local attacker to overwrite privileged system files (if not restricted by sandboxing, MAC or symlinking policies).

At least O_EXCL flag should be used. I'd also use more complex logic where files are created with unpredictable names (also using O_TMPFILE) and then possibly renamed to match file naming convention (if the protocol does not allow completely random file names). I would not use files for IPC.

[topimiettinen]

I've opened issue USBGuard/usbguard#277 for USBGuard.

[jnpkrn]

Thank you very much, Topi, for taking time to report this, initiating
hence a wider investigation.

(Cat is out of the bag by now, and GitHub cannot make the issues private
anyway, AFAIK.)

TBH, this got me really worried that I should have pursued the initial
suspicion at the first opportunity (not very trivial counterproof in
the legacy -- as in the original authors no longer around -- software
where the consequences of a change may not be straightforward was one
of the inhibitors), and sadly, this indeed has bad implications
(for anyone, whenever you suspect something like that, please follow
https://wiki.clusterlabs.org/wiki/Security#Reporting that's the best
genetic way to report things like that, since there's no particular
contact is dedicated for dealing with handling such reports within
the scope of ClusterLabs projects incl. libqb).

Regarding the possible quick workaround at the client side, commented
(with negative statement) at mentioned USBGuard/usbguard#277.

What works with Linux kernel 4.19+ (or perhaps through distro backports)
instantly, though is:

cat /proc/sys/fs/protected_regular && echo 1 > /proc/sys/fs/protected_regular

This is deemed a good enough immediate workaround where supported
(for instance, systemd installation may enable this by default,
as is the case with Fedora).

Patch following the suggestion above to come once several things gets
considered (alternative is to enclose the files into a dedicated,
assurably unique and well guarded subdir of /dev/shm).

[topimiettinen]

In addition to fs.protected_regular, I'd also use related sysctls

fs.protected_fifos = 1
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

It would be a good idea to mention the security reporting link on Github front page README.markdown and also ClusterLabs libqb page. The security page itself mentions encrypted email but no email address is actually given.

[jnpkrn]

We don't use FIFOs (anywhere in the cluster stack but some resource
agents using mkfifo(1), for that matter), but agree that catching all
at once is sensible, and following the indirections could also cause
troubles here.

[jnpkrn]

Regarding the hints, yes, we were likely resting on our laurels, hence
not much pro-activity there (or past reports), in part because of there's
no single point of absolute authority due to many parties involved, and
no one is appointed the central contact for security related reports
either, as mentioned. So the intuitive options while retaining some
limited confidentiality:

If I can speak for the vendor side, for instance Red Hat has this:
https://access.redhat.com/security/team/contact/

Distro representatives surely scan distros list and would notify
us eventually:
https://oss-security.openwall.org/wiki/mailing-lists/distros

Last but not least, you can get the idea of who is maintaining this
project from the commit history and notify these people privately,
especially since you can find the respective OpenPGP keys on
common key servers.

All these could be done in parallel, though I agree it is perhaps
asking too much and some explicitly announced arrangement for these
purposes might work better.

[jnpkrn]

FWIW. there are many tightly coupled considerations regarding the
specificity of IPC inner details (which could partially alleviate also
in this very regard), e.g., see the last point of
#222 (comment)

[wferi]

Wouldn't adding O_EXCL here and there fix the immediate vulnerability? Then we could still think about not reimplementing the POSIX shared memory API as per #222.

[chrissie-c]

wferi: I'm working on a patch that adds O_EXCL to the files and also adds a random number suffix to the names. That should help the worst of the problems.

[topimiettinen]

Adding just O_EXCL helps with the overwrite, but it would still allow a local user to fill /dev/shm with files with matching pattern, which would then prevent libqb from working properly, i.e. denial of service attack. Unpredictable (random and never reused) file names (or directory with random name) would prevent that.

[chrissie-c]

PR#339

[jnpkrn]

Alternative is #343

Btw. when this double-problem gets sufficiently fixed, following can be
reverted (sigh!): #150

EDIT: only if filesystem sockets are enforced and build-time configured
to use unique paths for that, but that's solely a workaround for abstract
Unix sockets, whereas it could have previously been also a stomping on
/dev/shm/qb-* files -- this is what will get eliminated one way or
another.

[chrissie-c]

release v1.0.4 includes O_EXCL when opening files and uses files in mkdtemp to create them in directories under /dev/shm

[wferi]

Hi, do we need a CVE ID for this?

[chrissie-c]

I'm still waiting for one.

[wferi]

Since I upgraded to libqb 1.0.4 Pacemaker experiences problems:

pacemaker-based[1581]:  error: Error in connection setup (/dev/shm/qb-1581-1807-11-dPlhQ1): Unknown error -1 (-1)

Connection to the CIB is impossible:

# crm_resource 
Error connecting to the CIB manager: Transport endpoint is not connected
Error performing operation: Transport endpoint is not connected

Here's my /dev/shm:

drwx------ 2 root      root         160 Apr 16 13:33 qb-1418-1579-31-u62Y2g
drwx------ 2 root      root         160 Apr 16 13:33 qb-1418-1579-32-dRdtjI
drwx------ 2 root      root         160 Apr 16 13:33 qb-1418-1579-33-wm7hc2
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1418-1581-36-KpzR6e
drwx------ 2 root      root         160 Apr 16 13:33 qb-1418-1582-34-eMhagm
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1418-1584-35-GU4Ceo
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1418-1787-37-9ee7X7
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1418-1787-38-avsDTX
drwx------ 2 hacluster haclient      40 Apr 16 13:33 qb-1581-1582-11-Fi7bVg
drwx------ 2 hacluster haclient      40 Apr 16 13:33 qb-1581-1582-11-SxgVPa
drwx------ 2 hacluster haclient      40 Apr 16 13:33 qb-1581-1582-11-TEJoNt
drwx------ 2 hacluster haclient      40 Apr 16 13:33 qb-1581-1582-11-tWFomy
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1581-1584-9-nkdYav
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1581-1787-10-a4vhgD
drwx------ 2 hacluster haclient      40 Apr 16 13:34 qb-1581-1807-11-dPlhQ1
drwx------ 2 hacluster haclient      40 Apr 16 13:34 qb-1581-1808-11-bIniDs
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1582-1787-7-b62eEB
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1583-1787-6-eels7v
drwx------ 2 hacluster haclient     160 Apr 16 13:33 qb-1585-1787-6-coneG1
-rw------- 1 root      root     8392704 Apr 16 13:33 qb-corosync-1418-blackbox-data
-rw------- 1 root      root        8248 Apr 16 13:33 qb-corosync-1418-blackbox-header

pacemaker-based is running as user hacluster.
I'd be grateful for some guidance. Let's mention @kgaillot in case he does not monitor this project.
Thanks.

[chrissie-c]

Hmm I'm not sure what's happening there, it worked in testing. I'm off tomorrow so it'll have to wait till Thursday at least. sorry. I did notice that the directories are 0700 and should be 0770 (so there's a chmod missing in the patch) but that doesn't fix it so there's something else happening too.

[vvidic]

Strace gives me this:

openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-request-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-request-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-response-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-response-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-event-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-14179-16247-10-tyW3K8/qb-event-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-p\3\376a\302U", O_RDWR) = -1 ENOENT (No such file or directory)

The path on the last one seems to be mangled compared to the previous libqb version:

openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-request-2122-2505-10-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-request-2122-2505-10-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-response-2122-2505-10-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-response-2122-2505-10-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-event-2122-2505-10-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-stonith-ng-event-2122-2505-10-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-request-2121-2505-13-header", O_RDWR) = 6
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-request-2121-2505-13-data", O_RDWR) = 7
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-response-2121-2505-13-header", O_RDWR) = 6
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-response-2121-2505-13-data", O_RDWR) = 7
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-event-2121-2505-13-header", O_RDWR) = 6
openat(AT_FDCWD, "/dev/shm/qb-cib_ro-event-2121-2505-13-data", O_RDWR) = 7

[vvidic]

Strange enough now I get a different listing now:

openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-request-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-request-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-response-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-response-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-event-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-20847-30556-10-x7VLSq/qb-event-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-20846-20849-11-mRfvu4/qb-request-cib_rw-header", O_RDWR) = -1 ENOENT (No such file or directory)

[wferi]

@vvidic, that first trace looks like memory corruption, can you reproduce it?
@chrissie-c, the problem is that Pacemaker isn't running as root, so the chown() call fails with EPERM and connection setup is aborted. Additionally there are sign errors in the error propagation, so we get "Unknown error -1" in the logs instead.

[vvidic]

Not always but now it seems to appear again:

root@sid1:~# strace crm_mon -1 2>&1 | grep openat | grep shm
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-request-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-request-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-response-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-response-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-event-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2178-10-R6A9cJ/qb-event-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-\20\22\270^\364U", O_RDWR) = -1 ENOENT (No such file or directory)

root@sid1:~# strace crm_mon -1 2>&1 | grep openat | grep shm
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-request-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-request-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-response-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-response-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-event-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2184-10-i8FLxE/qb-event-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-\20\22\270^\364U", O_RDWR) = -1 ENOENT (No such file or directory)

root@sid1:~# strace crm_mon -1 2>&1 | grep openat | grep shm
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-request-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-request-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-response-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-response-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-event-stonith-ng-header", O_RDWR) = 4
openat(AT_FDCWD, "/dev/shm/qb-925-2190-10-XrkknB/qb-event-stonith-ng-data", O_RDWR) = 5
openat(AT_FDCWD, "/dev/shm/qb-\20\22\270^\364U", O_RDWR) = -1 ENOENT (No such file or directory)

[vvidic]

Just for the info this is libqb0 1.0.4-1 with pacemaker 2.0.1-2 all from Debian unstable.

Also uploading the full strace in case someone can read the binary protocol: crm_mon.strace.gz

[wferi]

@vvidic Strangely, I can't reproduce this corruption. It might be a mishandled/ignored error on the client side. I can see lots of interesting things in the pacemaker startup logs, though, like

pacemaker-based[4578]:  error: Error in connection setup (/dev/shm/qb-4578-4579-11-fBzgsq): Unknown error -1 (-1)
pacemaker-fenced[4579]:  error: couldn't open file /dev/shm/qb-: No such file or directory (2)
pacemaker-fenced[4579]:  error: couldn't open file /tmp/: Is a directory (21)
pacemaker-fenced[4579]:  error: couldn't open file for mmap: Is a directory (21)

It's worth noting that we configure libqb --with-socket-dir=/tmp.
However, all problems disappear if I apply the patches in #347. I uploaded the package to deb http://apt.niif.hu/debian unstable main in case you want to give it a spin.

[vvidic]

@wferi Yes, it seems to behave a bit different every time I boot the VM or restart pacemaker. I also see these errors in the logs so it might be that after the error pacemaker gets some random data from memory into this string?

Installing the libqb0_1.0.4-2_amd64.deb from your repo fixes the problem for me too.

[wferi]

@vvidic The sign mistake made pacemaker-based send back a positive response.hdr.error value (1 instead of -1, which is -EPERM) from handle_new_connection(), so qb_ipcc_connect() in the client didn't abort early, but passed down the largely uninitialized response structure to its helpers, who expected filenames in it.

[chrissie-c]

@wferi @vvidic Thank you. PR#348 seems to work for me.

[wferi]

@chrissie-c Have you seen PR#347? I think those signs should be fixed as well for correct propagation of errors.

[chrissie-c]

@wferi Apologies, I did not. That looks better to me, I'll put the chown back in there (for corosync), and give it some testing

[chrissie-c]

I was thinking of

/* chown can fail because we might not be root */
 (void)chown(c->description, c->auth.uid, c->auth.gid);
 if ((chmod(c->description, 0770)
     && errno != EPERM) {
         res = -errno;
         goto send_response;
}

Is there something I've missed?

[wferi]

I think chmod() can't fail with EPERM right after the mkdtemp(), but it can after a successful chown(), if the process has CAP_CHOWN only.

[chrissie-c]

ahh fair enough I hadn't realised that. So the first of your two options above makes best sense to me now then

[wferi]

OK, I replaced those commits. Now Pacemaker works and all directories under /dev/shm have mode 0770. The file modes are mixed, though:

# ls -lR /dev/shm/qb-1593-159?-1*
/dev/shm/qb-1593-1594-11-JsW85M:
total 1584
-rw------- 1 hacluster haclient 528384 Apr 18 13:11 qb-event-cib_rw-data
-rw------- 1 hacluster haclient   8248 Apr 18 13:11 qb-event-cib_rw-header
-rw------- 1 hacluster haclient 528384 Apr 18 13:11 qb-request-cib_rw-data
-rw------- 1 hacluster haclient   8252 Apr 18 13:11 qb-request-cib_rw-header
-rw------- 1 hacluster haclient 528384 Apr 18 13:11 qb-response-cib_rw-data
-rw------- 1 hacluster haclient   8248 Apr 18 13:11 qb-response-cib_rw-header

/dev/shm/qb-1593-1599-10-i7oabl:
total 1584
-rw-rw---- 1 hacluster haclient 528384 Apr 18 13:11 qb-event-cib_shm-data
-rw-rw---- 1 hacluster haclient   8248 Apr 18 13:11 qb-event-cib_shm-header
-rw-rw---- 1 hacluster haclient 528384 Apr 18 13:11 qb-request-cib_shm-data
-rw-rw---- 1 hacluster haclient   8252 Apr 18 13:11 qb-request-cib_shm-header
-rw-rw---- 1 hacluster haclient 528384 Apr 18 13:11 qb-response-cib_shm-data
-rw-rw---- 1 hacluster haclient   8248 Apr 18 13:11 qb-response-cib_shm-header

Is this expected?

[chrissie-c]

Thanks.

The perms are consistent with 1.0.3.

[wferi]

True, so I suppose it's OK then.
Do you know why the CI fails?

[chrissie-c]

Not precisely. The libqb tests are a constant thorn on my side. Mostly they're failing with
16:43:13 make[4]: Leaving directory '/srv/workspace/libqb-build-all-voting/libqb-build-all-voting/debian-testing-x86-64/libqb-1.0.4.6-e3a8/_build/sub/tests/functional/log_external'
16:43:13 mkdir: cannot create directory ‘.deps’: File exists

rather than anything 'real'. It's one of the, many, reasons I got rid of the linker sections for 2.0. But we'll have to live with that for a little while yet.

[jnpkrn]

This problem (as initially disclosed here) has been assigned
CVE-2019-12779.

Once again, thanks for the report.

[apoleon]

I'm currently investigating whether version 0.11 in Debian 8 "Jessie" is vulnerable. Am I correct that the following commit is the fixing commit for CVE-2019-12779 6a4067c

[apoleon]

Should #347 also be applied?

[jnpkrn]

On 14/06/19 14:02 -0700, Markus Koschany wrote: Should #347 also be applied?

Definitely, at least if you want to have the cluster stack functional.

…

-- Jan (Poki)

[wferi]

Can we say that setting both fs.protected_hardlinks and fs.protected_symlinks to 1 fully mitigates this problem? (That's the only supported configuration since Debian jessie.)

[jnpkrn]

On 17/06/19 01:45 -0700, wferi wrote: Can we say that setting both `fs.protected_hardlinks` and `fs.protected_symlinks` to 1 fully mitigates this problem? (That's the only supported configuration since Debian jessie.)

I'd be very cautious to call that an unconditional closing of the gap, since there are effectively more vectors pertaining this problem. AFAICT, `fs.protected_*links` would only resolve "powers roundtrip" attacks, like said overwriting of privileged files in case a privileged IPC server is tricked into that (talking about the situation prior to the `O_EXCL` fix). OTOH, it doesn't fix eavesdropping and possibly and/or active mangling with the channel (most likely with DoS effect, crafted diversion is unlikely [for more shared resources, namely semaphores, involved], but wasn't disproved either) venues coming with the vulnerability at hand.

…

-- Jan (Poki)

[gao-yan]

On 6/14/19 11:47 PM, Jan Pokorný wrote: On 14/06/19 14:02 -0700, Markus Koschany wrote: > Should #347 also be > applied? Definitely, at least if you want to have the cluster stack functional.

I think it should be #349, right? Any reason why it doesn't seem to be in the master branch?

[jnpkrn]

On 18/06/19 07:17 -0700, Gao,Yan wrote: On 6/14/19 11:47 PM, Jan Pokorný wrote: > On 14/06/19 14:02 -0700, Markus Koschany wrote: > > Should #347 also be > > applied? > > Definitely, at least if you want to have the cluster stack functional. I think it should be #349, right?

my bad, was familiar enough ... hopefully this line of progress over PR iterations (as commented on) naturally follows

Any reason why it doesn't seem to be in the master branch?

Ah, good spot, it wasn't intentional I am sure.

…

-- Jan (Poki)

[rcsanchez97]

Hello all. I am working on an update of libqb in Debian 8. The libqb package in that Debian release is somewhat old, being at version 0.11.1. I have adapted what I believe are the three relevant commits from the version_1 branch: 269a0ca, f950a5d, 1699bf4 (the last being a commit from #349 while the others in that PR do not seem to apply to the older version). I have done my best to understand the issues at hand and the fixes made so that I could adapt those commits to the older 0.11.1 version of libqb. If someone could review the patches I have prepared, it would be very much appreciated. Incidentally, if I should open a new issue for this request, please let me know and I will do so.

01_CVE-2019-12779_1_of_3.txt
02_CVE-2019-12779_2_of_3.txt
03_CVE-2019-12779_3_of_3.txt

If these patches look correct, then I will proceed with updating the package in Debian 8. Otherwise, I will make whatever corrections or adjustments are needed.

[vvidic]

On Mon, Nov 11, 2019 at 07:54:07AM -0800, Roberto C. Sánchez wrote: Hello all. I am working on an update of libqb in Debian 8. The libqb package in that Debian release is somewhat old, being at version 0.11.1. I have adapted what I believe are the three relevant commits

I suppose you mean version 1.0.1-1 of the Debian package? Probably best to contact wferi since he was working on libqb fixes for Debian.

…

-- Valentin

[rcsanchez97]

@vvidic No, I am in fact referring to version 0.11.1-2 in Debian 8 "jessie," which is supported by the LTS team.

[vvidic]

On Mon, Nov 11, 2019 at 08:31:38AM -0800, Roberto C. Sánchez wrote: @vvidic No, I am in fact referring to version 0.11.1-2 in Debian 8 "jessie," which is supported by the LTS team.

Ah, you are right, I was looking at Debian 9.

…

-- Valentin

[rcsanchez97]

No problem. When the versions are closer we oftentimes coordinate between the LTS team and the stable security team. However, the versions involved in this case are quite far apart.

[wferi]

Hello all. I am working on an update of libqb in Debian 8.

What uses libqb in Debian 8?

The libqb package in that Debian release is somewhat old, being at version 0.11.1. I have adapted what I believe are the three relevant commits from the version_1 branch: 269a0ca, f950a5d, 1699bf4

I think you'd need the chown patch and at least the error handling fix from #349 as well. The buffer overflow parts may not apply to 0.11, I can't check it now.

[rcsanchez97]

On Mon, Nov 11, 2019 at 03:10:57PM -0800, wferi wrote: What uses libqb in Debian 8?

It would appear that nothing in the archive depends on it: root@build01:/# apt-cache rdepends libqb0 libqb0 Reverse Depends: libqb-dev root@build01:/# apt-cache rdepends libqb-dev libqb-dev Reverse Depends: root@build01:/#

I think you'd need the chown patch and at least the error handling fix from [4]#349 as well. The buffer overflow parts may not apply to 0.11, I can't check it now.

For the chown patch, I was not able to find a place where the change was applicable. I do not recall why I excluded the error handling fix. I will take another look.

[rcsanchez97]

@wferi I have taken another look and the reason I left out the chown and error handling patches is because my adaptation did not contain the part of f950a5d to which those further changes apply. It seems like the absence of c->description in the older libqb makes the changes to handle_new_connection in f950a5d not applicable. That said, I am left with two questions:

1. Given my observation relative to the part of f950a5d not being applicable, am I mistaken such that there is a correct way to adapt that change that I have overlooked?
2. Returning to your earlier question about what uses libqb in Debian, since it is a leaf package, would it be more prudent to simply drop support for it so that the LTS team does not spend time and effort supporting a package that "nobody" uses?

[wferi]

I see, shared memory IPC changed much since 0.11. I don't think it's worth spending effort on fixing this issue in Debian 8; anybody using it there must have used the 0.17 or 1.0 backport instead. Unfortunately jessie-backports is closed, so we can't do anything for them now.

[rcsanchez97]

@wferi Thank you for the assessment. Your insight on this matter is appreciated.

[chrissie-c]

Yes, I think you'll have trouble backporting that patch to 0.11. libqb is only used for corosync 2.0 onwards so I'm not really surprised that it has no reverse dependancies

[rcsanchez97]

I brought this up to the team and we are going ahead with dropping support for libqb in Debian 8 "jessie". Thank you to all for the help and guidance on this.

[hartwork]

Hi! Is my understanding correct that this issue was fixed by 6a4067c for releases >=1.9.0?

[chrissie-c]

@hartwork That's correct

[hartwork]

@chrissie-c thank you! 👍