flat assembler
Message board for the users of flat assembler.

flat assembler > Heap > Skype bug ‘system’ level access and English is the solution

Goto page Previous  1, 2, 3, 4, 5, 6  Next
Author
Thread Post new topic Reply to topic
sleepsleep



Joined: 05 Oct 2006
Posts: 7627
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
in the beginning, there is only 0 and then 1,
bit, then byte, then word, double word, quad word,

then the arts how to process them,
Post 05 May 2018, 14:17
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
revolution wrote:
I don't know the specific answers for that graphic. But in general, you won't be able to read memory that is not mapped by the page tables. So for most OSes you can't read the memory of other users because it isn't mapped into your address space. And without a mapping there is simply no way to address it.

So I expect the problem they describe is mostly for the browser. One tab can read the state of the entire browser memory. But it probably cannot read another process without some other exploit like calling a system function to map in memory from other processes. If you can trick the browser to call a system function then it could read memory from other processes under the same user. And since most OSes won't allow one user to map in memory from another user, then other user memory is likely not accessible.

And that is what makes Spectre and Meltdown nothing more than yet another way to do something, not the vulnerability by itself. If a browser allows some JS to perform quite tricky stuff which requires precise time measuring of memory accesses, it’s a vulnerability in the browser. If an OS holds sensitive data mapped to the application’s virtual address space, it’s the problem of an OS being too careless. Preliminary memory accesses through cache are just another way to take advantage from using such vulnerabilities, not the vulnerability itself.
Post 05 May 2018, 14:29
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
DimonSoft wrote:
And that is what makes Spectre and Meltdown nothing more than yet another way to do something, not the vulnerability by itself. If a browser allows some JS to perform quite tricky stuff which requires precise time measuring of memory accesses, it’s a vulnerability in the browser. If an OS holds sensitive data mapped to the application’s virtual address space, it’s the problem of an OS being too careless. Preliminary memory accesses through cache are just another way to take advantage from using such vulnerabilities, not the vulnerability itself.
I don't think they are the same. Normally the permission settings prevent a user from reading kernel memory. And if the CPU didn't have a bug then everything is fine. It is not efficient to have to keep mapping and unmapping memory all the time. So usually the OS won't unmap things, it just sets the permissions accordingly. The problem is that code can bypass the permissions the OS sets. And that is the major problem. Bypassing the settings means the settings are effectively useless. Not a good thing.

The browser/JS is the same. It isn't a problem in the browser. It is the JS exploiting a problem in the CPU.

So it all comes back the CPU not enforcing its own rules. It isn't that the OS did something wrong or bad. It is that the CPU has a bug.
Post 05 May 2018, 14:35
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
revolution wrote:
So it all comes back the CPU not enforcing its own rules. It isn't that the OS did something wrong or bad. It is that the CPU has a bug.


In fairness, so what? Bugs happen, and this is a minor one. Certainly Intel has robust testing in place to avoid most common functionality errors, but they can't catch everything.

It's unfair for us (or anybody) to expect them to be perfect. Would it be nice if they fixed it? Sure, but the main problem isn't their incompetence or broken functionality but the fact that every microscopic flaw is scrutinized by thousands all over the world, and certain people will use any excuse to misuse flaws in the system.

It's not really a technical problem but a social one. It really sucks that you can't even make honest, technical mistakes without someone exploiting it (for fleeting profit, if even that "good").

If you have to be 100% perfect just to exist in the world, then we're all doomed. Intel will never be flawless, and while it's noble to try to avoid flaws, it's an unwinnable war.

If someone is dumb enough to break the system, then they don't deserve good things. This is why we can't have nice things.

In a suffering world, nobody has a right to complain if they actively work to make things worse.

