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

Didier Spaier 01-15-2018 05:32 AM

Quote:

Originally Posted by abga (Post 5806619)
More good news about Intel, this time it's about AMT and I'm wondering if there's a way to flash that firmware from within Slackware, or do I need to boot a Redmond. Maybe I'll take the hard decision on this occasion and disable it for good.

https://press.f-secure.com/2018/01/1...orate-laptops/

If I understand well there is no need to flash the firmware, you can just disable AMT case occuring.

Cf. https://github.com/mjg59/mei-amt-check

PS Not sure it's the same CVS...

Anyway if one needs AMT the article you linked to suggest to just use a good password.

abga 01-15-2018 02:26 PM

Quote:

Originally Posted by Didier Spaier (Post 5806630)
If I understand well there is no need to flash the firmware, you can just disable AMT case occuring.

Cf. https://github.com/mjg59/mei-amt-check

PS Not sure it's the same CVS...

Anyway if one needs AMT the article you linked to suggest to just use a good password.

It's usually advised to change/put a strong password and after that some firmware updates, for changing default values and patching other not yet public issues, will pop up.
I have only one "business grade" DELL laptop that is "empowered" by this AMT (!@$@#$%^), it came with Win7 and I've missed already an Intel AMT firmware because the patch on DELL's support site works only under Win10 (obviously I didn't upgrade). I'm currently running only Slackware on this machine and was wondering if there's a way to update the firmware under Linux, just considering that there will be many more security issues & patches.
Intel AMT is supported under Linux:
https://www.kernel.org/doc/Documenta...es/mei/mei.txt
But apparently Intel doesn't provide any mitigation under Linux:
https://en.wikipedia.org/wiki/Intel_...and_mitigation

As mentioned, I'm really considering to go for the tools the guys at Positive Technologies provided and clean the whole thing. One problem less I need to care about. ;)
Reference:
https://www.linuxquestions.org/quest...ml#post5785847

GazL 01-17-2018 03:34 AM

Libc Realpath Buffer Underflow CVE-2018-1000001
 
Possible priv-escalation leveraging suid binaries.
ref: https://www.halfdog.net/Security/201...fferUnderflow/


Fix (amongst others) has been applied to https://sourceware.org/git/?p=glibc....se/2.26/master

abga 01-18-2018 02:32 PM

Quote:

Originally Posted by abga (Post 5805728)
This might be of interest for the ones (very) active on some threads here on the Slackware Forum discussing the update of CPU microcode on Intel processors:
https://newsroom.intel.com/news/inte...reboot-issues/

Again, trying not to interfere with the specific microcode updates threads, might annoy again someone, but using this general thread for general visibility:
https://newsroom.intel.com/news/firm...enter-systems/

"As I noted in my blog post last week, while the firmware updates are effective at mitigating exposure to the security issues, customers have reported more frequent reboots on firmware updated systems.

As part of this, we have determined that similar behavior occurs on other products in some configurations, including Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms. We have reproduced these issues internally and are making progress toward identifying the root cause. In parallel, we will be providing beta microcode to vendors for validation by next week."

It looks like there will be a patch of a patch of a patch, good that the firmware update process works and is documented now in the Slackware forum, might need to automate it and put it in crond ...

atelszewski 01-18-2018 03:21 PM

Hi,

Technically, it's not patch to a patch to...
You only upload single microcode file ;-)

--
Best regards,
Andrzej Telszewski

gmgf 01-19-2018 05:16 AM

libunwind-1.2.1-x86_64-1.txz: Added.

just for info, it seem some packages can be recompiled with libunwind support:

gstreamer, strace, mesa, xorg-server.

gmgf 01-19-2018 06:13 AM

Oopps Sorry posted in the bad thread

BratPit 01-19-2018 11:48 AM

https://skyfallattack.com

Darth Vader 01-19-2018 12:28 PM

Quote:

Originally Posted by BratPit (Post 5808638)

IF that can enlighten us a bit, the IP used by https://skyfallattack.com : 93.93.131.30 was in the past also of britishfantasysociety.org ;)

BratPit 01-19-2018 12:42 PM

Yes

but in that business you never know from ....

by the way
I checked if the last pre-meltdown free grsec patch for kernel 4.9.25 works for meltdown POC from here:

https://github.com/raphaelsc/Am-I-affected-by-Meltdown


Quote:

