SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
A defect in BIND's handling of responses containing a DNAME answer
can cause a resolver to exit after encountering an assertion failure
in db.c or resolver.c
During processing of a recursive response that contains a DNAME
record in the answer section, BIND can stop execution after
encountering an assertion error in resolver.c (error message:
"INSIST((valoptions & 0x0002U) != 0) failed") or db.c (error
message: "REQUIRE(targetp != ((void *)0) && *targetp == ((void
ther of these error conditions will stop,
resulting in denial of service to clients. The risk to authoritative
servers is minimal; recursive servers are chiefly at risk.
curl-7.51.0 is released with a lot of security fixes.
This release includes the following changes:
o nss: additional cipher suites are now accepted by CURLOPT_SSL_CIPHER_LIST
o New option: CURLOPT_KEEP_SENDING_ON_ERROR 
This release includes the following bugfixes:
o CVE-2016-8615: cookie injection for other servers 
o CVE-2016-8616: case insensitive password comparison 
o CVE-2016-8617: OOB write via unchecked multiplication 
o CVE-2016-8618: double-free in curl_maprintf 
o CVE-2016-8619: double-free in krb5 code 
o CVE-2016-8620: glob parser write/read out of bounds 
o CVE-2016-8621: curl_getdate read out of bounds 
o CVE-2016-8622: URL unescape heap overflow via integer truncation 
o CVE-2016-8623: Use-after-free via shared cookies 
o CVE-2016-8624: invalid URL parsing with '#' 
o CVE-2016-8625: IDNA 2003 makes curl use wrong host 
o openssl: fix per-thread memory leak using 1.0.1 or 1.0.2 
o http: accept "Transfer-Encoding: chunked" for HTTP/2 as well 
o LICENSE-MIXING.md: update with mbedTLS dual licensing 
o examples/imap-append: Set size of data to be uploaded 
o test2048: fix url
o darwinssl: disable RC4 cipher-suite support
o CURLOPT_PINNEDPUBLICKEY.3: fix the AVAILABILITY formatting
o openssl: donít call CRYTPO_cleanup_all_ex_data 
o libressl: fix version output 
o easy: Reset all statistical session info in curl_easy_reset 
o curl_global_cleanup.3: don't unload the lib with sub threads running 
o dist: add CurlSymbolHiding.cmake to the tarball
o docs: Remove that --proto is just used for initial retrieval 
o configure: Fixed builds with libssh2 in a custom location
o curl.1: --trace supports % for sending to stderr!
o cookies: same domain handling changed to match browser behavior 
o formpost: trying to attach a directory no longer crashes 
o CURLOPT_DEBUGFUNCTION.3: fixed unused argument warning 
o formpost: avoid silent snprintf() truncation
o ftp: fix Curl_ftpsendf
o mprintf: return error on too many arguments
o smb: properly check incoming packet boundaries 
o GIT-INFO: remove the Mac 10.1-specific details 
o resolve: add error message when resolving using SIGALRM 
o cmake: add nghttp2 support 
o dist: remove PDF and HTML converted docs from the releases 
o configure: disable poll() in macOS builds 
o vtls: only re-use session-ids using the same scheme
o pipelining: skip to-be-closed connections when pipelining 
o win: fix Universal Windows Platform build 
o curl: do not set CURLOPT_SSLENGINE to DEFAULT automatically 
o maketgz: make it support "only" generating version info
o Curl_socket_check: add extra check to avoid integer overflow
o gopher: properly return error for poll failures
o curl: set INTERLEAVEDATA too
o polarssl: clear thread array at init
o polarssl: fix unaligned SSL session-id lock
o polarssl: reduce #ifdef madness with a macro
o curl_multi_add_handle: set timeouts in closure handles 
o configure: set min version flags for builds on mac 
o INSTALL: converted to markdown => INSTALL.md
o curl_multi_remove_handle: fix a double-free 
o multi: fix inifinte loop in curl_multi_cleanup() 
o nss: fix tight loop in non-blocking TLS handhsake over proxy 
o mk-ca-bundle: Change URL retrieval to HTTPS-only by default 
o mbedtls: stop using deprecated include file 
o docs: fix req->data in multi-uv example 
o configure: Fix test syntax for monotonic clock_gettime
o CURLMOPT_MAX_PIPELINE_LENGTH.3: Clarify it's not for HTTP/2 
Cryptsetup CVE-2016-4484 Applies to Slackware 14.2
I just saw this vulnerability regarding cryptsetup / luks affecting version 2.1 and earlier. I tried it on a Slackware64 14.2 system and reproduced the problem easily.
After failing to unlock an encrypted partition during boot one is dropped into a shell as root. From there it is simple to mount unencrypted partitions, such as /boot, and have your way with it such as adding suid programs for later use.
Hmmm, I wonder if /boot could be mounted nosuid & noexec and still work?
The "rescue shell" in the initrd is a feature not a bug. Whilst it's something to be aware of from a hardening standpoint, unless you've locked down your bios/uefi environment and boot-managers so an attacker can't boot from alternate media or override kernel options (such as init=/bin/sh) then they're not getting any access here that they couldn't get in several other ways.
Taking the rescue shell out completely would hinder problem determination should you hit issues during the initrd phase, but perhaps there's an argument for a '--hardened' flag on mkinitrd to aid those that need a locked down boot process.
This is not the serious vulnerability that some websites are making out. zdnet actually compared it to heartbleed, which is just laughable.
I really don't know if this is worth worrying about, but here you go, this is a quick and dirty patch for this issue (NOTE: Not tested at all!)
Fix: CVE-2016-4484 - Cryptsetup Initrd root Shell
Apply to 'init' in /usr/share/mkinitrd/initrd-tree.tar.gz
--- init.orig 2016-09-20 19:27:04.000000000 +0100
+++ init 2016-11-16 16:11:01.947041538 +0000
@@ -125,6 +125,9 @@
ROOTFS=$(echo $ARG | cut -f2 -d=)
WAIT=$(echo $ARG | cut -f2 -d=)
@@ -303,9 +306,16 @@
if [ ! -r /mnt/sbin/init ]; then
echo "ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead."
- echo " You can try to fix it. Type 'exit' when things are done."
+ if [ -n "$SHELLONFAIL" ]; then
+ echo " You can try to fix it. Type 'exit' when things are done."
+ echo " Reboot specifying 'shellonfail' to get access to"
+ echo " a shell for diagnostic purposes."
expat 2.2.0 (21 June 2016). Security fix and other bug fixes:
CVE-2016-0718 (issue 537)
Fix crash on malformed input
Improve insufficient fix to CVE-2015-1283 / CVE-2015-2716 introduced with Expat 2.1.1
CVE-2016-5300 (issue 499)
Use more entropy for hash initialization than the original fix to CVE-2012-0876
CVE-2012-6702 (issue 519)
Resolve troublesome internal call to srand that was introduced with Expat 2.1.0 when addressing CVE-2012-0876 (issue 496)
Are there any security fixes in this kernel? I cant find any mentions of CVEs in the ChangeLog.
Non explicitly mentioned by CVE number, but a few of them have that sort of smell about them.
zram hot_add sysfs attribute is a very 'special' attribute - reading from it creates a new uninitialized zram device. This file, by a mistake, can be read by a 'normal' user at the moment, while only root must be able to create a new zram device.
There was also mention of many of the usual suspects: bad memory access, overflows, races, use after free's etc. I don't have the in-depth knowledge necessary to say whether any of this is worth worrying about, and the linux dev's are infamous for not highlighting security issues, so I think the best answer to your question is "Probably".