(Sorry to get all philosophical, but it's pointless arguing about who's to blame. It's not Intel's fault that criminals exist. They're not miracle workers, and they can't stop all bad deeds.)
Post 05 May 2018, 23:25
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1260
I see, that's good then. My only fear now is that the "new" Spectre exploits are worse, since Intel marked four as "critical" which is something they usually hesitate to do. Ah well, we'll see when they get published.
Post 05 May 2018, 23:43
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
rugxulo wrote:
In fairness, so what? Bugs happen, and this is a minor one.
I can't agree here. The bug is not minor. It affects a large population of CPUs and users, it can be done remotely through JS, it can read arbitrary memory. How is that minor?
Post 06 May 2018, 00:57
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
It's "minor" because it's not breaking major functionality and the cpu already passed all of their in-house tests overall (presumably). We can still use the afflicted computers effectively, it's just 1% error that "might" be intentionally exploited by some rare crackpot with an axe to grind. So it's minor in the sense that we shouldn't need to worry about it but are forced because of immoral people.

If it literally took all cpus offline or some other major flaw, that was ignored by legitimate testing beforehand, maybe you'd have a better point. I don't want to deny the problem, but it's overly magnified, not by importance or criticality, but moreso because some third-parties have no scruples.
Post 06 May 2018, 01:07
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1260
But if it can read memory beyond a VM, then it's a serious flaw. It might not be for you who has full control over your VMs at all times as a desktop user, but not for other cases.

You know, in virtualized servers and such. They run (by definition) untrusted 3rd party code for a (paid) account. Kind of a large security leak.
Post 06 May 2018, 16:11
View user's profile Send private message Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7627
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
another malware feature,
https://blog.google/products/chrome/improving-autoplay-chrome/
Quote:

Chrome does this by learning your preferences. If you don’t have browsing history, Chrome allows autoplay for over 1,000 sites where we see that the highest percentage of visitors play media with sound. As you browse the web, that list changes as Chrome learns and enables autoplay on sites where you play media with sound during most of your visits, and disables it on sites where you don’t. This way, Chrome gives you a personalized, predictable browsing experience.


wait, this mean sending my url back to google, damn it,
how is google going to know the 1000 sites unless they steal the data from surfers, Laughing crazy shit
Post 07 May 2018, 02:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
sleepsleep wrote:
how is google going to know the 1000 sites unless they steal the data from surfers, Laughing crazy shit
Didn't you know that Chrome OS and Chrome browser report everything back to Google? They are both free products so of course they are collecting your information.
Post 07 May 2018, 03:04
View user's profile Send private message Visit poster's website Reply with quote
sleepsleep



Joined: 05 Oct 2006
Posts: 7627
Location: ˛                              ⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣ Posts: 6699
in the name of ai learning, we could collect anything we want, just need a holy cause to justify every evil act,
Post 07 May 2018, 04:19
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
revolution wrote:
I don't think they are the same. Normally the permission settings prevent a user from reading kernel memory. And if the CPU didn't have a bug then everything is fine. It is not efficient to have to keep mapping and unmapping memory all the time. So usually the OS won't unmap things, it just sets the permissions accordingly. The problem is that code can bypass the permissions the OS sets. And that is the major problem. Bypassing the settings means the settings are effectively useless. Not a good thing.

The browser/JS is the same. It isn't a problem in the browser. It is the JS exploiting a problem in the CPU.

So it all comes back the CPU not enforcing its own rules. It isn't that the OS did something wrong or bad. It is that the CPU has a bug.

Well, the CPU enforces the rules. The order in which things are done is an implementation detail. That CPU accesses memory before ensuring it is allowed for the program doesn’t mean the mechanism doesn’t work. The program doesn’t get this data by means of direct access with an instruction.

Measuring time to perform unauthorized reads is like reading keyboard input by measuring the fluctuations that occur in power networks (or recording and analyzing clicking sounds) when you press a key. Yes, it might work with high probability but nobody actually guaranteed that the keyboard will not produce any side effects.

