LinuxQuestions.org - [Slackware security] vulnerabilities outstanding 20140101

Page 18 of 20

Show 50 post(s) from this thread on one page

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

teoberi

11-13-2019 12:42 AM

I was missing such posts!
Thanks @abga.

abga	11-13-2019 06:02 AM

Quote:

Originally Posted by teoberi (Post 6057064)

I was missing such posts!
Thanks @abga.

Yeah, I just got a delayed BIOS update containing fixes (microcode) for the MDS vulnerability (discovered - 2018) for some of my DELL laptops and was happy that finally I don't need to care about loading the microcode myself. Well, my "state of happiness" didn't last that long...

Intel has actually released details and fixes for an entire list of vulnerabilities (Intel AMT , ME included) and a nice erratum called "Conditional Code Erratum", fixed by the latest microcode, affecting: Amber Lake, Cascade Lake, Coffee Lake, Comet Lake, Kaby Lake, Skylake and Whiskey Lake.

Intel's list of vulnerabilities:
https://www.intel.com/content/www/us...-sa-00241.html

Blog entry:
https://blogs.intel.com/technology/2...rm-update-ipu/

Mitigations for Jump Conditional Code Erratum - White Paper (apparently fixed by latest microcode):
https://www.intel.com/content/dam/su...de-erratum.pdf

ehartman

11-13-2019 07:07 AM

Quote:

Originally Posted by abga (Post 6057162)

was happy that finally I don't need to care about loading the microcode myself. Well, my "state of happiness" didn't last that long...

And note that the newest kernel upgrade for Slackware 14.2 (4.4.201) does not include the kernel-firmware package (again) anymore, so everyone: make sure you retain the (4 days old) firmware from the .199 kernel!

phenixia2003

11-13-2019 08:38 AM

Hello,

Quote:

Originally Posted by ehartman (Post 6057186)

... Or, instead of running slackpkg upgrade-all, run slackpkg upgrade patches to only upgrade packages for which updates are available in "patches" directory. This, obviously, applies to slackware-stable only.

"slackpkg upgrade-all" is mandatory on slackware-current. On stable, it is better to just stick to "slackpkg upgrade patches".

--
SeB

teoberi

11-13-2019 09:34 AM

Quote:

Originally posted by abga
Intel has actually released details and fixes for an entire list of vulnerabilities (Intel AMT , ME included) and a nice erratum called "Conditional Code Erratum", fixed by the latest microcode, affecting: Amber Lake, Cascade Lake, Coffee Lake, Comet Lake, Kaby Lake, Skylake and Whiskey Lake.

In the last few months I have spent a lot of time learning about Intel ME from here:
https://www.win-raid.com/f39-Intel-M...nt-Engine.html
https://www.win-raid.com/t596f39-Int...tem-Tools.html
This is how I managed to update my Intel ME version because my friends at ASUS had not yet decided to send me a new BIOS version.
Now I am analyzing the risk of updating to the latest Intel ME version available in the link above.
Thanks @abga seems to have it!

volkerdi

11-13-2019 12:17 PM

Quote:

Originally Posted by ehartman (Post 6057186)

The kernel-firmware package was moved up a directory level. It's still under /patches, so it shouldn't be a problem this time.

ehartman

11-13-2019 08:02 PM

Quote:

Originally Posted by volkerdi (Post 6057297)

The kernel-firmware package was moved up a directory level. It's still under /patches, so it shouldn't be a problem this time.

Yes, I've now noticed that so I've adjusted my own private mirror now.

And thanks Pat, for removing this updating problem.

abga	11-15-2019 03:57 PM

Quote:

Originally Posted by teoberi (Post 6057245)

Intel released some Linux (wow!) detection tools for the latest Intel AMT & Intel ME & Intel CSME vulnerabilities:
https://www.intel.com/content/www/us...hnologies.html
https://downloadcenter.intel.com/download/29057
https://downloadcenter.intel.com/download/28632

As for the latest CPU microcode from Intel, the SlackBuild is not yet updated but easy to adapt.
- get the latest Intel microcode

Code:

wget https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191112.tar.gz

- rename it to fit the SlackBuild

Code:

mv microcode-20191112.tar.gz Intel-Linux-Processor-Microcode-Data-Files-microcode-20191112.tar.gz

- get the SlackBuild from http://www.slackbuilds.org/repositor...tel-microcode/ and use the microcode file from above
- change VERSION=${VERSION:-20191112} in intel-microcode.SlackBuild
- build and install/upgrade it

Petri Kaukasoina

11-17-2019 02:51 AM

Quote:

Originally Posted by abga (Post 6058225)

get the latest Intel microcode

There's now even microcode-20191115.

teoberi

11-17-2019 07:41 AM

They were really fast: 20191112 Release -> 20191115 Release.
I wonder in what state of mind hardware manufacturers will be, if Intel keeps it that way!

abga	11-17-2019 11:40 AM

Well, get http://www.slackbuilds.org/repositor...tel-microcode/
Adapt the intel-microcode.SlackBuild --> VERSION=${VERSION:-20191115}
And get&use the new microcode:

Code:

wget https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20191115.tar.gz

mv microcode-20191115.tar.gz Intel-Linux-Processor-Microcode-Data-Files-microcode-20191115.tar.gz

abga	11-18-2019 11:30 PM

Potential DoS vulnerability affecting many Intel CPUs.
Machine Check Error on Page Size Change - CVE-2018-12207

https://software.intel.com/security-...-size-change-0

More details in the kernel thread:
https://www.linuxquestions.org/quest...ml#post6059518

Didier Spaier

12-05-2019 04:35 PM

New Linux Vulnerability Lets Attackers Hijack VPN Connection

Cf.: https://www.bleepingcomputer.com/new...n-connections/

abga	12-05-2019 06:46 PM

Quote:

Originally Posted by Didier Spaier (Post 6065109)

Cf.: https://www.bleepingcomputer.com/new...n-connections/

Quote:

* This attack works regardless of if you have a VPN or not. The attacker just needs to be able to
send packets to the other host. It's not systemd specific. It can also occur because the user deliberately
configured the rp_filter that way (that's sometimes the case if PBR (Policy Based Routing) is configured.
The default for rp_filter is strict. For further information on the matter see ip-sysctl.txt[2]
and RFC 3704 Section 2.4[3]. For now, just create a file /etc/sysctl.d/51-rpfilter.conf with the content
"net.ipv4.conf.all.rp_filter=1".
* You can solve the problem generally for IPv6 by using the rpfilter iptables or nftables module in *mangle
PREROUTING[1].
...
[1] Would look like that: ip6tables -t mangle -I PREROUTING -m rpfilter --invert -j DROP

And there is a slashdot discussion:
https://linux.slashdot.org/story/19/...pn-connections

Quote:

So don't connect to a VPN when using an unknown access point, and you'll be fine! ;-)

:D