[15:28:44 --> root in Am-I-affected-by-Meltdown-master]$ ./meltdown-checker
Unable to find symbol sys_call_table in /proc/kallsyms
Falling back on the alternative symbol map file (usually requires root permission): /boot/System.map-4.9.25-grsec_test...
Checking whether system is affected by Variant 3: rogue data cache load (CVE-2017-5754), a.k.a MELTDOWN ...
Checking syscall table (sys_call_table) found at address 0xffffffff81801120 ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...
so far so good (i.e. meltdown safe) ...

System not affected (take it with a grain of salt though as false negative may be reported for specific environments; Please consider running it once again).

So far so good especially for x86.

abga 01-23-2018 12:29 PM

Quote:

Originally Posted by abga (Post 5808192)
Again, trying not to interfere with the specific microcode updates threads, might annoy again someone, but using this general thread for general visibility:
https://newsroom.intel.com/news/firm...enter-systems/

"As I noted in my blog post last week, while the firmware updates are effective at mitigating exposure to the security issues, customers have reported more frequent reboots on firmware updated systems.

As part of this, we have determined that similar behavior occurs on other products in some configurations, including Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms. We have reproduced these issues internally and are making progress toward identifying the root cause. In parallel, we will be providing beta microcode to vendors for validation by next week."

It looks like there will be a patch of a patch of a patch, good that the firmware update process works and is documented now in the Slackware forum, might need to automate it and put it in crond ...

Be advised, Intel is pushing microcode updates on some specific channels to revert what the first microcode Meltdown/Spectre patches had done:
https://www.auscert.org.au/bulletins/57150
https://support.hpe.com/hpsc/doc/pub...a00039267en_us
https://usn.ubuntu.com/usn/usn-3531-2/

Sir Linus Torvald's latest rant on the subject - some useful technical details to be found between the lines(NSFW):
http://lkml.iu.edu/hypermail/linux/k...1.2/04628.html

It looks to me like a typical organized chaos, where the parties (HW manufacturers - Intel, Kernel Devs. and Compiler Devs.) are racing to provide their own resolution. I still hope that the Spectre related vulnerabilities will be mitigated solely on the microcode level (enough complexity available in the latest CPUs) and that the things will soon settle down.

Thom1b 01-24-2018 01:41 AM

curl-7.58.0 is released with security fix
 
curl-7.58.0 is released with security fix.

Quote:

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

libcurl might leak authentication data to third parties.

When asked to send custom headers in its HTTP requests, libcurl will send that
set of headers first to the host in the initial URL but also, if asked to
follow redirects and a 30X HTTP response code is returned, to the host
mentioned in URL in the `Location:` response header value.

Sending the same set of headers to subsequest hosts is in particular a problem
for applications that pass on custom `Authorization:` headers, as this header
often contains privacy sensitive information or data that could allow others
to impersonate the libcurl-using client's request.

We are not aware of any exploit of this flaw.

INFO
----

This bug has existed since before curl 6.0. It existed in the first commit we
have recorded in the project.

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

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

- Affected versions: libcurl 7.1 to and including 7.57.0
- Not affected versions: libcurl >= 7.58.0

Thom1b 01-29-2018 01:18 AM

rsync-3.1.3 is released with security fix
 
rsync-3.1.3 is released with security fix.
http://rsync.samba.org/ftp/rsync/src...1.3.tar.gz.asc
http://rsync.samba.org/ftp/rsync/src/rsync-3.1.3.tar.gz

Quote:

NEWS for rsync 3.1.3 (28 Jan 2018)
Protocol: 31 (unchanged)
Changes since 3.1.2:

SECURITY FIXES:
- Fixed a buffer overrun in the protocol's handling of xattr names and
ensure that the received name is null terminated.
- Fix an issue with --protect-args where the user could specify the arg in
the protected-arg list and short-circuit some of the arg-sanitizing code.

Thom1b 01-30-2018 11:53 AM

mariadb-10.0.34 is released with security fixes. You can see changelog.

mralk3 03-11-2018 12:43 PM

Ruby gems is vulnerable, see for details: https://www.linuxquestions.org/quest...86#post5829686

For 14.2, ruby patch here: rubygems-276-for-ruby22.patch

Source: https://www.ruby-lang.org/en/news/20...s-in-rubygems/


All times are GMT -5. The time now is 12:20 PM.