Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 23 Jan 2018, 06:24
All times are UTC - 4
 Forum index » Off-Topic Area » Security
Intel, AMD, ARM--all chips found to pose huge security risk
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [24 Posts]   Goto page: 1, 2 Next
Author Message
belham2

Joined: 15 Aug 2016
Posts: 1426

PostPosted: Thu 04 Jan 2018, 04:32    Post subject:  Intel, AMD, ARM--all chips found to pose huge security risk  

Guess this deserves its own thread, since it is not 'Intel' specific. Posted it another thread http://murga-linux.com/puppy/viewtopic.php?p=979185#979185 but no one seem to read it. Stuff is not just going on with Intel....there are bigger problems out there than just with Intel latest screw-up. There is NO excuse in any universe of chip-design I'm aware of for not knowing about possible bypasses of "memory isolation mechanisms" and then, worse, doing nothing about them all these years. Damn, as mentioned before, this behavior almost makes Microsoft look saintly all these decades releasing OSes with full knowledge they all were (and still are) vulnerable.

http://www.securityweek.com/intel-amd-chip-vulnerabilities-put-billions-devices-risk
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 805

PostPosted: Thu 04 Jan 2018, 04:35    Post subject:  

Here is what wired says:

Quote:

Although both attacks are based on the same general principle, Meltdown allows malicious programs to gain access to higher-privileged parts of a computer's memory, while Spectre steals data from the memory of other applications running on a machine. And while the researchers say that Meltdown is limited to Intel chips, they say that they've verified Spectre attacks on AMD and ARM processors, as well.

https://www.wired.com/story/critical-intel-flaw-breaks-basic-security-for-most-computers/?mbid=social_fb
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 12752
Location: Arizona USA

PostPosted: Thu 04 Jan 2018, 13:22    Post subject:  

Does this vulnerability allow for such as encrypting your stuff and demanding a ransom for the key, or does it only allow for poking around in your stuff and reading it?

Edit: more info from
Massive Intel CPU flaw: Understanding the technical details of Meltdown and Spectre
By James Sanders | January 4, 2018

And
How Linux is dealing with Meltdown and Spectre
By Steven J. Vaughan-Nichols for Linux and Open Source | January 4, 2018
Quote:
... In an email, Red Hat security wrote that the vulnerability affects x86 (Intel and AMD chipsets), POWER 8, POWER 9, System z, and ARM processors. AMD claimed its chips aren't vulnerable. In a statement, AMD said, "AMD is not susceptible to all three [attack] variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time."
Be that as it may, all three attacks have the potential to allow unauthorized read access to memory. There are three unique attack paths that could allow an attacker to execute a side-channel attack to bypass protections to read memory. ...

So it would seem that the flaw doesn't allow to execute anything, only to read what's in RAM.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1722

PostPosted: Sat 06 Jan 2018, 14:47    Post subject: the aftermath begins  

First, we should note the start of a legal battle that we will be able to tell grandchildren we saw begin.

Second, it seems people are dishing the dirt on other companies, starting with AMD. I will mention that this parallels Intel's problem with the IME that brings up their high-performance CPUs, though this implementation is very different.

I've had questions about the Trusted Security Platform initiative from the beginning because this was based on the idea of "security through obscurity". It was never opened up to analysis by independent investigators. As a problem limiting competition it served admirably, but I am not at all surprised that multiple implementations failed to address security, and even opened up new modes of attack.

Qualcomm also got in on the excitement.

The fundamental problem goes back to the era when architectures originally designed to be simple and small were scaled up without much consideration for implications. All the major processors today would count as "superscalar" architectures, as well as matching definitions for a list of other supercomputer marketing buzzwords. They also try to be both CISC and RISC processors, depending on the level at which you view them.

Note that MIPS and RISC machines which were designed with RISC architectures from day one do not suffer from these vulnerabilities.

Parallelism is a primary means of gaining a speed-up, and from other experience I can tell you it opens many cans of worms. Even a single-core chip today contains multiple pipelines. You also have multiple architectures on one chip, with CPUs also functioning as DSPs and vector processors. Floating point is still presented to programmers as a zero-address stack processor with limited stack depth. Inside it is implemented by microcode that behaves in a very different manner. The only term I can come up with for this architecture is "baroque".

Memory management was sort of an afterthought, since these designs started at a time when nobody really expected microcomputers to ever need more than a megabyte of main memory. The original x86 design beat designs that were limited to a 64 KB address space by introducing segmentation. This implementation of the previously-known idea of segmentation was so bad the term has been dropped from theoretical computer science. Suffice it to say that there were big machines with segmented memory prior to the x86 that had no such limitation to the size of segments.

Another feature of earlier segmented memory was built-in bounds checking on array accesses. This was deemed too expensive in terms of memory access speed, and was dropped. Spectre is one consequence of this decision.

