LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-14-2019, 04:43 PM   #811
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514

Quote:
Originally Posted by ponce View Post
there's no specific informations about this that I could find, but I tried testing an update of the SlackBuild neverthless, waiting for Andrzej

http://ponce.cc/slackware/testing/intel-microcode/

and there are actually updated microcodes for every intel cpu I have...
Meanwhile I updated my post #809 - added a P.S. about the spectre-meltdown-checker, which looks to be capable of identifying these new vulnerabilities. Worth testing it before and after the microcode update.
I can't do it myself right now, my systems are busy, the one I'm typing on is building Hadoop and the other two that are around are doing some data processing. As soon as I get one system available I'll test this on my own and report.
 
1 members found this post helpful.
Old 05-14-2019, 04:57 PM   #812
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 884

Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
A new set of vulnerabilities have officially surfaced affecting Intel Core-i and Xeon CPUs.
It's dubbed ZombieLoad (Attack) Intel refers to it by using "Microarchitectural Data Sampling (MDS)".
Still waiting for Intel to fix SPECTRE/MELTDOWN here for my multiple Penryn systems. Not holding my breath.

Actually waiting for Intel to fix that and either Intel, the kernel devs or Xorg to fix their crap for the GM965 chipset so it doesn't take 10 minutes for my PC's to get to the desktop. Again, not holding my breath.
 
Old 05-14-2019, 05:15 PM   #813
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514
Quote:
Originally Posted by Skaendo View Post
Still waiting for Intel to fix SPECTRE/MELTDOWN here for my multiple Penryn systems. Not holding my breath.

Actually waiting for Intel to fix that and either Intel, the kernel devs or Xorg to fix their crap for the GM965 chipset so it doesn't take 10 minutes for my PC's to get to the desktop. Again, not holding my breath.
You shouldn't wait after Intel for a SPECTRE/MELTDOWN fix, they don't care about older CPUs:
https://www.theregister.co.uk/2018/0...ocode_updates/
"Intel admits a load of its CPUs have Spectre v2 flaw that can't be fixed
And won’t fix Meltdown nor Spectre for 10 product families covering 230-plus CPUs"
&
https://www.intel.com/content/dam/ww...e_05132019.pdf
The Penryn microarchitecture is listed in Section 2:
"Section 2 – No planned microcode updates"
I'd suggest to get some newer HW, so that you can also enjoy these fresh vulnerabilities
 
Old 05-14-2019, 05:42 PM   #814
Skaendo
Member
 
Registered: Dec 2014
Location: West Texas, USA
Distribution: Slackware64-14.2
Posts: 884

Rep: Reputation: Disabled
Quote:
Originally Posted by abga View Post
I'd suggest to get some newer HW, so that you can also enjoy these fresh vulnerabilities
I have newer hardware (Sandy and AMD), but I have 2 Penryn laptops that I use all the time. I will never buy another Intel based PC ever again.

One of the main selling points of Linux in general is that "It brings old hardware new life". I am starting to feel like that was just a big a lie.
 
Old 05-14-2019, 06:54 PM   #815
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 795
Blog Entries: 26

Rep: Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028
I'm regretting getting rid of my old Pentium systems. They'd be proof against rowhammer, AMT, spectre, meltdown and zombieload.

An i586 running Slackware would serve nicely as a secure network router or text processor desktop.
 
2 members found this post helpful.
Old 05-14-2019, 07:17 PM   #816
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 795
Blog Entries: 26

Rep: Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028Reputation: 1028
Two more vulnerabilities besides Zombieload -- "RIDL" and "Fallout": https://cpu.fail/
 
1 members found this post helpful.
Old 05-14-2019, 10:26 PM   #817
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514
Quote:
Originally Posted by ttk View Post
I'm regretting getting rid of my old Pentium systems. They'd be proof against rowhammer, AMT, spectre, meltdown and zombieload.