Suppose they fix it. Some day there will be thermal sensors on the socket that might be sensitive enough to tell the difference between cache and memory accesses. Should we fix it? Why not do it now?
Post 08 May 2018, 15:12
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1260
DimonSoft wrote:
Suppose they fix it. Some day there will be thermal sensors on the socket that might be sensitive enough to tell the difference between cache and memory accesses. Should we fix it? Why not do it now?
Well you could always make the thermal sensors less accurate purposefully.

Other than Meltdown, I wouldn't call Spectre "CPU bugs", just exploits, and yes they need to be fixed.

Say you're a major corporation and guarantee to your customers that your "data centers" are free from prying eyes -- you ensure this by building giant thick walls (we're not talking digital here, just an analogy). This works for a while, since nobody can see from outside what happens inside.

But then someone brings something like X-Ray binoculars or whatever, and can now snoop on it. What will you tell angry customers who thought their data was safe & secret? "It wasn't designed against X rays so it won't be fixed". And lose them all. Might even get a lawsuit against you... (no idea if you'll win though, IANAL).
Post 08 May 2018, 15:29
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
The actual CPU bug is this: Code that never gets executed is still able to affect other parts of the CPU. By allowing the CPU to begin executing code without knowing if it is valid to do so yet (speculative execution), we can then see the cache being changed. If the CPU, when it later cancels the execution of the instructions, was also able to undo the cache modifications, then there would be no Meltdown bug. But there is currently no practical way to rollback cache changes. The only "real" solution currently would be to disable speculative execution, but that would have a huge negative impact on performance, and CPUs wouldn't sell.

So instead the OS unmaps all memory except the running program's memory and a short exception handling stub. The Meltdown bug still exists but it leaves the user code only able to read its own memory, and the stub exception handler code. This also impacts performance whenever there is a context switch. Any single process browser running JS could still allow one tab to read the contents of another tab, or the contents of memory even for tabs you recently closed, or any other data the browser has cached in memory. So be careful about not mixing sensitive browsing with general browsing.
Post 08 May 2018, 16:16
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
Furs wrote:
What will you tell angry customers who thought their data was safe & secret? "It wasn't designed against X rays so it won't be fixed". And lose them all. Might even get a lawsuit against you... (no idea if you'll win though, IANAL).


I know the world always wants someone's head on a platter any time something goes wrong. But it's ridiculous to assume that Intel is wildly incompetent or intentionally negligent. There's no reason to even pretend that. It's just that we live in an angry world that envies and hates each other. If even the poor have many enemies, how much more the rich and powerful!

(I know that's a fairly obvious or simplistic thing to say, but I can't help it.)
Post 09 May 2018, 07:30
View user's profile Send private message Visit poster's website Reply with quote
rugxulo



Joined: 09 Aug 2005
Posts: 2309
Location: Usono (aka, USA)
revolution wrote:
The only "real" solution currently would be to disable speculative execution, but that would have a huge negative impact on performance, and CPUs wouldn't sell.


I call b.s. Sure, some people are spoiled, but the rest of us "normies" (oldies?) can live with weaker machines. Heck, my machines are already fairly old. I'd love to compare benchmarks to such "fixed" cpus. I'll bet it's still better than my rigs! I'm no pro, but I can still get stuff done even with "ancient" cpus.

Anyways, software optimizations are never truly optimal. So, call me crazy, but I think we can heavily improve most things. That should offset some losses.

But I guess only time will tell what will happen.
Post 09 May 2018, 07:34
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1260
rugxulo wrote:
I know the world always wants someone's head on a platter any time something goes wrong. But it's ridiculous to assume that Intel is wildly incompetent or intentionally negligent. There's no reason to even pretend that. It's just that we live in an angry world that envies and hates each other. If even the poor have many enemies, how much more the rich and powerful!

(I know that's a fairly obvious or simplistic thing to say, but I can't help it.)
Well I have nothing against Intel and I never said they are incompetent (in this context). It's not even an Intel-only problem anyway, I mean, AMD and even some ARM processors suffer from the same exploits (talking about Spectre here, not Meltdown).

However, if they refused to fix the exploit because "it's not a CPU bug", then that would have been incompetence. It's not so much that the exploit exists, but that the company refuses to fix it as "not our problem", it's not going to be good on your customers, hence my analogy.

I mean yeah, it might not be a bug, but it still has to be fixed. In software, some exploits are due to bugs (e.g. buffer overflows), but some are simply due to design. The latter are not bugs, but they still need to be fixed (the exploits), eventually.


BTW just for the record I know Intel didn't refuse to fix the exploits. But if they did refuse...
Post 09 May 2018, 10:58
View user's profile Send private message Reply with quote
DimonSoft



Joined: 03 Mar 2010
Posts: 419
Location: Belarus
Furs wrote:
Well you could always make the thermal sensors less accurate purposefully.
<…>
But then someone brings something like X-Ray binoculars or whatever, and can now snoop on it. What will you tell angry customers who thought their data was safe & secret? "It wasn't designed against X rays so it won't be fixed". And lose them all. Might even get a lawsuit against you... (no idea if you'll win though, IANAL).

Any physical process has its side effects, the difference is only in the difficulty of their detection. It becomes the war of walls and ladders as soon as we start protecting ourselves against them blindly.

Spectre and Meltdown rely on precise time measurement. Let’s just make timers less accurate purposefully? That would avoid performance degradation and decrease the hardware complexity, thus being a better solution from Occam’s razor point of view.

CPU guarantees that unauthorized memory accesses will not affect the program context (registers). We cannot imply arbitrary properties and guarantees. Any optimization has obvious effect on execution time, it’s what optimization is all about in the first place! Finding another way to get some additional information from observing the effect (or lack of effect) of optimization is just a matter of time.

With today’s level of hardware complexity where a tiny change might cause serious difference in performance (remember what revolution always says) the fact that a program can measure effects of caching reliably already implies that the program has nearly unlimited control over the machine code: performing such precise measurements from interpreted/JIT language is impossible since any instruction occasionally added or context switch in a multitasking system might change the time a lot.

So, what we have is either a JIT/interpreter which allows unlimited control over generated machine code (vulnerability is not in CPU, you’re on the other side of airtight hatchway long before) or an application which can read its own virtual address space. Since such application can only read the memory, it can’t map arbitrary physical memory pages. So the only thing to worry about are the kernel memory pages. And that is the only place where we can see it being, arguably, a bug. But all the sensitive information (user data, passwords) is already in the user mode. Let’s discuss what sensitive information can an application find in the kernel memory mapped to its VAS: I’m sure, it either gives nothing new to an attacker or should not be there and thus is a vulnerability in the OS. I can’t see where the vulnerability in Spectre/Meltdown they make so much buzz about is. And I can’t see anything severe in it.
Post 09 May 2018, 11:59
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 16057
Location: 112 Ocean Avenue, Amityville
DimonSoft wrote:
And I can’t see anything severe in it.
Kernel memory contains all sorts of information that random programs shouldn't have access to. For example: cryptographic keys, the keyboard buffer with all the keystrokes, network buffers with all communications data, and no doubt a lot more that I can't think of ATM.
Post 09 May 2018, 12:38
View user's profile Send private message Visit poster's website Reply with quote
Furs



Joined: 04 Mar 2016
Posts: 1260
Intel Postpones Patching 'Spectre NG' CPU Flaws

@DimonSoft: JIT is not random, it's always the same, if an attacker bothers for the specific target. Also, VMs don't even execute JIT they execute direct code.

So I can buy an account on a data center for some server hosting, they give me a VM and access to it, I upload my malicious Spectre NG code on that server and it's perfectly OK for me to read the memory of all the other VMs and expose those people's secrets?

Design flaw is not a bug (which is a mistake in the code), but if it's exploitable it needs to be fixed.
Post 09 May 2018, 14:30
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4, 5, 6  Next

< Last Thread | Next Thread >
Forum Rules:
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 can attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.