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.
I've found there's an optional patch in firefox slackbuild:
Code:
# Patch mimeTypes.rdf
# Uncomment this if you want to use the patch; otherwise, we overwrite the
# mimeTypes.rdf inside the package directory later
Maybe it would be possible to include optional xunxun's patch the same way?
There's a github with all the patches.
Not requesting anything really, but I would use push.patch, newtab.patch and webrtc.patch if they were available since there are security issues with these features.
* getrrsetbyname with a non absolute name could trigger an infinite
recursion bug in lwresd and named with lwres configured if when
combined with a search list entry the resulting name is too long.
This flaw is disclosed in CVE-2016-2775. [RT #42694]
Someone spotted a nasty loophole in CGI (and similar) modules used by various web servers that allows attackers to remotely control the value of the HTTP_PROXY environment variable in the CGI environment, which many server-side scripts and libraries use when deciding whether outbound HTTP requests should be proxied. CVE control numbers have been assigned for httpd, PHP and Python, which are all part of Slackware.
The Apache Software Foundation has released a response, which essentially advises the insertion of the following lines into httpd.conf to unset the "Proxy" header in HTTP requests before processing them with mod_{cgi,php,python}:
Code:
LoadModule headers_module lib64/httpd/modules/mod_headers.so
RequestHeader unset Proxy early
(mod_headers is already loaded by default in Slackware 14.1 and above, possibly earlier stable releases too, so the first line isn't necessary for us.)
This should be a straightforward change that doesn't break existing webapps, since none of them should be relying on the value of a "Proxy" header in HTTP requests in the first place.
It looks like there have been one or two security bugfix releases for stunnel in the past few weeks. The page says they have an urgency of "High." The latest version of stunnel is 5.35.
libcurl would attempt to resume a TLS session even if the client certificate
had changed. That is unacceptable since a server by specification is allowed
to skip the client certificate check on resume, and may instead use the old
identity which was established by the previous certificate (or no
certificate).
libcurl supports by default the use of TLS session id/ticket to resume
previous TLS sessions to speed up subsequent TLS handshakes. They are used
when for any reason an existing TLS connection couldn't be kept alive to make
the next handshake faster.
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-2016-5419 to this issue.
Quote:
Re-using connections with wrong client cert
===========================================
libcurl did not consider client certificates when reusing TLS connections.
libcurl supports reuse of established connections for subsequent requests. It
does this by keeping a few previous connections "alive" in a connection pool
so that a subsequent request that can use one of them instead of creating a
new connection will do so.
When using a client certificate for a connection that was then put into the
connection pool, that connection could then wrongly get reused in a subsequent
request to that same server that either didn't use a client certificate at all
or that asked to use a different client certificate thus trying to tell the
user that it is a different entity.
This mistakenly using the wrong connection could of course lead to
applications sending requests to the wrong realms of the server using
authentication that it wasn't supposed to have for those operations.
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-2016-5420 to this issue.
Quote:
use of connection struct after free
===================================
libcurl works with easy handles using the type 'CURL *' that are objects the
application creates using curl_easy_init(). They are the handles that are all
each associated with a single transfer at a time. libcurl also has an internal
struct that represents and holds most state that is related to a single
connection. An easy handle can hold references to one or many such connection
structs depending on the requested operations.
When using libcurl's multi interface, an application performs transfers by
adding one or more easy handles to the multi handle and then it can drive all
those transfers in parallel.
Due to a flaw, libcurl could leave a pointer to a freed connection struct
dangling in an easy handle that was previously added to a multi handle when
curl_multi_cleanup() is called with an easy handle still added to it. This
does not seem to cause any notable harm if the handle is then closed properly.
However, if the easy handle would instead get used again with the easy
interface and curl_easy_perform() to do another transfer, it would blindly use
the connection struct pointer now pointing to freed memory.
An application could be made to allocate its own fake version of the connect
struct, fill in some data and then have the curl_easy_perform() call do
something that clearly was not intended by the original code.
For example, this could be an application using a component or library that
uses libcurl to do something against fixed URLs or fixed host names or with a
set of fixed options, but using this flaw the application can then make the
component to do something completely different and unintended.
libcurl built on top of NSS (Network Security Services) incorrectly re-used
client certificates if a certificate from file was used for one TLS connection
but no certificate set for a subsequent TLS connection.
While the symptoms are similar to CVE-2016-5420 (Re-using connection with wrong
client cert), this vulnerability was caused by an implementation detail of the
NSS backend in libcurl, which is orthogonal to the cause of CVE-2016-5420.
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-2016-7141 to this issue.
AFFECTED VERSIONS
-----------------
This flaw is present in curl and libcurl only if they are built with the
support for NSS and only if the libnsspem.so library is available at run-time.
- Affected versions: libcurl 7.19.6 to and including 7.50.1
- Not affected versions: libcurl >= 7.50.2
libcurl is used by many applications, but not always advertised as such!
This flaw is present in curl and libcurl only if they are built with the
support for NSS and only if the libnsspem.so library is available at run-time.
Curl in Slackware is not built against NSS, nor is the libnsspem.so library available. Not vulnerable.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.