The fundamental problem is that we tend to think of all computation taking place in one or more CPUs, ignoring the substantial computation involved in memory management before the CPU has anything to work on. We have concentrated on incredibly detailed memory timing, ignoring higher-level abstractions about what memory means.

(Think I exaggerate? Assignment: compare and contrast DDR3 9,9,9, 24 memory with DDR4 15,17,17, 36. Don't stop with bandwidth, explain the impact on average and worst-case latency.)

This neglect was made worse by reliance on passwords for security, with the same processor having several different hats it wears while executing code for different purposes at different levels of security. It should have been obvious all along that we needed to use one-time passwords (OTP) that would be useless if stolen, and that these needed to be generated by hardware that was physically isolated from any processor running untrusted code.

Such special-purpose processors are now remarkably cheap. We should not be having to replace machines worth thousands of dollars to correct a design error. It should be no more difficult than replacing a credit card or ID containing a chip.
Back to top
View user's profile Send private message 
Sailor Enceladus

Joined: 22 Feb 2016
Posts: 1426

PostPosted: Sat 06 Jan 2018, 14:58    Post subject:  

I found this image. It seems accurate enough to me Smile

Back to top
View user's profile Send private message 
belham2

Joined: 15 Aug 2016
Posts: 1426

PostPosted: Sat 06 Jan 2018, 17:06    Post subject:  

I've two questions:

1) Can anyone give a reply to Flash's question. I'd never thought of it, but now I am wondering what actually happens when we have encrypted partitions and/or encrypted (i.e. USB and/or HD) plug-ins?

2) Does running all web-facing apps in a tight sandbox help and/or matter? Or is it just window dressing and does not matter either? I run anticapitalista & crew's latest "antiX 64-bit", and since they made using "Firejail" pretty much braindead easy by integrating it & the Firejails great DE app FireTools, I always--100% of the time--always run my web-facing apps inside a Firejail. Am just wondering if this would help with either of these two bugaboos (Spectre 1 and 2) we're facing.



P.S. As a side note, if Sailor's graph represents true, have to say I am bit happy the house is all on AMD, except for the one Intel laptop (which I've decommissioned until more clarity is provided from Intel). But, alas, maybe I am just hoping against hope---in my house there's still a lot of Apple stuff floating around (iphones, ipads, itouches)...sigh
Firejail-Firetools-GUI-in-latest-antiX-64bit-frugal-install.jpg
 Description   
 Filesize   68.84 KB
 Viewed   499 Time(s)

Firejail-Firetools-GUI-in-latest-antiX-64bit-frugal-install.jpg

Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1722

PostPosted: Sun 07 Jan 2018, 09:50    Post subject:  

@belham2

I know I am not much of an authority, but here's my response to part of your queries.

Encrypted data has to be decrypted at some point to be used, no matter how it is handled. If there can be leakage between secure and untrusted processes, then the unencrypted data can be exposed. Even public key cryptography needs to be able to decrypt transmitted data using private keys on some processor.

The security principle at work here is that savvy attackers will go after the weakest link in the chain, wherever that might be.

Flash is correct in saying this is only about reading data, not remote execution of code. The problem there is that knowing what is supposed to be hidden opens you up to a wide range of known attacks that have been dealt with previously. There are good reasons for hiding sensitive data.

Simply as a proof of concept, the possibility of acquiring administrator passwords illustrates the danger of data leakage, but this is only the simplest and most obvious approach to compromise. Expect to see a long tail of exploits stemming from this class of vulnerabilities. Most of these will be hard to understand. Even the basic approach presented in the attacks already demonstrated depends on understanding details of processor timing that most programmers don't bother to consider.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1722

PostPosted: Sun 07 Jan 2018, 10:15    Post subject:  

At this point I can't resist telling an anecdote about a friend who is even older than I am, (there are still a few such people,) who told me that she doesn't do any business by computer.

"What do you do instead?", I asked.

"I call them on my phone, and give them my credit card number by voice."

This led to my anecdote about one time when I did this myself. I heard some clicking in the background, and correctly deduced that they were entering the data in their own computer system.

"What OS are you running?" (This led to a longer exchange I'll omit.)

Bottom line: this was a mom-and-pop shop running Windows-XP, which is no longer supported by Microsoft.
Back to top
View user's profile Send private message 
Flash
Official Dog Handler


Joined: 04 May 2005
Posts: 12752
Location: Arizona USA

PostPosted: Sun 07 Jan 2018, 11:07    Post subject:  

An important point: I think I read somewhere that an attacker needs physical access to the computer to exploit these flaws.
Back to top
View user's profile Send private message 
6502coder


Joined: 23 Mar 2009
Posts: 423
Location: Western United States

PostPosted: Sun 07 Jan 2018, 15:43    Post subject:  

You're probably thinking of something like this, quoted from the SA-00088 bulletin:

Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

I'm not sure that "local access" in this context means PHYSICAL access.
Back to top
View user's profile Send private message 
ac2011

Joined: 09 Feb 2011
Posts: 127

PostPosted: Mon 08 Jan 2018, 06:02    Post subject:  

6502coder wrote:

I'm not sure that "local access" in this context means PHYSICAL access.


I believe you are correct. I think that in security-nerd-speak, "local access" just means the code is running on the local machine, which might include JavaScript in a browser or, for server installations, a VM running something dodgy. It excludes very little.

That's what I read recently, anyway. I'm still getting up to speed on all this.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1722

PostPosted: Mon 08 Jan 2018, 09:54    Post subject:  

Right! "Local access" could be HTML, javascript, etc. run in an unsecured process on a browser. Because of cross-site scripting you can't even depend on being safe if you avoid dodgy sites. More often than not ads displayed when you access one site originate elsewhere. This is what pays for the Internet, so it can't simply be prohibited.

Just as an example of how far from your intentions such code can be I'll mention that it has been used for mining Bitcoin while others pay for the equipment and electrical power. This is massively inefficient, but then the attackers aren't paying for it.

Changing browsers can limit the danger from this source. I'm now using Firefox 57.0.4 and/or Google-Chrome-01072018-x86_64. Unfortunately, this means I have to learn how to use No-Script all over again, so that it doesn't stop me from reading articles like the following: Triple Meltdown.

One final irony: defensive measures against these vulnerabilities will likely interfere with antivirus programs or vice versa. There will not be any quick fix, and I hesitate to estimate how long it will take problems to shake out.

One more item: such an attack via code sent over the Internet would not necessarily leave any traces on the machine, the way other hacks do. If intelligence services of nation-states have been exploiting this we might not know.
Back to top
View user's profile Send private message 
8Geee


Joined: 12 May 2008
Posts: 1341
Location: N.E. USA

PostPosted: Mon 08 Jan 2018, 23:20    Post subject:  

I would like to point out a list by ARM(GB) of affected processors. The listing is here. Please read the full bulletin, dated Jan. 03, 2018.

Google/Android can do what they will, in some cases the ARM-processor needs a patch. Of all the discussion here, almost nothing on ARM, and whats vunerable to what problem.

Regards
8Geee

_________________
Linux user #498913

Good God!, by the stars in the sky we are lost!
And into the breach we got tossed!
And the world is comin' on fast! --Florence Welch
Back to top
View user's profile Send private message 
s243a

Joined: 02 Sep 2014
Posts: 805

PostPosted: Mon 08 Jan 2018, 23:31    Post subject:  

8Geee wrote:
I would like to point out a list by ARM(GB) of affected processors. The listing is here. Please read the full bulletin, dated Jan. 03, 2018.

Google/Android can do what they will, in some cases the ARM-processor needs a patch. Of all the discussion here, almost nothing on ARM, and whats vunerable to what problem.

Regards
8Geee


I think that the issue is potentially more serious on ARM because I trust popular software on the linux repositories much more then I do google play. We all know how many different aps people try on google play and I don't have much faith in googles oversite of it.

Then again maybe google has already pached this and we are safe.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1722

PostPosted: Tue 09 Jan 2018, 10:18    Post subject:  

Just as anticipated, the response to the problem is itself a problem. Some AMD processors (Athlons) have been unable to run anything beyond the startup screen with the Windows logo after the update. I suppose this solves the security problem caused by running Windows in the first place.

Other examples of updates borking various applications have turned up.

To be evenhanded, I will mention that IBM is also having problems with support in this crisis.

Systems which are not bricked only suffer substantial slowdowns. This means you can now get the performance from your high-end system you would have had if you had bought a cheaper system.

Microsoft, as I would have predicted, has decided they can no longer afford to support their OS after sale unless you keep paying them. Here comes software as a service.

Meanwhile, back at some old news, that move by Munich to convert their Linux systems to Windows, which was said to save 4 million Euros in support costs, will now cost 100 million Euros.

Note that after a successful conversion they will then have the privilege of paying whatever M$ decides they should in the future, with no control of source code or data formats. Should negotiations ever become a problem, M$ will have the option of letting them be molested by attackers.

If you read your licenses and terms of service/servitude, you will find they have absolutely no legally-binding responsibilities for your continued operation if anything at all goes wrong. You also have no right to know what is going on inside the machine you are said to own or the software you license from them.

Should you wish to dispute this, you might check on what happened with another lawsuit which has not had a single claim upheld in court. This involved SCO vs the entire Unix/Linux world, but M$ had paid SCO some hundreds of millions to avoid claims, and this fueled further litigation. The total cost of litigation passed $1 billion years ago. SCO had not done nearly the thorough job M$ has done to sew things up legally.

Personally, I doubt that some claims in M$ licensing and TOS are legally valid, but I am also sure that even the U.S. government and EU have failed to enforce any significant court judgment against them.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [24 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Security
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0798s ][ Queries: 12 (0.0142s) ][ GZIP on ]