Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Security Bug Operating Systems

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

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.
This discussion has been archived. No new comments can be posted.

Multiple OS Vendors Release Security Patches After Misinterpreting Intel Docs

Comments Filter:
  • by Anonymous Coward

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

  • Wow ... (Score:5, Insightful)

    by Anonymous Coward on Wednesday May 09, 2018 @01:34PM (#56582264)

    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.

    • Re:Wow ... (Score:4, Interesting)

      by mikael ( 484 ) on Wednesday May 09, 2018 @06:30PM (#56584400)

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

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

      "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.

  • by Anonymous Coward on Wednesday May 09, 2018 @01:42PM (#56582340)

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

  • 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?

    • 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.

      • by Anonymous Coward

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

        how can people be this dense?

    • Re:AMD (Score:5, Informative)

      by Megol ( 3135005 ) on Wednesday May 09, 2018 @02:13PM (#56582582)

      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.

    • by Khyber ( 864651 )

      "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.

      • Anyone who belongs in a nursing home is old enough to know what you just stated. I think you meant daycare.
        • by Khyber ( 864651 )

          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.

    • Re:AMD (Score:5, Informative)

      by UnknownSoldier ( 67820 ) on Wednesday May 09, 2018 @02:47PM (#56582822)

      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 [edn.com] and again in 2009. [zdnet.com]; AMD clarifyied the deal in 2015 [kitguru.net]

      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 [google.com] for more info. but the agreement are (usually?) confidential.

      • by AvitarX ( 172628 )

        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).

  • by WoodstockJeff ( 568111 ) on Wednesday May 09, 2018 @01:47PM (#56582382) Homepage

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

  • 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.

    • 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?

      • Re:Understandable (Score:5, Informative)

        by caseih ( 160668 ) on Wednesday May 09, 2018 @02:17PM (#56582600)

        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.

      • 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 o

      • by Nkwe ( 604125 )

        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 e

      • 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.

  • 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.

    • ... Apple, Microsoft... Red Hat... and other Linux distros... Motion to have the sentence taken out back and shot.
  • Good work, BSD teams!
    • by afidel ( 530433 ) on Wednesday May 09, 2018 @02:40PM (#56582778)

      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.

  • To be fair (Score:5, Interesting)

    by JOstrow ( 730908 ) <jostrow@x13designs.com> on Wednesday May 09, 2018 @03:10PM (#56582944) Homepage

    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?

    • If the custodians of every major OS

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

      • 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?

      • " 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.

  • Given that Windows - by far and away the most-used operating system - isn't on the list, are we supposed to assume it's safe?

    A confirmation either way would be nice, given the seriousness of the problem.

    • "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.

  • Face in palm.
  • 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!

Time to take stock. Go home with some office supplies.

Working...