An i586 running Slackware would serve nicely as a secure network router or text processor desktop.
Actually I still own an old fanless Pentium MMX 300MHz sub-notebook (a very slim and slick Toshiba portege) that I used as a router with 2 PCMCIA Ethernet cards until some years ago when I switched to OpenWRT / Raspberry - Slackware ARM. That ancient sub-notebook is still working now, still loaded with Slackware 13.x and I remember I had some issues upgrading to Slackware 13.x & a new kernel because I had some BIOS issues and only 24 MB RAM (32 - but 8 were allocated for the GPU)
It was some years ago (many) that I also got in direct contact with AlienBoB on his blog, actually he moderated my post, because I contradicted him, "invalidated his theory" at that time - he was convinced, and sustained that it cannot be done. I was not able to boot the boot disks (floppies) due to some BIOS/RAM/kernel limitations (can't remember exactly - getting older) and found a way to load a pseudo "BIOS" / boot loader with a special floppy image and then boot the actual Slackware boot floppies.

For the router part - I'd suggest www.openwrt.org with some beefy (multi-core - to handle some load & Gbit traffic) router that is supported.
For the secure processor desktop, well, I'm also looking for a solution...maybe:
https://en.wikipedia.org/wiki/Risc-v
but they don't have a GPU yet and the few boards available are really expensive and sort of developer-boards.
 
2 members found this post helpful.
Old 05-16-2019, 01:57 AM   #818
devafree
LQ Newbie
 
Registered: Jan 2006
Posts: 5

Rep: Reputation: 0
Ghostscript package not found -current x86_64

http://www.slackware.com/security/vi...ecurity.371149

Could not find package:-

Updated package for Slackware x86_64 -current:
ftp://ftp.slackware.com/pub/slackwar...6-x86_64-2.txz

Thanks!
 
Old 05-16-2019, 02:13 AM   #819
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 4,758

Rep: Reputation: Disabled
Quote:
Originally Posted by devafree View Post
http://www.slackware.com/security/vi...ecurity.371149

Could not find package:-

Updated package for Slackware x86_64 -current:
ftp://ftp.slackware.com/pub/slackwar...6-x86_64-2.txz

Thanks!
it has already been updated again to ghostscript-9.27-x86_64-1 in current.
 
Old 05-18-2019, 10:15 AM   #820
abga
Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 982

Rep: Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514Reputation: 514
Quote:
Originally Posted by abga View Post
Couldn't find a proper list with all affected CPU's, Intel, in the SA-00233 is pointing to the latest firmware release guide:
https://www.intel.com/content/dam/ww...e_05132019.pdf
Which states:

- the majority of the modern Core-i & Xeon CPUs are listed in "Section 1"
Here is the official Intel list with all the CPUs affected by the MDS vulnerabilities:
https://software.intel.com/security-...msrs#MDS-CPUID
 
1 members found this post helpful.
Old 05-19-2019, 09:56 AM   #821
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,599

Rep: Reputation: Disabled
Quote:
Originally Posted by ttk View Post
I'm regretting getting rid of my old Pentium systems. They'd be proof against rowhammer, AMT, spectre, meltdown and zombieload.

An i586 running Slackware would serve nicely as a secure network router or text processor desktop.
https://en.wikipedia.org/wiki/Pentium_FDIV_bug
https://en.wikipedia.org/wiki/Pentium_F00F_bug
 
Old 05-19-2019, 01:33 PM   #822
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 1,695

Rep: Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236Reputation: 5236
At least those bugs could be worked around in the kernel without imposing a significant performance hit.
 
2 members found this post helpful.
Old 05-22-2019, 03:56 AM   #823
Thom1b
Member
 
Registered: Mar 2010
Location: France
Distribution: Slackware
Posts: 251

Rep: Reputation: 197Reputation: 197
curl-7.65.0 is released with 2 security fixes:
https://curl.haxx.se/download/curl-7.65.0.tar.xz
https://curl.haxx.se/download/curl-7.65.0.tar.xz.asc

Quote:
Integer overflows in `curl_url_set()`
=====================================

Project curl Security Advisory, May 22nd 2019 -
[Permalink](https://curl.haxx.se/docs/CVE-2019-5435.html)

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

libcurl contains two integer overflows in the `curl_url_set()` function that
if triggered, can lead to a too small buffer allocation and a subsequent heap
buffer overflow.

The flaws only exist on 32 bit architectures and require excessive string
input lengths.

We are not aware of any exploit of this flaw.

INFO
----

There are two entry points to this issue, on 32 bit architectures.

By asking libcurl to parse a string, passing in a string longer than 2GB to
this API: `curl_url_set(uh, CURLUPART_URL, "string", 0);` triggers the bug.

Asking libcurl to update a URL with a new string, and URL encoded it in the
process, by passing in a string longer than 1.33GB to this API:
`curl_url_set(uh, CURLUPART_*, "string", CURLU_URLENCODE);` triggers the bug.

This bug was introduced in August 2018 in
[commit fb30ac5a2d](https://github.com/curl/curl/commit/fb30ac5a2d63773c52).

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

CWE-131: Incorrect Calculation of Buffer Size

Severity: 3.7 (Low)

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

- Affected versions: libcurl 7.62.0 to and including 7.64.1
- Not affected versions: libcurl < 7.62.0 and >= libcurl 7.65.0

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

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

A [fix for CVE-2019-5435](https://github.com/curl/curl/commit/5fc28510a4664f4) is already merged.

RECOMMENDATIONS
--------------

We suggest you take one of the following actions immediately, in order of
preference:

A - Upgrade curl to version 7.65.0

B - Apply the patch to your version and rebuild

TIMELINE
--------

The issue was reported to the curl project on April 24, 2019. The patch was
communicated to the reporter on April 25, 2019. We contacted distros@openwall
on May 15.

curl 7.65.0 was released on May 22 2019, coordinated with the publication of
this advisory.
Quote:
TFTP receive buffer overflow
============================

Project curl Security Advisory, May 22nd 2019 -
[Permalink](https://curl.haxx.se/docs/CVE-2019-5436.html)

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

libcurl contains a heap buffer overflow in the function
(`tftp_receive_packet()`) that recevives data from a TFTP server. It calls
`recvfrom()` with the default size for the buffer rather than with the size
that was used to allocate it. Thus, the content that might overwrite the heap
memory is entirely controlled by the server.

The flaw exists if the user selects to use a "blksize" of 504 or smaller
(default is 512). The smaller size that is used, the larger the possible
overflow becomes.

Users chosing a smaller size than default should be rare as the primary use
case for changing the size is to make it larger.

It is rare for users to use TFTP across the Internet. It is most commonly used
within local networks.

We are not aware of any exploit of this flaw.

INFO
----

This bug was introduced in January 2009 in [commit 0516ce7786e95](https://github.com/curl/curl/commit/0516ce7786e95).

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

CWE-122: Heap-based Buffer Overflow

Severity: 1.8 (Low)

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

- Affected versions: libcurl 7.19.4 to and including 7.64.1
- Not affected versions: libcurl < 7.19.4 and >= libcurl 7.65.0

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

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

A [fix for CVE-2019-5436](https://github.com/curl/curl/commit/...f8097830b82275)

RECOMMENDATIONS
--------------

We suggest you take one of the following actions immediately, in order of
preference:

A - Upgrade curl to version 7.65.0

B - Apply the patch to your version and rebuild

C - do not use TFTP with curl

TIMELINE
--------

The issue was reported to the curl project on April 29, 2019. The patch was
communicated to the reporter on April 29, 2019. We contacted distros@openwall
on May 15.

curl 7.65.0 was released on May 22 2019, coordinated with the publication of
this advisory.
 
2 members found this post helpful.
  


Reply

Tags
exploit, security, slackware


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[Slackware Security]: Some pending vulnerabilities... mancha Slackware 7 08-22-2013 09:08 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:57 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration