Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Insecure Temporary Files #338

Closed
topimiettinen opened this issue Mar 1, 2019 · 47 comments

Comments

Projects
None yet
7 participants
@topimiettinen
Copy link

commented Mar 1, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 1, 2019

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

@jnpkrn

This comment has been minimized.

Copy link
Collaborator

commented Mar 4, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 5, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

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

This comment has been minimized.

Copy link
Author

commented Mar 12, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 12, 2019

PR#339

@jnpkrn

This comment has been minimized.

Copy link
Collaborator

commented Mar 22, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

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

@chrissie-c chrissie-c closed this Apr 15, 2019

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

Hi, do we need a CVE ID for this?

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

I'm still waiting for one.

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

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

This comment has been minimized.

Copy link

commented Apr 16, 2019

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

This comment has been minimized.

Copy link

commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link

commented Apr 17, 2019

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

This comment has been minimized.

Copy link

commented Apr 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@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

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@chrissie-c Just to eliminiate confusion: I did not remove the chown(), just prepended it with a chmod().

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

ahh I missed out on the ||

I don't really like that construction, it's hard to read. Could you change it to separate lines please?

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

@chrissie-c I'm no big fan of it either, just tried avoid duplicating the followup error handling logic. What about something like

if ((chmod(c->description, 0770) ||
     chown(c->description, c->auth.uid, c->auth.gid))
    && errno != EPERM) {
        res = -errno;
        goto send_response;
}

instead? Or do you prefer to ignore any error from one of the calls?

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

I'm quite happy with (void)chown(...); and a comment (splint needs the (void)).

I think things like system calls really should have their own lines, for clarity. Maybe I'm just old-school ;)

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

Well, we can put them on separate lines like above (edited)... But I'm being cautious mainly because chmod() and chown() require different capabilities (CAP_FOWNER vs. CAP_CHOWN), so chmod() can still fail after a successful chown() in principle. Not that I really expect this to happen in practice, but why not handle it if we can?
Anyway, we'd need to ignore EPERM on chmod() unless we stick to doing that first, like

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

It's also an option to pull together the error paths like

if (!mkdtemp(c->description) ||
    chmod(c->description, 0770)) {
        [...]
}

but I guess you wouldn't like that any more...

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

Thanks.

The perms are consistent with 1.0.3.

@wferi

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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

@chrissie-c

This comment has been minimized.

Copy link
Contributor

commented Apr 18, 2019

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 comment has been minimized.

Copy link
Collaborator

commented Jun 8, 2019

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

Once again, thanks for the report.

@apoleon

This comment has been minimized.

Copy link

commented Jun 14, 2019

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

This comment has been minimized.

Copy link

commented Jun 14, 2019

Should #347 also be applied?

@jnpkrn

This comment has been minimized.

Copy link
Collaborator

commented Jun 14, 2019

@wferi

This comment has been minimized.

Copy link
Contributor

commented Jun 17, 2019

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

This comment has been minimized.

Copy link
Collaborator

commented Jun 17, 2019

@gao-yan

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

@jnpkrn

This comment has been minimized.

Copy link
Collaborator

commented Jun 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.