LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (https://www.linuxquestions.org/questions/slackware-14/)
-   -   [Slackware security] vulnerabilities outstanding 20140101 (https://www.linuxquestions.org/questions/slackware-14/%5Bslackware-security%5D-vulnerabilities-outstanding-20140101-a-4175489800/)

gmgf 07-14-2016 03:25 AM

new gimp-2.8.18:

(We are releasing GIMP 2.8.18 to fix a vulnerability in the XCF loading code (CVE-2016-4994)

http://www.gimp.org/news/2016/07/14/...8-18-released/

http://download.gimp.org/mirror/pub/...2.8.18.tar.bz2

Thom1b 07-14-2016 12:25 PM

libgcrypt-1.7.2 is released. I don't know if security issues are fixed.

Quote:

Noteworthy changes in version 1.7.2
===================================

* Bug fixes:

- Fix setting of the ECC cofactor if parameters are specified.

- Fix memory leak in the ECC code.

- Remove debug message about unsupported getrandom syscall.

- Fix build problems related to AVX use.

- Fix bus errors on ARM for Poly1305, ChaCha20, AES, and SHA-512.

* Internal changes:

- Improved fatal error message for wrong use of gcry_md_read.

- Disallow symmetric encryption/decryption if key is not set.
ftp://ftp.gnupg.org/gcrypt/libgcrypt...-1.7.2.tar.bz2
ftp://ftp.gnupg.org/gcrypt/libgcrypt....2.tar.bz2.sig

elcore 07-15-2016 06:10 AM

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.

Thom1b 07-18-2016 09:35 PM

bind-9.10.4-P2 is released with security fix.

Quote:

Security Fixes

* 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]
ftp://ftp.isc.org/isc/bind9/9.10.4-P...10.4-P2.tar.gz

CTM 07-19-2016 11:48 AM

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.

casualfred 07-28-2016 11:12 AM

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.

For stunnel 5.35:
https://www.stunnel.org/pipermail/st...ly/000124.html

For version 5.34:
https://www.stunnel.org/pipermail/st...ly/000123.html

Thom1b 08-03-2016 04:05 AM

curl-7.50.1
 
curl-7.50.1 is released with security fixes.

https://curl.haxx.se/download/curl-7.50.1.tar.bz2
https://curl.haxx.se/download/curl-7.50.1.tar.bz2.asc

Quote:

TLS session resumption client cert bypass
=========================================

Project cURL Security Advisory, August 3rd 2016 -
[Permalink](https://curl.haxx.se/docs/adv_20160803A.html)

VULNERABILITY
-------------

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
===========================================

Project cURL Security Advisory, August 3rd 2016 -
[Permalink](https://curl.haxx.se/docs/adv_20160803B.html)

VULNERABILITY
-------------

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
===================================

Project cURL Security Advisory, August 3rd 2016 -
[Permalink](https://curl.haxx.se/docs/adv_20160803C.html)

VULNERABILITY
-------------

libcurl is vulnerable to a use-after-free flaw.

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.

Pseudo code for a bad application

easy = curl_easy_init();
curl_easy_setopt(easy, CURLOPT_URL, "http://example.com/");

// --- start of code to confuse libcurl ---
multi = curl_multi_init();
curl_multi_add_handle(multi, easy);
curl_multi_perform(multi, &still_running);
curl_multi_cleanup(multi);

// --- attack code
allocate_fake_connection_struct()
fill_in_fake_connection_struct()

// ---- end of confusion code

// now this is called, it will not use example.com at all even if the
// option above asks for it...

curl_easy_perform(easy);

This flaw can also be exploited using libcurl bindings in other languages.

We are not aware of any exploit of this flaw.

INFO
----

This flaw does not affect the curl command line tool.

The Common Vulnerabilities and Exposures (CVE) project has assigned the name
CVE-2016-5421 to this issue.

elcore 08-03-2016 08:07 AM

firefox_45.3_esr is now available

Here's a direct link to source if anyone wants to build.

jmccue 08-09-2016 08:56 PM

I am not sure what to make of this sciencedaily.com, I saw a mention in LWN and decided to to a search. I ended up doing this

Code:

# /sbin/sysctl -w net.ipv4.tcp_challenge_ack_limit=999999999
as recommended just to be safe (I am not a network expert), but putting here in case there is a real concern.

John

elcore 08-10-2016 01:38 AM

With the absence of sysctl, one could achieve this by adding a line in rc.firewall script.

Code:

echo 999999999 > /proc/sys/net/ipv4/tcp_challenge_ack_limit
However, I'm not convinced it will fully mitigate the problem, perhaps nat rules are needed in this case.
Anyway, when it doubt, -j DROP :)

slalik 08-18-2016 01:24 PM

Quote:

Originally Posted by elcore (Post 5588816)
With the absence of sysctl, one could achieve this by adding a line in rc.firewall script.

Code:

echo 999999999 > /proc/sys/net/ipv4/tcp_challenge_ack_limit
However, I'm not convinced it will fully mitigate the problem, perhaps nat rules are needed in this case.
Anyway, when it doubt, -j DROP :)

This is CVE-2016-5696, fixed in 4.4.18. Changing of tcp_challenge_ack_limit is not enough, it should be randomized.

ttk 08-19-2016 12:37 PM

Quote:

Originally Posted by slalik (Post 5592585)
This is CVE-2016-5696, fixed in 4.4.18. Changing of tcp_challenge_ack_limit is not enough, it should be randomized.

Okay, how about this then:
Code:

perl -e 'print "1".sprintf("%09d",int(rand()*1000000000))' > /proc/sys/net/ipv4/tcp_challenge_ack_limit
That assigns a random value between 1 billion and 2 billion.
Stick it in /etc/cron.hourly/scramble_challenge_ack_limit and done?

haary 08-19-2016 08:17 PM

Security risk in libgcrypt/gpg
https://lists.gnupg.org/pipermail/gn...q3/000395.html

All users should update to libgcrypt 1.7.3/gpg 1.4.21

Thom1b 09-07-2016 08:46 AM

curl-7.50.2 is released with security fixes.

https://curl.haxx.se/download/curl-7.50.2.tar.bz2
https://curl.haxx.se/download/curl-7.50.2.tar.bz2.asc

Quote:

VULNERABILITY
-------------

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!

THE SOLUTION
------------

A fix for this flaw is included in libcurl 7.50.2 via
[commit `curl-7_50_2~32`](https://github.com/curl/curl/commit/curl-7_50_2~32).
For older releases of libcurl there is a
[patch for CVE-2016-7141](https://curl.haxx.se/CVE-2016-7141.patch).

volkerdi 09-07-2016 12:35 PM

Quote:

Originally Posted by Thom1b (Post 5601862)
curl-7.50.2 is released with security fixes.

[...]

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.


All times are GMT -5. The time now is 02:31 AM.