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

volkerdi 11-13-2019 12:17 PM

Quote:

Originally Posted by ehartman (Post 6057186)
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!

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

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)

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


All times are GMT -5. The time now is 08:36 PM.