Author Topic: OS/2 kernel requiring speculative execution patch!!!!  (Read 1464 times)

Devon

  • Newbie
  • *
  • Thank You
  • -Given: 2
  • -Receive: 5
  • Posts: 34
    • View Profile
Re: OS/2 kernel requiring speculative execution patch!!!!
« Reply #15 on: January 07, 2018, 02:27:17 am »
Yea, my understanding is that the way OS/2 manages its memory, getting access to kernel memory isn't that big of a deal as we don't have permissions or sandboxes so just need to read a different tabs memory or even the swap file if one exists.
As for the code, it seems to have to be tight assembler, which, as you say, has to target OS/2 and be delivered.
There is a proof of concept using Chromes JavaScript JIT but even that would have to be targeted as there are many code paths in the JIT depending on CPU etc.
The real problem is in data centres and such as this allows escaping from a virtual machine or/and getting roots password.

I'd need to see citations or a source test to confirm, because as far as I can tell, it is exploitable on x86 on any OS.

This link has a rather frightening graphic from Epic Games that shows the performance hit for their servers after a patch had been applied

https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update

Performance will be reduced under the following conditions:
#1 you're using Windows instead of Linux (NT kernel is worse at handling this than the Linux kernel)
#2 your CPUs lack PCID

So it's possible epicmegagames is running NT on pre-westmere CPUs.

Olafur Gunnlaugsson

  • Full Member
  • ***
  • Thank You
  • -Given: 25
  • -Receive: 8
  • Posts: 103
    • View Profile
Re: OS/2 kernel requiring speculative execution patch!!!!
« Reply #16 on: January 07, 2018, 02:31:54 am »
#1 you're using Windows instead of Linux (NT kernel is worse at handling this than the Linux kernel)

Where do you get that info from?

Dave Yeo

  • Hero Member
  • *****
  • Thank You
  • -Given: 8
  • -Receive: 93
  • Posts: 1216
    • View Profile
Re: OS/2 kernel requiring speculative execution patch!!!!
« Reply #17 on: January 07, 2018, 03:16:45 am »

I'd need to see citations or a source test to confirm, because as far as I can tell, it is exploitable on x86 on any OS.

Well you can some ideas about proofs of concept code here, https://googleprojectzero.blogspot.ca/2018/01/reading-privileged-memory-with-side.html

But think about it. What are you trying to protect? You're browsing history? Any process can read files on the disk and history is not encrypted. Your logins? They are encrypted on the disk and in the kernels disk cache memory, other then that they aren't in kernel memory. they may be in the browsers memory, in which case any JavaScript flaw can be used to read them as they're all in the same process. Another program could use Spectre to read a different processes memory.
So a malignant program could in theory read the browsers memory, it is going to have to be an OS/2 program that you run, possibly through trickery. Who is going to go to the trouble to write a malignant program and target you? Quite likely due to timing problems, the code will have to target your exact CPU, which I believe you've mentioned is an old one.
If you're really worried about security, there are easier flaws in our discontinued browser to exploit, often using cross platform code such as JavaScript. Much easier but even then you often get code trying to run C:\Windows\cmd.exe and failing on OS/2.
If you're really worried about security, you should run one of the BSD's and even then there is a risk of a zero day exploit.
The real worry is someone targeting your bank, a much richer target.

Devon

  • Newbie
  • *
  • Thank You
  • -Given: 2
  • -Receive: 5
  • Posts: 34
    • View Profile
Re: OS/2 kernel requiring speculative execution patch!!!!
« Reply #18 on: January 07, 2018, 10:47:54 am »
#1 you're using Windows instead of Linux (NT kernel is worse at handling this than the Linux kernel)

Where do you get that info from?

I'm honestly surprised at how pro-Windows people are in this day and age when Windows was traditionally derided for being an unstable bucket of frogs (which it still is).

One of the main reasons is that the KTPI fix implemented on Linux does not require PCID, which means performance won't hit pre-westmere CPUs that much. But not only that the way Windows has to work around the problem is a lot more messy due to the way Windows has everything in paged and non-paged pools--whereas this is not the case in Linux or any Unix for that matter because they're not dementedly designed like NT. Just google it, there's sources out there.