SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
curl supports "globbing" of URLs, in which a user can pass a numerical range
to have the tool iterate over those numbers to do a sequence of transfers.
In the globbing function that parses the numerical range, there was an
omission that made curl read a byte beyond the end of the URL if given a
carefully crafted, or just wrongly written, URL. The URL is stored in a heap
based buffer, so it could then be made to wrongly read something else instead
of crashing.
An example of a URL that triggers the flaw would be
`http://ur%20[0-60000000000000000000`.
We are not aware of any exploit of this flaw.
INFO
----
This flaw only affects the curl command line tool, not the libcurl
library. The bug was introduced in commit
[5ca96cb84410270](https://github.com/curl/curl/commit/5ca96cb84410270), August
2013. curl 7.34.0.
For version 7.55.0, the parser properly stops at the end of the string and a
test has been added to verify this.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2017-1000101 to this issue.
AFFECTED VERSIONS
-----------------
- Affected versions: curl 7.34.0 to and including 7.54.1
- Not affected versions: curl < 7.34.0 and >= 7.55.1
Quote:
VULNERABILITY
-------------
When doing a TFTP transfer and curl/libcurl is given a URL that contains a
very long file name (longer than about 515 bytes), the file name is truncated
to fit within the buffer boundaries, but the buffer size is still wrongly
updated to use the untruncated length. This too large value is then used in
the `sendto()` call, making curl attempt to send more data than what is
actually put into the buffer. The `sendto()` function will then read beyond
the end of the heap based buffer.
A malicious HTTP(S) server could redirect a vulnerable libcurl-using client to
a crafted TFTP URL (if the client hasn't restricted which protocols it allows
redirects to) and trick it to send private memory contents to a remote server
over UDP. Limit curl's redirect protocols with `--proto-redir` and libcurl's
with `CURLOPT_REDIR_PROTOCOLS`.
We are not aware of any exploit of this flaw.
INFO
----
This flaw also affects the curl command line tool.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2017-1000100 to this issue.
- Affected versions: libcurl 7.15.0 to and including 7.54.1
- Not affected versions: libcurl < 7.15.0 and >= 7.55.0
Quote:
VULNERABILITY
-------------
When asking to get a file from a file:// URL, libcurl provides a feature that
outputs meta-data about the file using HTTP-like headers.
The code doing this would send the wrong buffer to the user (stdout or the
application's provide callback), which could lead to other private data from
the heap to get inadvertently displayed.
The wrong buffer was an uninitialized memory area allocated on the heap and if
it turned out to not contain any zero byte, it would continue and display the
data following that buffer in memory.
We are not aware of any exploit of this flaw.
INFO
----
This flaw also affects the curl command line tool.
The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2017-1000099 to this issue.
CVE-2016-1248 arbitrary code execution in Vim via a specially crafted text file.
CVE-2016-9273 and several vulnerabilities in libtiff that were fixed in libtiff 4.0.8 (Slackware is still on 4.0.7).
CVE-2017-3636, CVE-2017-3641 and CVE-2017-3653 all in MariaDB that allow unauthorized access of information and unauthorized inserts, deletes and updates.
CVE-2016-0634 arbitrary shell command execution as any user in Bash via a specially crafted hostname.
CVE-2017-10663 in the Linux kernel allows for arbitrary code execution in the kernel space when mounting a maliciously crafted F2FS filesystem.
CVE-2017-12424 a buffer overflow vulnerability in shadow that could result in a crash and other unspecified impacts, possible privilege escalation.
Hi Scott,
Thanks for the input!
Welcome to the dilemmas of a distro maintainer, trying to balance the demands of security against the need for intrusive updates.
My comments:
CVE-2016-1248 - Requires upstream support and has been adopted in -current. (vim is a PITA)
CVE-2016-9273 - Has been adopted in -current.
CVE-2017-3636, CVE-2017-3641 and CVE-2017-3653 - Requires upstream support and has 10.2.8 in -current.
CVE-2016-0634 - "The expansion of '\h' in the prompt string in bash 4.3 allows remote authenticated users to execute arbitrary code via shell metacharacters placed in 'hostname' of a machine." If you cannot trust remote authenticated users, then why are they trusted?
CVE-2017-10663 - In Slackware, root controls mounts.
CVE-2017-12424 - Seems like a fix is in the pipeline. https://bugs.debian.org/cgi-bin/bugr...cgi?bug=756630
I completely understand the difficulty of balancing security updates with being unintrusive to the end users' systems. This is something I have struggled with as well. I just have a couple of thoughts on your comments:
CVE-2016-1248 - There has been a patch released upstream for this: patch 8.0.0056. It can easily be applied to vim 7.4 without causing any disruption (this is what I did on Cucumber Linux).
CVE-2016-9273 - Why not backport it to 14.2 as well then? This is what happened when libtiff 4.0.7 was released.
CVE-2017-3636, CVE-2017-3641 and CVE-2017-3653 - MariaDB 10.0.32 has been released upstream and fixes these problems.
CVE-2016-0634 - I agree; in the real world this vulnerability should be very difficult to exploit. However, if the hostname is ever set via DHCP, this becomes much more exploitable. I know this doesn't usually happen, but I've always thought better safe than sorry when it comes to security.
CVE-2017-10663 - Consider the following scenario: I have a micro SD card in my phone formatted with F2FS. I want to transfer some files off it, so I put it in my laptop and mount the filesystem. Now say my phone was infected with malware and the SD card's filesystem was maliciously altered. Now that malware just managed to execute code in the kernel space on my laptop.
CVE-2017-12424 - There is a patch (commit 954e3d2e7113e9ac06632aee3c69b8d818cc8952) that fixes this. Being CVSS ranked this vulnerability as critical (a 9.8/10 severity, which is extraordinarily high), I applied the patch immediately on shadow 4.2.1 and it didn't cause any issues.
I'm having a hard time imagining how someone on stock Slackware who isn't root could go anywhere with this one.
It's listed as 9.8 on nist.gov (https://nvd.nist.gov/vuln/detail/CVE-2017-12424). Sorry, I don't always have time to check all the other databases. Also from the nist.gov entry: "This crosses a privilege boundary in, for example, certain web-hosting environments in which a Control Panel allows an unprivileged user account to create subaccounts."
certain web-hosting environments in which a Control Panel allows an unprivileged user account to create subaccounts."
... none of which are shipped in Slackware, and all of which are a lousy idea, particularly if they don't sanitize their inputs. I don't see why Patrick shouldn't have an extra hour in bed tomorrow.
My comments:
...
CVE-2017-10663 - In Slackware, root controls mounts.
Quote:
CVE-2017-10663: The sanity_check_ckpt function in fs/f2fs/super.c in the Linux kernel before 4.12.4 does not validate the blkoff and segno arrays, which allows local users to gain privileges via unspecified vectors.
Thanks to both Scott and allend for raising and replying to these items.
@allend - Is Slackware 14.2 protected from this vulnerability if /etc/fstab options include "user" or "users"? I ask because on several systems I use this fstab configuration in a limited way for convenience of mounting storage devices as a local user. I understand that this vulnerability applies only to one file system.
Perhaps one can argue that the use of user/users in fstab invites weak security or that since root controls /etc/fstab that therefore "root controls mounts".
Up to this point I've not been concerned about the use of fstab options user/users and depended upon the associated implied options of noexec, nosuid, & nodev when using user/users options. But perhaps I've misunderstood the security characteristics of user/users options.
This is a genuine question (in bold above) not a comment.
Last edited by TracyTiger; 09-01-2017 at 04:53 PM.
Reason: Added Paragraph Break
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
