SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Distribution: Slint64-14.2.1 on Lenovo Thinkpad W520
Posts: 8,101
Rep:
Quote:
Originally Posted by abga
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.
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
"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 ...
[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).
"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 ...
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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
