LinuxQuestions.org
Page 37 of 65 « First 273536 37 383947 Last »
Show 50 post(s) from this thread on one page

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/)

Thom1b 09-07-2016 11:48 AM
Quote:
Originally Posted by volkerdi (Post 5601959)
Curl in Slackware is not built against NSS, nor is the libnsspem.so library available. Not vulnerable.
OK, thanks for your reply.

Thom1b 09-14-2016 02:25 AM
curl-7.50.3 is released with security fix.
 
I hope my post will be useful this time :D

curl-7.50.3 is released with a security fix.

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

Quote:
curl escape and unescape integer overflows
==========================================

Project cURL Security Advisory, September 14, 2016 -
[Permalink](https://curl.haxx.se/docs/adv_20160914.html)

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

The four libcurl functions `curl_escape()`, `curl_easy_escape()`,
`curl_unescape` and `curl_easy_unescape` perform string URL percent escaping
and unescaping. They accept custom string length inputs in signed integer
arguments. (The functions having names without "easy" being the deprecated
versions of the others.)

The provided string length arguments were not properly checked and due to
arithmetic in the functions, passing in the length 0xffffffff (2^32-1 or
`UINT_MAX` or even just -1) would end up causing an allocation of zero bytes
of heap memory that curl would attempt to write gigabytes of data into.

The use of 'int' for this input type in the API is of course unwise but has
remained so in order to maintain the API over the years.

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-7167 to this issue.

AFFECTED VERSIONS
-----------------

This flaw exists in the following libcurl versions.

- Affected versions: libcurl 7.11.1 to and including 7.50.2
- Not affected versions: libcurl < 7.11.1 and libcurl >= 7.50.3

libcurl is used by many applications, but not always advertised as such!

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

In version 7.50.3, these functions will deny negative string lengths from
being used.

A [patch for CVE-2016-7167](https://curl.haxx.se/CVE-2016-7167.patch) is
available.

Cesare 09-21-2016 04:32 PM
irssi 0.8.20 has been released with fixes for CVE-2016-7044 and CVE-2016-7045.

Quoting https://irssi.org/2016/09/21/irssi-0.8.20-released/
Quote:
Irssi 0.8.20 has been released. This release fixes two remote crash issues in Irssi 0.8.17 and later. There are no new features. All users should upgrade to this version. See the NEWS for details.

cwizardone 09-21-2016 06:29 PM
Here you go:

Quote:
Wed Sep 21 21:10:52 UTC 2016
n/irssi-0.8.20-x86_64-1.txz: Upgraded.
This update fixes two remote crash and heap corruption vulnerabilites
in Irssi's format parsing code. Impact: Remote crash and heap
corruption. Remote code execution seems difficult since only Nuls are
written. Bugs discovered by, and patches provided by Gabriel Campana
and Adrien Guinet from Quarkslab.
For more information, see:
https://irssi.org/security/irssi_sa_2016.txt
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2016-7044
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2016-7045
(* Security fix *)
+--------------------------+

mats_b_tegner 09-23-2016 07:13 AM
php 5.6.26
 
Several security related fixes:
https://secure.php.net/ChangeLog-5.php#5.6.26

OldHolborn 09-25-2016 09:51 AM
Kernel 4.4.22

http://lkml.iu.edu/hypermail/linux/k...9.3/00082.html

commit ad3817096cf97fad790f45a38c53d5bb39c1b5be
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Thu Aug 18 20:54:02 2016 -0400

frv: fix clear_user()

commit 3b8767a8f00cc6538ba6b1cf0f88502e2fd2eb90 upstream.

It should check access_ok(). Otherwise a bunch of places turn into
trivially exploitable rootholes.

mats_b_tegner 09-25-2016 10:36 AM
Quote:
Originally Posted by OldHolborn (Post 5609842)
4.4.22 is already in -current. Maybe you should ask Pat V to upgrade the kernel in -stable as well?

Mats

OldHolborn 09-25-2016 11:11 AM
That's why it was pointed out...

hj1967 10-03-2016 09:23 AM
Currently Slackware has openjpeg 2.1.0. In July Openjpeg 2.1.1 was released and in September Openjpeg 2.1.2.
Both contain fixes for bad files that could result in crashes.

For more info see: https://github.com/uclouvain/openjpe...1/CHANGELOG.md

cwizardone 10-04-2016 10:21 AM
X.Org security advisory: Protocol handling issues in X Window System client libraries
 
"X.Org security advisory: Protocol handling issues in X Window System client libraries."

Quote:
Affected libraries and CVE Ids

libX11 - insufficient validation of data from the X server
can cause out of boundary memory read (XGetImage())
or write (XListFonts()).
Affected versions libX11 <= 1.6.3

libXfixes - insufficient validation of data from the X server
can cause an integer overflow on 32 bit architectures.
Affected versions : libXfixes <= 5.0.2

libXi - insufficient validation of data from the X server
can cause out of boundary memory access or
endless loops (Denial of Service).
Affected versions libXi <= 1.7.6

libXrandr - insufficient validation of data from the X server
can cause out of boundary memory writes.
Affected versions: libXrandr <= 1.5.0

libXrender - insufficient validation of data from the X server
can cause out of boundary memory writes.
Affected version: libXrender <= 0.9.9

XRecord - insufficient validation of data from the X server
can cause out of boundary memory access or
endless loops (Denial of Service).
Affected version libXtst <= 1.2.2

libXv - insufficient validation of data from the X server
can cause out of boundary memory and memory corruption.
CVE-2016-5407
affected versions libXv <= 1.0.10

libXvMC - insufficient validation of data from the X server
can cause a one byte buffer read underrun.
Affected versions: libXvMC <= 1.0.9
Full article here, https://lists.freedesktop.org/archiv...er/058344.html

cwizardone 10-20-2016 10:17 AM
The 4.4.26 kernel has been released to address a security issue.

The change log, https://cdn.kernel.org/pub/linux/ker...angeLog-4.4.26

Quote:
commit 4ad454918b1a7e4cccb373d3b1034052c49f6105
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Thu Oct 20 10:01:03 2016 +0200

Linux 4.4.26

commit 1294d355881cc5c3421d24fee512f16974addb6c
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Thu Oct 13 13:07:36 2016 -0700

mm: remove gup_flags FOLL_WRITE games from __get_user_pages()

commit 19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619 upstream.

This is an ancient bug that was actually attempted to be fixed once
(badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
get_user_pages() race for write access") but that was then undone due to
problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

In the meantime, the s390 situation has long been fixed, and we can now
fix it by checking the pte_dirty() bit properly (and do it better). The
s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
software dirty bits") which made it into v3.9. Earlier kernels will
have to look at the page state itself.

Also, the VM has become more scalable, and what used a purely
theoretical race back then has become easier to trigger.

To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
we already did a COW" rather than play racy games with FOLL_WRITE that
is very fundamental, and then use the pte dirty flag to validate that
the FOLL_COW flag is still valid.

Reported-and-tested-by: Phil "not Paul" Oester <kernel@linuxace.com>
Acked-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Michal Hocko <mhocko@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Nick Piggin <npiggin@gmail.com>
Cc: Greg Thelen <gthelen@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

cwizardone 10-21-2016 10:35 AM
More information about the security problem mentioned above, aka, "dirty cow," can be found here,

https://www.linuxquestions.org/quest...it-4175591915/

cwizardone 10-27-2016 11:29 AM
POINTYFEATHER / tar extract pathname bypass (CVE-2016-6321)

Quote:
CVE-2016-6321 - GNU tar extract pathname bypass
===============================================
The latest version of this advisory is available at:
https://sintonen.fi/advisories/tar-e...ass.proper.txt

Overview
--------
GNU `tar' archiver can be tricked into extracting files and directories in the given destination, regardless of the path name(s) specified on the command line.

Description
-----------
GNU `tar' archiver attempts to avoid path traversal attacks by removing offending parts of the element name at extract. This sanitizing leads to a vulnerability where the attacker can bypass the path name(s) specified on the command line.

Impact
------
The attacker can create a crafted tar archive that, if extracted by the victim, replaces files and directories the victim has access to in the target directory, regardless of the path name(s) specified on the command line.

Details
-------
The discovered vulnerability, described in more detail below, enables file and directory overwrite attacks against the user or system by using a crafted tar archive. The attack requires that the victim or system extract the crafted tar archive prepared by the attacker. Automated systems extracting paths from archives originating from untrusted sources are in particular danger, especially if the extract operation is performed with elevated privileges.

In the worst-case scenario this vulnerability can lead to a full system compromise (remote code execution as root).

1. Extract pathname bypass due to safer_name_suffix usage

lib/paxnames.c safer_name_suffix() function sanitizes the `file_name' parameter and removes the file system prefix from the name if `absolute_names' parameter is 0. As a result, the path name effectively becomes relative to the target directory, ignoring the path name given on the command line......
The rest is at, http://seclists.org/fulldisclosure/2016/Oct/96

GazL 10-27-2016 03:33 PM
gnu tar 1.29 is the latest on their ftp site. I guess they haven't made a new release yet.

http://seclists.org/fulldisclosure/2016/Oct/96
Quote:
Timeline
--------

10.03.2016 discovered the vulnerability
11.03.2016 wrote a preliminary advisory
11.03.2016 contacted the GNU tar maintainer for a PGP key
14.03.2016 revised the advisory with --anchored --exclude bypass
information
15.03.2016 reworked the advisory slightly
15.03.2016 sent the advisory to the GNU tar maintainer
16.03.2016 contacted secalert () redhat com for help in coordination
17.03.2016 added end user mitigation via --one-top-level to the
advisory
17.03.2016 GNU tar maintainer didn't consider this to be an issue.
as a result mitigation in upstream GNU tar appears
unlikely
23.03.2016 added more attack scenarios to the advisory
10.08.2016 reworked the advisory slightly
10.08.2016 polled secalert () redhat com regarding the status of the
coordination
11.08.2016 CVE-2016-6321 was assigned to the vulnerability
15.09.2016 polled secalert () redhat com regarding the status of the
coordination
26.10.2016 handcrafted the ascii release file at a lobby bar
27.10.2016 public release of the advisory at t2'16
The response doesn't look to have been very impressive.
:(

BTW, reading the advisory, it looks like it's mostly a problem when used with the -C option, so if you always extract untrusted tarballs by first cd'ing into an empty directory (always good practice) it should be safe.

Thom1b 10-28-2016 12:23 PM
mariadb-10.0.28
 
mariadb-10.0.28 is released with many security fixes :
https://mariadb.com/kb/en/mariadb/ma...release-notes/


All times are GMT -5. The time now is 08:55 AM.
Page 37 of 65 « First 273536 37 383947 Last »
Show 50 post(s) from this thread on one page