*The BBC is reporting major bugs in basically all CPUs, but is not saying what they are.

Joined: April 5th, 2005, 9:24 pm

January 4th, 2018, 1:04 pm #1

*The BBC is reporting major bugs in basically all CPUs, but is not saying what they are.
Quote
Like
Share

Joined: April 5th, 2005, 9:24 pm

January 4th, 2018, 2:01 pm #2

Both alleged vulnerabilities involve speculative execution. It seems that using speculative execution and measuring the timing of memory access can leak information about kernel memory. There are claims that this can allow attacking code to actually read kernel memory, and memory from other user programs, revealing passwords and such.

It is not yet clear to me how the timing information reveals the contents of memory.

Going out on a limb here: Maybe by doing a bunch of speculative comparisons? Like if you know a password is at a particular kernel address, perform a comparison on it, then conditionally, a read from another memory location? Maybe, the 1st read and comparison happen before the security check, and conditionally the second read, and if it took longer, you can deduce that the second read occurred, and the condition was true? Flush the cache, and repeat, playing a game of guess higher/lower, until you have read the data? That's the only way i can think of that a timing attack would reveal actual data.

As for address space randomization, I have been of the opinion that it is not, or should not be, necessary.

Regards,
Michael.
Last edited by MCalkins on January 4th, 2018, 2:03 pm, edited 1 time in total.
Quote
Like
Share

Joined: August 14th, 2017, 2:44 am

January 4th, 2018, 2:11 pm #3

As for address space randomization, I have been of the opinion that it is not, or should not be, necessary.

if you dont have it, it is easier to manipulate/attack parts of ram that should not ideally be manipulated or attacked.

if the reason you think its not necessary is because some other mechanism is protecting it, then the mechanism is insufficient on its own. define insufficient-- it left the ram too vulnerable.

whether its necessary or not, i think the idea is that its better security. sort of like ssl/https on websites (which sure aint perfect) is better than http/no ssl, random address space is better than the lack of it.

unless of course, you know a reason this isnt the case. i mean, im happy to hear that out. as for "or should not be" <- what does that mean?
Quote
Like
Share

Joined: April 5th, 2005, 9:24 pm

January 4th, 2018, 2:47 pm #4

address space randomization is meant to protect against classic buffer overflow attacks. Such vulnerabilities should not be in modern software. And there are other ways to protect against them, such as having compilers put canary values, and code analysis.

Normally, the read-only parts of program modules (EXEs and DLLs) can be shared between multiple processes. I'm thinking user-mode address space randomization would or could interfere with this. (though maybe all the processes could use the same randomized addresses? but even if so, you'd still have to use the page file for backing instead of using the original EXE/DLL files for backing.)

And I don't see the point of kernel mode address randomization. I don't understand how it provides any substantial protection. It might make an attack more difficult, but probably wouldn't stop one. It is unnecessary complication.

Didn't the vulnerability you mentioned here:
http://www.network54.com/Forum/554399/m ... everywhere
involve defeating address space randomization?
P.S. that might not have been you. too much capitalization... :-)

Regards,
Michael
Last edited by MCalkins on January 4th, 2018, 2:49 pm, edited 1 time in total.
Quote
Like
Share

Joined: August 14th, 2017, 2:44 am

January 4th, 2018, 11:47 pm #5

i wouldnt let the smileys stop the code from displaying, and more than that, the indentation (in full paragraphs) is the surest sign that wasnt me.

DUDE:

address space randomization is meant to protect against classic buffer overflow attacks. Such vulnerabilities should not be in modern software.

BUT THEY ARE THOUGH... and as long as they are... this is your use of "liberal" vs. conservative all over again. its one of those (hopefully rare) situations where being technically correct is almost less relevant than everything else.


what youre saying is sort of like "bullet proof vests shouldnt be necessary"

"why?"

"because people shouldnt shoot each other." well, DUH...

but lets give you the benefit of the:


"And there are other ways to protect against them, such as having compilers put canary values, and code analysis."

those are tools for reducing the number of buffer overflow vulnerabilities, while address randomisation reduces the effectiveness of buffer overflow attacks.


so what youre basically saying is like saying:

"condoms shouldnt be necessary because people shouldnt have stds and they shouldnt do stuff when ovulating"

oh yeah! why didnt anyone think of that :(

you can have an operating system without address randomisation, so youre technically right. but so far, you seem to be confusing "other ways to mitigate" with "no need for this mitigation."

totally possible im reading too much into what youre saying, but when you make a remark like "______ shouldnt be necessary" when it actually serves a purpose that is not adequately served by other means (in practice, and despite a whole lot of effort already...) cmon, man. i almost want to ask "what does that even mean?" though you already answered it.

at least i know what you meant now :/

eh.
Quote
Like
Share

Joined: April 5th, 2005, 9:24 pm

January 5th, 2018, 3:29 am #6

Both alleged vulnerabilities involve speculative execution. It seems that using speculative execution and measuring the timing of memory access can leak information about kernel memory. There are claims that this can allow attacking code to actually read kernel memory, and memory from other user programs, revealing passwords and such.

It is not yet clear to me how the timing information reveals the contents of memory.

Going out on a limb here: Maybe by doing a bunch of speculative comparisons? Like if you know a password is at a particular kernel address, perform a comparison on it, then conditionally, a read from another memory location? Maybe, the 1st read and comparison happen before the security check, and conditionally the second read, and if it took longer, you can deduce that the second read occurred, and the condition was true? Flush the cache, and repeat, playing a game of guess higher/lower, until you have read the data? That's the only way i can think of that a timing attack would reveal actual data.

As for address space randomization, I have been of the opinion that it is not, or should not be, necessary.

Regards,
Michael.
https://cyber.wtf/2017/07/28/negative-r ... user-mode/

it looks like what he wanted to do was read kernel memory 1 bit at a time, by speculatively using the contents of kernel memory to cache memory from one of two user mode locations. He could then use timing to determine which user memory was cached, and thus the value of the bit of kernel memory.

There was something about hardware threads and multiple cores. If I understand correctly, he uses junk arithmetic to keep one core busy, or something.

Anyway, if that's all it was, then instead of using kernel page table isolation, and punishing all system calls, why not have the page fault interrupt handler/exception dispatcher flush the cache and maybe introduce a random delay, thus punishing the rarer (exceptional) access violation page faults instead of all system calls?

Note that the blog linked above was preliminary work which seems to have led up to this scandal. I haven't had time to read the details of the vulnerabilities/exploits themselves. I'm sure the OS devs would have thought of flushing the cache from the interrupt handler/exception dispatcher, so they seem to have felt that more was necessary.

Regards,
Michael

Edit: i pasted the wrong URL.
Last edited by MCalkins on January 5th, 2018, 3:31 am, edited 1 time in total.
Quote
Like
Share