Besides, this is part of my standard (IPv4 & static routing) firewall header (it's been for ages):

Code:

if [ -r /proc/sys/net/ipv4/conf/default/rp_filter ]; then

echo "Enabling rp_filter"

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

fi

P.S. If you bring up the interfaces before setting up the rp_filter, then you need to care about all of them manually:

Code:

if [ -r /proc/sys/net/ipv4/conf/all/rp_filter ]; then

 echo "Enabling rp_filter"

 for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do

  echo 1 > $i

 done

 echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter

fi

- more info on the values for rp_filter:
https://www.kernel.org/doc/Documenta.../ip-sysctl.txt

Aeterna

12-05-2019 08:46 PM

Quote:

Originally Posted by abga (Post 6065139)

Thanks for the update!
The original report (link available in the bleepingcomputer article) has a response in which more details and some simple workarounds are available:
Original report:
https://seclists.org/oss-sec/2019/q4/122
Response:
https://seclists.org/oss-sec/2019/q4/123

And there is a slashdot discussion:
https://linux.slashdot.org/story/19/...pn-connections

:D

Besides, this is part of my standard (IPv4 & static routing) firewall header (it's been for ages):

Code:

if [ -r /proc/sys/net/ipv4/conf/default/rp_filter ]; then

echo "Enabling rp_filter"

echo 1 > /proc/sys/net/ipv4/conf/default/rp_filter

fi

P.S. If you bring up the interfaces before setting up the rp_filter, then you need to care about all of them manually:

Code:

if [ -r /proc/sys/net/ipv4/conf/all/rp_filter ]; then

 echo "Enabling rp_filter"

 for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do

  echo 1 > $i

 done

 echo 0 > /proc/sys/net/ipv4/conf/lo/rp_filter

fi

- more info on the values for rp_filter:
https://www.kernel.org/doc/Documenta.../ip-sysctl.txt

actually for Strong ES Model you need:

Quote:

net.ipv4.conf.default.rp_filter=1
net.ipv4.conf.eth0.rp_filter=1 # replace with your interface
net.ipv4.conf.wlan0.rp_filter=1 # replace with your interface and so on
net.ipv4.conf.all.arp_filter=1
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

just create (ifyou don't have it already)

Quote:

/etc/sysctl.conf

add the above and run:

Code:

sudo sysctl -p

abga	12-05-2019 09:28 PM

@Aeterna
Thanks for the tips!

I do have the lines you suggested in my firewall header, but with some different, IMO, optimal values:

Code:

echo 2 > /proc/sys/net/ipv4/conf/all/arp_ignore

echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce

echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter

I also have a /etc/sysctl.conf and since Slackware doesn't provide one by default, I also instruct other users to create&use it:
https://www.linuxquestions.org/quest...5/#post5963569
But I don't use it for networking stuff, only for system tweaks. I prefer to focus on the firewall instead (trying to not loose my head).

______

Up in #864 I quoted an excerpt from the seclists.org Response where an iptables line was suggested for mitigation.
Checked the actual iptables manual:
http://ipset.netfilter.org/iptables-....man.html#lbBX
And learned (also successfully tested) that the actual syntax should be:

Code:

/usr/sbin/iptables -A PREROUTING -t raw -m rpfilter --invert -j DROP

/usr/sbin/ip6tables -A PREROUTING -t raw -m rpfilter --invert -j DROP

That's if you don't like the "logic" of the /proc/sys/net/ipv4/conf/*/rp_filter

P.S. - /proc/sys/net/ipv4/conf/*/rp_filter logic
- TLDP - FIXME
http://tldp.org/HOWTO/Adv-Routing-HO...ernel.rpf.html
- RH Experts focusing on the default value
https://access.redhat.com/documentat...ath_forwarding
- The Urban Penguin's "PhD dissertation":
https://www.theurbanpenguin.com/rp_f...inux-security/

Aeterna

12-05-2019 09:46 PM

@abga
even more good tips. I see :)

eventually to consider (on the server I have (in addition to the above) )

Quote:

net.ipv4.conf.eth0.arp_ignore = 1
net.ipv4.conf.eth0.arp_announce = 2
net.ipv4.conf.eth1.arp_ignore = 1
net.ipv4.conf.eth1.arp_announce = 2

bamunds

12-06-2019 05:52 PM

Quote:

Originally Posted by Aeterna (Post 6065167)

actually for Strong ES Model you need:

just create (ifyou don't have it already)

add the above and run:

Code:

sudo sysctl -p

So I just loaded firewalld running on my Slackware64 14.2 The environment is a single desktop behind a Modem/Router with IPv4 only service on the LAN, NAT enabled, and Firewall on. Some might ask why I'm running any firewall? Well I have been for years and yet I want to get experience and get ready to use a laptop when out and about. So simple setups in safe environment first. My firewalld zone is home and only irc,mdns, and samba-client are checked for services.

How would one convert the above commands to block this new IPv4 security issue in the firewalld entries? Can they be put in to FirewallD Direct Configuration?

Cheers, BrianA_MN

abga	12-06-2019 06:17 PM

@bamunds

You have two options, the first one, outside of the scope of firewalld, using the kernel sysctl interface, presented in the bottom of my post #864.
The second, to import/migrate into firewalld the two (maybe only the IPv4 is required) iptables rules available in the second half of my post #866. I have no experience with firewalld and I suggest to look into the doc / search the net for how to achieve this. A starting point can be:
https://serverfault.com/questions/91...s-to-firewalld

abga	12-06-2019 08:12 PM

Basically all the workarounds, these are workarounds and not fixes, presented for the CVE-2019-14899 - Inferring and hijacking VPN-tunneled TCP connections, together with Aeterna's sysctl additions, helping also with a potential ARP Flux, are enforcing a strong host model on the networking system. This is not a bad practice after all and it works in almost all networking scenarios (simple static routing(no policy routing or advanced routing)).
If in doubt, consult the RFC - sections 4.2.2.11, 4.3.2.7, 5.3.3.3 (etc)
https://tools.ietf.org/html/rfc1812
Even on simple static routing setups for instance, by using "net.ipv4.conf.all.arp_ignore = 2" on your system, you can get into issues when talking to weird networking devices or an ARP proxy. Here is a concrete example:
https://bugs.endian.com/view.php?id=1507

IMO, a proper fix should maybe get developed by the VPN providers, in their SW and only affecting the interface it uses.
OpenVPN is closely watching this issue (whatever that means):
"OpenVPN Inc. is keeping a close eye on the discussions currently ongoing, and possible solutions. Currently there is no evidence suggesting there is a flaw in the OpenVPN software itself."
https://openvpn.net/security-advisor...nvpn-software/

And the Wireguard devs (Wireguard being that new VPN thingy that is going to make its way (already in 5.5.x?) into the kernel) are scratching their heads:
https://lists.zx2c4.com/pipermail/wi...er/004679.html

Side note on Wireguard:
https://lwn.net/Articles/802376/
https://www.phoronix.com/scan.php?pa...ible-Linux-5.5

abga	12-08-2019 05:43 PM

Is this thread no longer sticky?

bassmadrigal

12-08-2019 05:51 PM

I think for some reason they unstickied this one and kept this old and outdated one as the sticky...

abga	12-08-2019 06:14 PM

Well, maybe it's time to start a new one, without any date & "outstanding" in the title, like:
[Slackware security] Live Vulnerabilities Announcements & Reports

Thom1b

12-08-2019 11:08 PM

Hi,

Quote:

Originally Posted by abga (Post 6065938)

Well, maybe it's time to start a new one, without any date & "outstanding" in the title, like:
[Slackware security] Live Vulnerabilities Announcements & Reports

I think the thread Status Update: Slackware LQ Security Thread is the one.

abga	12-08-2019 11:29 PM

@Thom1b

Thanks! Noticed that already. It's all GazL's fault for calling it "active, and useful" :D
Now this one that contains all the fresh stuff & details will get flushed down the toilet ... forum thread list and will soon vanish.
I don't know if it's in the power of the mods, but I'd rather suggest to rename this thread, remove " outstanding 20140101 " from the title and keep it active & sticky.
Or, rename it in: [Slackware security] Live Vulnerabilities Announcements & Reports
- maybe other more suggestive name (I'm not a native English speaker and not very creative at this time (tired too)).

GazL	12-09-2019 05:20 AM

Yep, sorry guys, looks like my desire to tidy up the stickies backfired and they clobbered the wrong one.

Mods, please can you. re-sticky this active thead:
https://www.linuxquestions.org/quest...-a-4175489800/

and unsticky this dead one: https://www.linuxquestions.org/quest...ad-4175522182/

As for the title, it might be an idea to wait until Jan and start a new 2020 thread to use going forward, or start a new one when Slackware 15.0 releases. what do people think?

GazL	12-09-2019 05:39 AM

Quote:

Originally Posted by abga (Post 6065985)

Or, rename it in:
- maybe other more suggestive name (I'm not a native English speaker and not very creative at this time (tired too)).

'Live' might make people think it relates to Eric's Slackware-Live.

"[Slackware Security] Unresolved Vulnerability Announcements, Reports and Discussion" seems like an unambiguous title, if a little bit long.

Tonus

12-09-2019 10:03 AM

"[Slackware Security] Vulnerability Announcements, Reports and Discussion"

Since I hope a few become solved, that would be my vote

unSpawn

12-09-2019 03:52 PM

Quote:

Originally Posted by GazL (Post 6066069)

Yep, sorry guys, looks like my desire to tidy up the stickies backfired and they clobbered the wrong one.

Thanks for correcting. Reversed stickification.

GazL	12-09-2019 04:16 PM

Thanks UnSpawn, much appreciated.

bamunds

12-09-2019 05:43 PM

Quote:

Originally Posted by bamunds (Post 6065426)

Turns out the Documentation for firewalld.conf clearly says that IPv4 rpfilter is controlled by sysctl.conf. So setting up sysctl.conf as stated above is exactly what to do. Thanks.

abga	12-09-2019 07:25 PM

Quote:

Originally Posted by GazL (Post 6066073)

I felt the "outstanding" would suggest that the vulnerabilities are not resolved and that is false, I know for sure Patrick is constantly monitoring & providing inputs in the thread and issues are getting resolved in no-time. The same goes for "current" - again unresolved?, additionally, for a visitor it can also suggest that Slackware is not doing a good job -, like : "look they have a thread for the outstanding(unresolved) security issues" :)
With "Live" I wanted to emphasize that the thread is active and "alive", that it should be used and monitored, but now I believe Tonus' formulation could be more suitable (with the plural for Discussion):
"[Slackware Security] Vulnerability Announcements, Reports and Discussions"

Glad it's back on sticky. :)

GazL	12-10-2019 02:49 AM

Quote:

Originally Posted by abga (Post 6066319)

I felt the "outstanding" would suggest that the vulnerabilities are not resolved and that is false,"

Actually, the original intention for the thread was as a place to draw attention to and discuss security related issues that need addressing on a Slackware system: either by local sysadms, or Pat, applying an upstream patch/update, or taking mitigating steps.

As such, "outstanding" and "unresolved" are appropriate. I prefer "unresolved" so as to avoid the multiple meanings "outstanding" has.

bassmadrigal

12-10-2019 08:04 PM

Quote:

Originally Posted by GazL (Post 6066384)

As such, "outstanding" and "unresolved" are appropriate. I prefer "unresolved" so as to avoid the multiple meanings "outstanding" has.

What I see abga trying to explain is that someone might look on page one and see a vulnerability from 2014 that they think hasn't been addressed. Without a proper way to edit the older posts in the thread when things are no longer outstanding or unresolved, it may lead someone to think that Slackware is insecure. Hopefully they won't come to that conclusion, but it is always possible.

If we had the ability to edit the first post and keep track of currently known vulnerabilities that don't have patches (or even recent ones that had patches already pushed out), it would make more sense to leave it as outstanding or unresolved.

But since I believe only moderators would have the ability to edit posts that old (and the topic name), we're stuck with the current name and OP.

I suppose if someone wanted to be gung-ho and maintain a slack-docs article on current vulnerabilities, they could open a new thread for new vulnerabilities announcements/reportings and then in the first post, they could link the slack-docs article that tracks current/recent vulnerabilities and their status on various Slackware versions. I certainly don't have the time and inclination to manage that, but it would certainly be a nice resource if someone is able to tackle it.

mats_b_tegner

01-18-2020 10:02 AM

Kernel 4.4.210 fixes the following CVEs: CVE-2019-14615, CVE-2019-14895
https://cdn.kernel.org/pub/linux/ker...ngeLog-4.4.210
https://cdn.kernel.org/pub/linux/ker...4.4.210.tar.xz

abga	01-28-2020 03:39 PM

Those of you fellow Slackers running on newer Intel CPUs (manufactured since 2015, apparently) thinking that by applying all the latest microcodes and kernel patches, your systems are safe now, think again ....
The latest microcode patches Intel provided are not fully mitigating the already discovered CPU flaws.

https://www.intel.com/content/www/us...-sa-00329.html

CVE-2020-0549 - called CacheOut by the University of Michigan and L1DES (L1D Eviction Sampling) by Intel
https://cacheoutattack.com/
https://mdsattacks.com/#ridl-nng
https://software.intel.com/security-...ction-sampling

CVE-2020-0548 - called VRS (Vector Register Sampling)
https://software.intel.com/security-...ister-sampling

There are no mitigations available ATM, microcode updates should fix them both. No info about future kernel patches.

Some articles on the subject:
https://www.wired.com/story/intel-zo...ive-execution/
https://www.phoronix.com/scan.php?pa...e-Data-Leakage

GazL	01-28-2020 04:19 PM

Quote:

Originally Posted by abga (Post 6083910)

Those of you fellow Slackers running on newer Intel CPUs (manufactured since 2015, apparently) thinking that by applying all the latest microcodes and kernel patches, your systems are safe now, think again ....

I don't believe anyone is under that delusion any more. Speculative execution is the gift that keeps on giving, and is likely to continue to do so for a good number of years yet.

abga	01-28-2020 11:23 PM

And when you think of it, Linus called the first Intel patches "COMPLETE AND UTTER GARBAGE".
https://lkml.org/lkml/2018/1/21/192
Poor guy was punished and had to abide to this:
https://git.kernel.org/pub/scm/linux...4093c54469c11f
But he deserved it, he was "utterly" wrong in the first place, forgot to add the word PERPETUAL in front of his original expression ;)

I'm only running on Intels and never considered AMD in the last 15 years or more. Will start to look more closely at their mobile CPUs from now on, since I'm loosing confidence in Intel's commitment in properly resolving their issues.
My last experience with AMD on laptops was: really bad thermal issues, overheating, CPUs literally burning out (including MB), they wouldn't last more than 1-2 years of normal usage. I hope that changed now.

abga	03-10-2020 08:24 PM

New vulnerability published affecting Intel SGX enabled CPUs. Firmware (microcode update) mitigation will be available and binutils is patching itself:
https://sourceware.org/pipermail/bin...ch/110175.html

https://lviattack.eu/
"LVI is a new class of transient-execution attacks exploiting microarchitectural flaws in modern processors to inject attacker data into a victim program and steal sensitive data and keys from Intel SGX, a secure vault in Intel processors for your personal data."

Intel's advisory:
https://www.intel.com/content/www/us...-sa-00334.html

CVE entry:
https://cve.mitre.org/cgi-bin/cvenam...=CVE-2020-0551

TracyTiger

04-05-2020 12:48 PM

Chrome Security Issues

It appears that Chrome (Chromium) has some vulnerabilities. In that last couple of days (March 31st) it has been recommended to upgrade to 80.0.3987.162 due to several important security issues.

https://www.us-cert.gov/ncas/current...updates-chrome

I pulled down Alien Bob's Chromium a couple of weeks ago and it was at 80.0.3987.149.

Those that follow Chrome more closely can add detail about these vulnerabilities. I only use Alien Bob's Chromium for websites that demand its features. (Thanks Eric!)

Although not a Slackware specific issue I'm posting this to inform members of this forum.

EDIT: More detail...

https://www.cisecurity.org/advisory/...tion_2020-044/

abga	06-10-2020 05:42 PM

A new security hole in some of the Intel Core i7, Core i9 and Xeon CPUs, called SRBDS, CVE-2020-0543.
Mitigated apparently only through microcode updates.
Details (I stopped analyzing them, don't really feel the need to become an expert in CPU design... ):
https://www.vusec.net/projects/crosstalk/
https://www.intel.com/content/www/us...-sa-00320.html

Extra, the usual AMT, plus some SSD, BIOS and "Innovation Engine Build and Signing Tool" (interesting name):
https://www.intel.com/content/www/us...-sa-00295.html
https://www.intel.com/content/www/us...-sa-00266.html
https://www.intel.com/content/www/us...-sa-00322.html
https://www.intel.com/content/www/us...-sa-00366.html

P.S. Actually, according to Intel, many more CPU families are affected by the vulnerability. I was only reading the vusec article when I composed the post.
Full list here:
https://software.intel.com/security-...duct-cpu-model

teoberi

06-11-2020 12:31 AM

Quote:

Originally Posted by abga (Post 6132893)

A new security hole in some of the Intel Core i7, Core i9 and Xeon CPUs, called SRBDS, CVE-2020-0543.
Mitigated apparently only through microcode updates.

Code:

./spectre-meltdown-checker.sh -v

Quote:

CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* SRBDS mitigation control is supported by the kernel: NO
* SRBDS mitigation control is enabled and active: NO (SRBDS not found in sysfs hierarchy)
> STATUS: NOT VULNERABLE (Your microcode is up to date for SRBDS mitigation control. The kernel needs to be updated)

And after updating the kernel:

Quote:

CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* Mitigated according to the /sys interface: YES (Mitigation: Microcode)
* SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation)
* SRBDS mitigation control is enabled and active: YES (Mitigation: Microcode)
> STATUS: NOT VULNERABLE (Your microcode and kernel are both up to date for SRBDS mitigation control. Mitigation is enabled)

abga	06-11-2020 05:03 AM

Quote:

Originally Posted by teoberi (Post 6132962)

[CODE]
And after updating the kernel:

Thanks for the details, didn't know that the kernel also has its own mitigation part.
And, I suppose you're referring to 5.4.46. That contains :

Quote:

x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation

commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.4.46

Whereas, for the stable Slackware 14.2, the 4.4.217 kernel doesn't appear to contain the SRBDS code yet, but only 4.4.227
https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.4.227

gegechris99

06-11-2020 04:36 PM

Quote:

Originally Posted by abga (Post 6133019)

Thanks for the details, didn't know that the kernel also has its own mitigation part.

This is not really a kernel mitigation per se. Kernel 5.4.46 offers the administrator the possibility to disable the microcode SRBDS mitigation if it leads to performance issues.

Quote:

x86/speculation: Add Special Register Buffer Data Sampling (SRBDS) mitigation
commit 7e5b3c267d256822407a22fdce6afdf9cd13f9fb upstream

SRBDS is an MDS-like speculative side channel that can leak bits from the
random number generator (RNG) across cores and threads. New microcode
serializes the processor access during the execution of RDRAND and
RDSEED. This ensures that the shared buffer is overwritten before it is
released for reuse.

While it is present on all affected CPU models, the microcode mitigation
is not needed on models that enumerate ARCH_CAPABILITIES[MDS_NO] in the
cases where TSX is not supported or has been disabled with TSX_CTRL.

The mitigation is activated by default on affected processors and it
increases latency for RDRAND and RDSEED instructions. Among other
effects this will reduce throughput from /dev/urandom.

* Enable administrator to configure the mitigation off when desired using
either mitigations=off or srbds=off.

* Export vulnerability status via sysfs

Also SRBDS vulnerability status can be checked with:

Code:

$cat /sys/devices/system/cpu/vulnerabilities/srbds

The output could be one of the following:

Code:

"Vulnerable"

"Vulnerable: No microcode"

"Mitigation: Microcode"

"Mitigation: TSX disabled"

"Unknown: Dependent on hypervisor status"

Didier Spaier

07-29-2020 12:32 PM

Multiple GRUB2 vulnerabilities - BootHole

Quoting a message from Daniel Kiper on the grub-devel mailing list:

Quote:

We have recently been made aware of a problem with GRUB2 by security research firm Eclypsium that allows a bad actor to circumvent UEFI Secure Boot. Normally, when Secure Boot is enabled, only modules [1] that have a valid signature can be loaded. The bug allows this to be circumvented and allow a module to be loaded that is not signed and therefore breaks the chain of trust that Secure Boot is supposed to guarantee.

This is not a concern for most Slackware users as Slackware doesn't allow booting with Secure Boot enabled out of the box, however it is possible to enable this feature as documented in this article on SlackDocs.

So if you enable Secure Boot read the message from Daniel.

PS I assume that all the 28 patches will be applied in grub-2.06, so just upgrading will address the mentioned CVEs. As an aside work on this issue probably delayed the release of this new version, meanwhile several non-security patches wait to be committed but the first RC can now appear within a few weeks, I think.

EDIT: good guess ;)
Le 29/07/2020 à 19:46, Daniel Kiper a écrit :
> I think this link [1] will explain my long absence... Sorry about that.
>
> I am going to go back to GRUB work next week. I will triage all the patches
> and take all (obvious) fixes. Then I will release rc1 ASAP... All new features
> will be taken after 2.06 release.
>
> Daniel
>
> [1] https://lists.gnu.org/archive/html/g.../msg00034.html

PPS The scope of this vulnerability is a lot wider than only GRUB2 as it can encompass a lot of systems using it or not to boot, including Windows. Read There’s a Hole in the Boot to know why and how.

cwizardone

07-31-2020 09:44 AM

There appears to be some serious security issues with xorg.

https://www.phoronix.com/scan.php?pa...CVE-2020-14344

Quote:

X.Org's Latest Security Woes Are Bugs In LibX11, Xserver
Written by Michael Larabel in X.Org on 31 July 2020 at 09:54 AM EDT.

The X.Org/X11 Server has been hit by many security vulnerabilities over the past decade as security researchers eye more open-source software. Some of these vulnerabilities date back to even the 80's and 90's given how X11 has built up over time. The X.Org Server security was previously characterized as being even worse than it looks while today the latest vulnerabilities have been made public.

CVE-2020-14344 is now public and covers multiple integer overflows and signed/unsigned comparison issues within the X Input Method implementation in the libX11 library. These issues can lead to heap corruption when handling malformed messages from an input method.

Several patches are now in libX11 Git for addressing these overflows and bad sign comparisons. LibX11 1.6.10 will be released shortly with these fixes.

More details on today's disclosure via the xorg-devel list.

Update: Further security issues are also being made public today... CVE-2020-14347 is public too as a bug in the pixmap data code leading to uninitialized heap memory being leaked to clients. In turn when paired with other flows and running the xorg-server as root could potentially lead to privilege escalation. X.Org Server 1.20.9 to be released soon with this fix, which was discovered as part of the Trend Micro Zero Day Initiative.

mats_b_tegner

09-03-2020 02:07 PM

GnuPG 2.2.23 released

https://lists.gnupg.org/pipermail/gn...q3/000448.html
https://dev.gnupg.org/T5050
https://www.gnupg.org/ftp/gcrypt/gnu...2.2.23.tar.bz2
https://www.gnupg.org/ftp/gcrypt/gnu...23.tar.bz2.sig

cwizardone

10-20-2020 06:12 AM

FreeType 2.10.4, is now available.

Quote:

....."This is an emergency release, fixing a severe vulnerability in embedded PNG bitmap handling...All users should update immediately."

https://www.freetype.org/

https://sourceforge.net/projects/fre...etype2/2.10.4/

Quote:

CHANGES BETWEEN 2.10.3 and 2.10.4
I. IMPORTANT BUG FIXES
- A heap buffer overflow has been found in the handling of embedded
PNG bitmaps, introduced in FreeType version 2.6.

https://cve.mitre.org/cgi-bin/cvenam...CVE-2020-15999

If you use option FT_CONFIG_OPTION_USE_PNG you should upgrade
immediately.
Source: README, updated 2020-10-20

The tarball, http://downloads.sourceforge.net/fre...-2.10.4.tar.xz

cwizardone

11-10-2020 08:26 PM

If you are running an Intel processor you might wnat to read this post in the kernel thread,
https://www.linuxquestions.org/quest...ml#post6184145

mats_b_tegner

11-20-2020 02:06 PM

Mutt 2.0.2 was released on November 20, 2020. This is an important bug-fix release, addressing CVE-2020-28896.
https://gitlab.com/muttmua/mutt/-/co...2863756ebbf59a
https://gitlab.com/muttmua/mutt/raw/stable/UPDATING
ftp://ftp.mutt.org/pub/mutt/mutt-2.0.2.tar.gz

All times are GMT -5. The time now is 04:14 PM.

Page 18 of 20

« First

Show 50 post(s) from this thread on one page