Slashdot Mirror

← Back to Stories (view on slashdot.org)

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs (bleepingcomputer.com)

Posted by msmash on from the lost-in-translation dept.

Almost all major OS vendors released security patches yesterday after a researcher discovered that some OS makers have misinterpreted an Intel CPU debug feature and left their systems open to attacks. From a report: The vulnerability is in how the OS vendors implemented a hardware debug mechanism for Intel x86-64 architectures -- and more specifically the MOV SS and POP SS instructions. "In certain circumstances after the use of certain Intel x86-64 architecture instructions, a debug exception pointing to data in a lower ring (for most operating systems, the kernel Ring 0 level) is made available to operating system components running in Ring 3," the CERT/CC team explained in an advisory published yesterday. Explained in layman's terms, "this may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions." Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.

42 of 81 comments (clear)

  1. Linux distros based on the Linux Kernel by Anonymous Coward · · Score: 1

    yes there used to be one based on a BSD kernel, but now-a-days ???

    1. Re: Linux distros based on the Linux Kernel by darkain · · Score: 1

      Windows Subsystem for Linux? SmartOS LX Branded Zones?

    2. Re: Linux distros based on the Linux Kernel by K.+S.+Kyosuke · · Score: 1

      That was more of a GNU (+friends) distribution rather than a Linux distribution, wasn't it?

      --
      Ezekiel 23:20
    3. Re: Linux distros based on the Linux Kernel by laffer1 · · Score: 3, Informative

      This is still a thing. https://www.debian.org/ports/k...

      --
      MidnightBSD: The BSD for Everyone
  2. Wow ... by Anonymous Coward · · Score: 5, Insightful

    Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.

    That must have been some seriously badly written documentation if that many things made the same mistake.

    That inspires confidence.

    1. Re:Wow ... by mikael · · Score: 3, Interesting

      The documentation can be found here on page 2876 of this PDF file

      https://software.intel.com/sit...

      "6-8 Vol. 3A
      INTERRUPT AND EXCEPTION HANDLING
      If an interrupt or exception occurs after the new SS segment descriptor has been loaded but before the ESP register
      has been loaded, these two parts of the logical address into the stack space are inconsistent for the duration of the
      interrupt or exception handler (assuming that delivery of the interrupt or exception does not itself load a new stack
      pointer).
      To account for this situation, the processor prevents certain events from being delivered after execution of a MOV
      to SS instruction or a POP to SS instruction. The following items provide details:
        Any instruction breakpoint on the next instruction is suppressed (as if EFLAGS.RF were 1).
        Any data breakpoint on the MOV to SS instruction or POP to SS instruction is inhibited until the instruction
      boundary following the next instruction.
        Any single-step trap that would be delivered following the MOV to SS instruction or POP to SS instruction
      (because EFLAGS.TF is 1) is suppressed.
        The suppression and inhibition ends after delivery of an exception or the execution of the next instruction.
        If a sequence of consecutive instructions each loads the SS register (using MOV or POP), only the first is
      guaranteed to inhibit or suppress events in this way. Intel recommends that software use the LSS instruction to
        load the SS register and ESP together. The problem identified earlier does not apply to LSS, and the LSS
      instruction does not inhibit events as detailed above"

      Why document the MOV SS and POP SS instructions first, when the safer option is the LSS instruction.

      This seems to be the problem with technology these days. We are offered a dozen different ways of doing things in C++
      or assembly language, but only one way is the fastest.

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
  3. Sounds not like Intel's Poor Writing/ by Anonymous Coward · · Score: 5, Insightful

    If several unrelated Companies made the exact same error it is more likely poorly written documentation.

    1. Re:Sounds not like Intel's Poor Writing/ by skids · · Score: 1

      (snark)

      Well, maybe he was right. In this case, the engineers were the users who lacked the discipline to test the veracity of the documentation for the closed system for which they were writing their... pfeh... OS code. Real men design microcode dispatchers.

      (/snark)

      --
      Someone had to do it.
  4. AMD by williamyf · · Score: 1

    AMD is affected too...

    So, my question is:

    Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?

    Shouldn't said developer be using AMD's documentation? If so, then, how said developer was also afected?

    --
    *** Suerte a todos y Feliz dia!
    1. Re:AMD by David_Hart · · Score: 1

      AMD is affected too...

      So, my question is:

      Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?

      Shouldn't said developer be using AMD's documentation? If so, then, how said developer was also afected?

      I don't know the answer. But I believe that the AMD design is, in part, based on the early reverse engineering of one of the early Intel CPUs. It's quite possible that this issue is present in both because the instruction design is the same for both.

    2. Re:AMD by Megol · · Score: 4, Informative

      No AMD isn't affected. Intel isn't either. The problem is in software, it's the software that is affected.

      AMD implements the x86 ISA which was designed by Intel and second sourced by AMD for a while. AMD then started designing their own CPUs based on the same ISA as they had a license that let them do that (as decided by a court of law). They have reverse engineered and used documented sources to make their processors compatible with those of Intel.

      So if the hardware works in some specific way (with a few exceptions) then Intel and AMD will work the same. This is ignoring some processor extensions not always implemented by both companies.

    3. Re:AMD by Khyber · · Score: 1

      "Why a developer, developing for AMD-64 on top of AMD Hardware (think Athlon, Buldozer, Ryzen/Epyc et al) would be using an "INTEL's" Docs?"

      You don't fucking belong here. AMD and Intel cross-license all kinds of shit to each other for the x86-64 uArch.

      Nursing home time for you.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    4. Re:AMD by UnknownSoldier · · Score: 4, Informative

      TL:DR; Cross Licensing

      Intel cross licensed the x86 stuff (32-bit) to AMD.
      AMD cross licensed the AMD64 stuff (64-bit) to Intel.

      The longer version:

      Intel and AMD got tired of suing each other over patents. They have a LONG history of cross licensing agreements. They renewed it in 2001 and again in 2009.; AMD clarifyied the deal in 2015

      It is only natural AMD would use Intel's docs as part of the verification process for the 32-bit stuff.

      You can search intel amd cross license agreement for more info. but the agreement are (usually?) confidential.

    5. Re:AMD by BronsCon · · Score: 1

      Anyone who belongs in a nursing home is old enough to know what you just stated. I think you meant daycare.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
    6. Re: AMD by Anonymous Coward · · Score: 1

      the standard is literally called amd64. and people still think amd is a intel copycat.

      how can people be this dense?

    7. Re:AMD by AvitarX · · Score: 1

      Why did every software developer (well Linux, Apple, and MS) get this wrong, yet AMD got it right?

      That's interesting to me, it seems like Intel and AMD share more than just docs (which makes sense, but still interesting).

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    8. Re:AMD by mikael · · Score: 1

      It goes back decades to 1997. Back then, all the big workstations companies were making their own 64-bit processors; Intel, DEC (the DEC Alpha chip), Sun (SPARC) and MIPS.

      DEC and Intel got into a lawsuit, and settled for $700 million. DEC was eventually split in into bits, neither of which kept the original designers.
      https://www.wired.com/1997/10/...
      https://www.extremetech.com/co...
      https://www.pcworld.idg.com.au...

      DEC and ARM also cross-licensed each others patents, signed before the Intel lawsuit.
      Plus many of the designs are based on the original paper by Tomasulo:
      https://en.wikipedia.org/wiki/...

      --
      Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
    9. Re:AMD by Khyber · · Score: 1

      No, because even children have a better time remembering than old people. That's why it's called senility, for OLD people that now forget such basic shit.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    10. Re:AMD by BronsCon · · Score: 1

      But a child wouldn't remember something before their time.

      --
      APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
  5. Princess Bride moment by WoodstockJeff · · Score: 4, Funny

    You keep using that instruction. I do not think it means what you think it means.

    1. Re:Princess Bride moment by K.+S.+Kyosuke · · Score: 2

      Process Bride?

      --
      Ezekiel 23:20
    2. Re:Princess Bride moment by Anonymous Coward · · Score: 1

      Hello, my name is PA-RISC and you killed my architecture. Prepare to die.

    3. Re:Princess Bride moment by skids · · Score: 1

      Ahh, if only mod points went higher than 5.

      --
      Someone had to do it.
  6. Understandable by PingSpike · · Score: 1

    Intel probably just had the same guy that drafted the spectre/meltdown response press release write the document and he was kind of on a roll with the whole misdirection thing.

    1. Re:Understandable by Marxist+Hacker+42 · · Score: 1

      What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.

      Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
    2. Re:Understandable by caseih · · Score: 4, Informative

      Not at all. You may be the only human user on your system but every day you bring untrusted data and actually programs onto your computer in the form of web pages. With these vulnerabilities, a rogue JavaScript program running in a web site could grab your passwords sitting in memory for other processes. In fact one of the meltdown exploits first demonstrated was in JavaScript. So it's a bigger deal than you think and it does affect you even though you don't run a server and are the only user on your computer.

    3. Re:Understandable by jittles · · Score: 1

      What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.

      Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?

      For a variety of reasons. For one thing, the same kernel may be used in both single and multi-user environments. For another, what’s the point of having a root account, with sudo, or UAC, or whatever your access restriction is if a malicious program can easily circumvent those protections and operate at ring -1 or whatever ring that exception is handled at? Just remember that even a single-user may not realize what instructions are being executed on their machine through javascript, or some piece of software that they downloaded. This could be used to open up the entire system to the malicious user’s control by disabling security settings or enabling services that would have required a privilege escalation to complete.

    4. Re:Understandable by Nkwe · · Score: 2

      What I don't get about spectre, meltdown, and now this- is why any *single user* computer cares about accessing the user's own data, regardless of what ring they are in.

      Isn't this only a problem for servers and multiple user computers? Why patch user level OS for this?

      Because while you may think your computer is "single user", if you are on the Internet (well the Web anyway), there are other "users" actually using your computer. These "users" are things like scripts running on web pages and any malware that you may have obtained. Sure the "user" isn't another person, but it is a process or may come from an actor that may not have good intentions. The same is actually true for any software that you install and didn't write yourself (which is most of it.) Because of this even single user computers have the concept of secure areas or sandboxes where you can run untrusted software. It may be helpful instead of thinking about multiple users, think about multiple security contexts. The issue here is that there are low level instructions normally used by software developers debugging software that allow programs in sandboxes to get out of the sandbox and apparently the documentation that describes this is not clear.

      All this being said, modern operating systems *are* multi-user. Sure, one person may own the computer and only create one account on the computer, but the operating system allows you to have multiple logins.

    5. Re:Understandable by sexconker · · Score: 1

      The "users" of the computer are the various chunks of code running on it and, ultimately, whoever they phone home to.

      Unless you audit and understand all code running on your system, you have to prevent programs from being naughty and reaching into some other program's cookie jar.

    6. Re:Understandable by Marxist+Hacker+42 · · Score: 1

      Isn't that why you browse with Lynx and turn off scripting?

      --
      SJW: a person who perceives an injustice, and while correcting it, commits a greater injustice.
  7. Operating systems that mishandle... by macxcool · · Score: 1

    Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel -- which is also affected.

    Apple, Microsoft, and Red Hat are not operation systems ;-) Also, I think most Linux distros are based on the Linux Kernel.

    1. Re:Operating systems that mishandle... by fibonacci8 · · Score: 1

      ... Apple, Microsoft... Red Hat... and other Linux distros... Motion to have the sentence taken out back and shot.

      --
      Inheritance is the sincerest form of nepotism.
  8. NetBSD and OpenBSD "Not Affected" by Ichijo · · Score: 1

    Good work, BSD teams!

    --
    Any sufficiently unpopular but cohesive argument is indistinguishable from trolling.
    1. Re:NetBSD and OpenBSD "Not Affected" by afidel · · Score: 5, Informative

      Yeah, looked for OpenBSD and wasn't all that surprised that they weren't affected. Theo is a bit of a douche to work with but he's usually right when it comes to security. OpenBSD also wasn't vulnerable to Meltdown and the OS level variants of Specter because he was already paranoid about cache flushing when thunking between rings due to an earlier Intel bug that he didn't believe was correctly addressed.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    2. Re: NetBSD and OpenBSD "Not Affected" by Mr.+Competence · · Score: 1

      Oh yeah? And what about your cozy little problem with Linux compatibility you Mormons!

      Mormons are fully Linux compatible. Some of them even use BSD.

      --
      Those who open their minds too far often let their brains fall out.
  9. To be fair by JOstrow · · Score: 4, Interesting

    If the custodians of every major OS misinterpreted the same document in the same way, shouldn't we consider that the document itself is suspect / at fault instead?

    1. Re:To be fair by Medievalist · · Score: 2

      Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros...

      Windows isn't on the list, but I don't know if that means it's definitely not affected.

      I've heard that Windows is the name of Microsoft's Operating System.

      Could be fake news, I guess? Maybe Russians al up in ur nets?

    2. Re:To be fair by yorgasor · · Score: 1

      " Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel"

      I'm pretty sure Windows falls under the 'Microsoft' category.

      --
      Looking for a computer support specialist for your small business? Check out
  10. Re:What about Windows? by yorgasor · · Score: 1

    "Operating systems that mishandle this debug exception and had their systems open to attacks include Apple, Microsoft, FreeBSD, Red Hat, Ubuntu, SUSE Linux, and other Linux distros based on the Linux Kernel"

    It's safe to assume that Windows falls under the 'Microsoft' category.

    --
    Looking for a computer support specialist for your small business? Check out
  11. fip by AndyKron · · Score: 1

    Face in palm.

  12. Oh, NOW I get it. by ambrose.carracho · · Score: 1

    Explained in layman's terms, "this may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions."

    @msmash: I, for one, laud your biddable rectitude anent proffering pleonasm-eschewing elucidationary paraphrasing. Kudos!

  13. Re:What about Windows? by wonkey_monkey · · Score: 1

    There's nothing wrong with my reading comprehension. It's my reading itself that needs work...

    --
    systemd is Roko's Basilisk.