Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Desktops (Apple) Movies Operating Systems Security Software Television Technology

Mysterious Avid Issue Knocks Out Mac Pro Workstations Across Hollywood (variety.com) 98

A possible computer virus attack has knocked out Mac Pro workstations for many film and TV editors across Los Angeles. According to Variety, the issue -- which is causing the workstations to refuse to reboot -- is widespread among users of Mac Pro computers running older versions of Apple's operating system as well as Avid's Media Composer software. From the report: Avid said in a statement that it was aware of the issue: "Avid is aware of the reboot issue affecting Apple Mac Pro devices running some Avid products, which arose late yesterday. This issue is top priority for our engineering and support teams, who have been working diligently to determine and resolve the root cause. As we learn more, we will immediately publish information -- directly to our customers and via our community forums and social media platforms -- in order to resolve this issue for all affected customers and prevent any further issues."

"A lot of L.A. post shops and people out on shows having their Macs slowly crash," reported video post-production consultant Matt Penn on Twitter. Freelance film editor Marcus Pun reposted a message from a popular Avid Facebook user group, advising users not to turn off their workstations. Other users reported that multiple computers at their company were affected by the issue, with social media chatter indicating that a number of different companies, and even major shows like "Modern Family," were affected by the issue.
UPDATE: The issue appears to be caused by a Google Chrome update gone haywire.
This discussion has been archived. No new comments can be posted.

Mysterious Avid Issue Knocks Out Mac Pro Workstations Across Hollywood

Comments Filter:
  • Apple (Score:4, Funny)

    by Anonymous Coward on Tuesday September 24, 2019 @04:43PM (#59231978)

    Macs. They just wo-

    • Macs. They just wo-

      ...until the boutique software your run suffers from a supply chain compromise?

      • It's been confirmed it's actually google chrome doing it, not Avid

        So, hows your botique google chrome...?

        • And this is better, how? Still portends a serious problem.

        • It's been confirmed it's actually google chrome doing it, not Avid

          So, hows your botique google chrome...?

          Not boutique? Honestly I'm not sure what you're trying to say. It's a combination of Chrome and third party software that requires people to disable security features, if I read the article correctly. Does this make it an Apple problem again somehow and I missed it?

        • What is "botique"? Is that a mispelling of "boutique" or "botox"?

          And what does the fact that it is Google Chrome have to do with the boutiqueness of the software?

      • What, you mean the same problem Microsoft has been facing for decades and which has always been Microsoft's fault? Regardless if it was called Flash or Quicktime or whatever? Microsoft's fault.

        Yeah, well, this time it's Apple's fault. Apple machines stop working, Apple's fault. It's the software that's gumming it up? No, that's not how it works. APPLE'S FAULT.

    • I'm curious what magic allows a Mac to "slowly crash". I'm guessing they mean "get less responsive", like in low-memory scenarios?

      Anyhow, it's interesting that this is so widespread and apparently synchronized. That may mean this was very fast-spreading wormable malware, or, perhaps more likely, it was a payload introduced supply-side from Avid or some similarly common source. It wouldn't be the first time malware has slipped in as a payload with official software.

      It's also somewhat unusual for modern ma

      • Re:Apple (Score:5, Informative)

        by tlhIngan ( 30335 ) <slashdot&worf,net> on Tuesday September 24, 2019 @05:47PM (#59232118)

        Anyhow, it's interesting that this is so widespread and apparently synchronized. That may mean this was very fast-spreading wormable malware, or, perhaps more likely, it was a payload introduced supply-side from Avid or some similarly common source. It wouldn't be the first time malware has slipped in as a payload with official software.

        No, it's a strange combination of factors. It only happened now because most likely, Google updated Chrome yesterday.

        Effectively, there's a bug in Chrome and it destroys the /var symlink. Chrome users don't notice it because macOS comes with System Integrity Protection which prevents Chrome from messing up the system to begin with.

        But Avid users DID disable SIP simply because they wanted to get their hardware working, and their hardware did not go through Apple's process to certify and sign drivers. Likely because the accelerator card manufacturer was too cheap and decided to skip it on their expensive card.

        Now the Google Chrome bug comes into play, macOS' self-preservation feature was disabled, leading to an unbootable system.

        • Comment removed based on user account deletion
          • by jythie ( 914043 )
            I would spare the developer and yank whoever handles their test plan. A bug like that should have never made it through testing since disabling SIP, while not super common, is a thing many people do actually do.
            • by Wolfrider ( 856 )

              Disabling SIP is pretty much the only way I've found to keep the ReFind bootloader from being overwritten, if you want to dual-boot Linux on an iMac.

          • I will log on to my linux desktop run now and try to delete my /var as a regular user without fear of consequence.

            Just trying to delete /var is retarded on Google's parts, but presumably this means Chrome requires admin privileges for /something/ and that is unacceptable for a web browser. Is this some crazy thing like WebUSB that Apple is refusing to provide an API for?

            At some point, if you take full control of an OS to circumvent the vendor, "you break it you bought it". To avoid that, don't offer featu

        • Re: (Score:2, Troll)

          How on earth can a mere application bugger up the Operating System?

          What a total and complete hunk of shit is an operating system that cannot even maintain its own integrity.

          This is an Apple problem. How on earth could the Operating System permit this to happen?

          • Re:Apple (Score:5, Informative)

            by Mattcelt ( 454751 ) on Tuesday September 24, 2019 @07:05PM (#59232302)

            I'm not certain what you missed in GP's post...

            An irresponsible browser update destroyed part of the OS.

            The OS has a protection layer that prevents this from happening. No problem for most users.

            The irresponsible and ridiculously expensive software used to edit video couldn't be arsed to sign or certify their drivers.

            The same OS protection layer prevents said software/drivers from running without certification.

            Users turned off the protection layer to run their ridiculously expensive software.

            Ergo, the protection that prevented the irresponsible browser from buggering the system in all other cases was turned off by the users because of the irresponsible video software.

            IOW, you can't disable the brake and then blame the manufacturer when the car doesn't stop.

            • protection layer needs to be off to use non apple hardware is the bigger issue. windows does not force that on most hardware.

            • The same OS protection layer prevents said software/drivers from running without certification.

              And that's fucked up. Their "certification" is bullshit. The OS is supposed to be isolated from "software/drivers".

              *sigh* Some day they'll get real and make the OS truly read only

              • The next version of the OS (due to be released next month) uses a read-only system volume alongside the read/write data volume.

              • by jythie ( 914043 )
                A detail that is bothering me about this.. granted I have not had to tinker inside OSX for a while now, but last time I did, making changes to things like /var still required being root, so even with SIP disabled a user space application couldn't do this kind of damage. SIP, as I recall, stopped even superuser processes from altering parts of the system.
            • The users are doing what they need to do in order to get their work done. If they screwed up anywhere, it was counting on Apple.

            • There are a lot of other reasons to turn off SIP on a mac. Chrome is to blame for this.
              To bring in the car analogy, if I'm riding a motorcycle without a helmet in a state where that's legal, and a car hits me from behind, the fault is with driver, even though wearing a helmet might have saved my life.
              • What *are* those other reasons?

                • What *are* those other reasons [to disable SIP]?

                  If you need to make any edit to anything under /System/ or other protected directories. startup scripts, changes to the login screen, etc. Note that these are changes for a corporate or school environment, which also matches the Avid-user/Hollywood demographic in terms of homogeneous computing setup. I expect some highschools to have had this issue recently.

            • CAR ANALOGY WOOT

          • "How...?" sudo fuck shit up
        • Ah, interesting. I guess you've heard more than the official story. That makes much more sense than malware. I guess it's also true for software that crashes are caused by simultaneous failures. Just ordinary bugs colliding with bad practices by Avid users.

          That's pretty amazing, though, that Chrome would clobber the /var symlink. Hopefully as part of Chrome's automated test suite, SIP is turned OFF on macOS test machines to help catch future issues like this - along with specific regression tests check

          • by Wolfrider ( 856 )

            > it would be unforgivable if it ever happened again

            --It's d--n near unforgivable that they allowed it to happen ONCE. Chrome Canary has been very unstable for the last few weeks on OSX, and now mainline Chrome is making the box unbootable? Fix your s--t, Google!

        • by AmiMoJo ( 196126 )

          How much does certification cost? For Windows a basic cert (enough to install the driver with a "do you trust these guys?" request to the user) is about $200.

      • by guruevi ( 827432 )

        The Mac's Mach kernel is tuned for desktop work, similar to some Linux distro's. This allows "foreground" applications to be more responsive while trading throughput and swapping out inactive programs more aggressively as well as pre-empting the desktop applications over background applications in case of resource contention. This leads to a 'slow crash' or the spinning wheel of death where a single application could be hanging but everything "important" is still perfectly chugging along.

        In this case it see

  • by carlhaagen ( 1021273 ) on Tuesday September 24, 2019 @04:53PM (#59231994)
    • So spyware was sinking its teeth even deeper into places it shouldn't be. Who woulda thunk it.

    • This does not merit a catchy title. Really, there is only one beautiful and pure vulnerability, perfect in form and lacking nothing, and its name is Row Hammer .

      Oh, your vuln exploits a symlink or whatever? Well Row Hammer uses physics to flip targeted bits in memory and that will never stop being impressive.

      • This does not merit a catchy title. Really, there is only one beautiful and pure vulnerability, perfect in form and lacking nothing, and its name is Row Hammer .

        The sheer ingenuity of it and the fact that it actually works is indeed a thing of beauty.

    • by BlindWillieMcTell ( 5553362 ) on Tuesday September 24, 2019 @05:08PM (#59232040)

      It's not Avid doing it, it's Google Chrome

      If a browser issue is causing your workstation to not boot, the problem is with the operating system.

      • by chispito ( 1870390 ) on Tuesday September 24, 2019 @05:25PM (#59232090)

        It's not Avid doing it, it's Google Chrome

        If a browser issue is causing your workstation to not boot, the problem is with the operating system.

        Per the article, there is a standard security feature that many people running Avid disable in order to get third party drivers to run, and the issue only occurs in these systems. So it's kind of a Google and Avid and Apple problem.

        • Per the article, there is a standard security feature that many people running Avid disable in order to get third party drivers to run, and the issue only occurs in these systems. So it's kind of a Google and Avid and Apple problem.

          Not being able to get third party drivers to run without disabling security is also a problem with the operating system.

          There's no way around the fact that this problem represents OSX design flaws at more than one level.

          • by Logger ( 9214 )

            Avid could sign their driver, and it would load without disabling SIP. The moment you load an unsigned kernel extension, isn't really all bets are off? Isn't that true with other operating systems too? Or does Window's have a fine grained controls, such that you can limit what access a driver has access to? I would think such an architecture would come with severe performance penalties.

          • There's no way around the fact that this problem represents OSX design flaws at more than one level.

            So what your saying is Apple should turn off driver signing checks for drivers because people might turn driver signing checks off on account of third party developers not signing their drivers.

            Thats a nutty take dude.

            • No. Apple should warn users about unsigned drivers, and offer them (perhaps through a somewhat hidden system setting rather than an easy clickable popup) to install the driver regardless. What's nutty is that the only way to install unsigned drivers is to disable all of SIP. Car analogy: most cars have a way to disable the passenger airbag so you can fit a child seat there. This is like requiring the driver to pull a fuse that disables all airbags as well as ABS and traction control.
      • by berj ( 754323 ) on Tuesday September 24, 2019 @06:02PM (#59232154)

        If the "browser issue" is deleting a system file then the problem is with the browser that's deleting the system file.

        If users need to turn of OS-level file-system protections of said system file in order to get some drivers to install/work then the problem is with the makers of the drivers.

        • No. The problem is with the user that decided to defeat security. It appears that those users learned WHY they should not do that sort of thing, and hopefully they will go bankrupt and thus not have the opportunity to be so stupid again. Besides it will look good on their resume that the lost their last job because they "bankrupted the company by defeating security policy in order to permit shoddily crap to function" -- I should nope they will be on the dole for the remainder of their lives.

          I have to con

          • defeating security to run nvidia = don't use mac or other hardware that does not give you choice.

      • by Falos ( 2905315 )

        To be fair, apple blocks users by default*. To apple, "it shouldn't be possible", not in the walled garden. But anyone worth talking to knows better than to hide behind that phrase, than to write code that leans heavily on flow assumptions.

        >>the problem is with the operating system

        Hmm. To be fair to that, OSX probably shouldn't be going into shit-the-bed unbootable KP loop mode. Though I also have to wonder what the hell deletePathIfSymlink is up to, from a chrome updater.

        *people using external video cards or some shit

      • If a browser issue is causing your workstation to not boot, the problem is with the operating system.

        Apparently the problem is with Google’s Keystone auto-update daemon, which Google tries to foist on everyone but a sane person would never let run on their computer.

      • by Wrath0fb0b ( 302444 ) on Tuesday September 24, 2019 @09:51PM (#59232586)

        If a browser issue is causing your workstation to not boot, the problem is with the operating system.

        Since 2014, the macOS ships with a feature called System Integrity Protection [wikipedia.org] turned on by default. When enabled, this feature prevents all users (even root) from modifying areas of the disk that are supposed to be owned by the system. In this case, it prevents the issue [mrmacintosh.com] by refusing to allow Chrome to break the system.

        Now, lots of people, especially on /. would be very insistent that SIP be a feature that end users can disable. After all, it's your computer, you should (suitably warned) have the right to tinker with the system as you want, even if that means bricking your machine. Protection for the naive should not impact the power user. And indeed, MacOS obliges and allows the user to disable SIP (to prevent remote disablement, you have to reboot the machine into a separate partition that can set a flag to disable it, so you have to really mean it).

        So, is the problem with the OS? From the OS perspective, these users exercised their choice and deliberately went out of their way to disable the thing that would have preserved the integrity of the system, having been warned that it's not an excellent idea to do so. But hey, software freedom right?

        My fear here isn't so much that people give a shit about whether it's the OS or Chrome or Avid's fault, it's that these episodes strongly incentivize companies not to allow such power-user functionality because they get bad press when someone clicks "yes" to the "are you absolutely sure you want to do this" button and then they get bad press over the dumb fallout. I'm sure they want to support the power users as best they can within the constraints, but those folks have to take responsibility -- if you turn off system protection and then some bad software breaks your system, well, shit don't do that.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          Seems pretty obvious that 'allow unsigned drivers to load' should be a separate option from the rest of the system integrity protection. It's going to be a common requirement for people with obscure hardware.

          • by tlhIngan ( 30335 )

            Seems pretty obvious that 'allow unsigned drivers to load' should be a separate option from the rest of the system integrity protection. It's going to be a common requirement for people with obscure hardware.

            Why? What's the difference? An unsigned driver is basically unsigned kernel code, which basically means the two options are the same security wise. In fact, they're really aliases of each other because an unsigned driver pretty much disables system integrity - kernel mode things have a habit of doing th

        • by jythie ( 914043 )
          There is still a bit of blame for Chrome too though. SIP stops superuser processes from making certain alterations, but regular old unix access control stops user processes from making a much wider range. Why is Chrome's updater running as root in the first place?
          • Oh yeah, ton of blame for Chrome.

            I was really looking at the angle of how a browser was even able to brick the system, and I found the answer was because people turned off the anti-brick protection feature.

    • by Mal-2 ( 675116 )

      And the reason it showed up in Avid users first is that many of them are forced to disable SIP (which would prevent Chrome from modifying the /var symlink) in order to run third party video cards. Most users have no need to do this.

      • by dgatwood ( 11270 ) on Tuesday September 24, 2019 @05:23PM (#59232084) Homepage Journal

        And the reason it showed up in Avid users first is that many of them are forced to disable SIP (which would prevent Chrome from modifying the /var symlink) in order to run third party video cards. Most users have no need to do this.

        No user should need to do this. SIP doesn't prevent third-party drivers. They just have to be properly signed with an Apple Developer ID certificate.

        There are basically no legitimate reasons for an end user to turn off SIP, with the possible exception of hand-wiping enough of the OS to let you downgrade to an earlier version. If Avid is in any way encouraging users to turn off SIP, that's incredibly bad.

        • Comment removed based on user account deletion
        • Appleâ(TM)s refusal to sign nVidia drivers puts a lot of people in this position. Apple has actively blocked nVidia drivers from the MacOS ecosystem.

          What do video editors need? The fastest video cards.

          • Apple has always had shit third-party driver support. They want to own the whole horizontal.

          • by dgatwood ( 11270 ) on Wednesday September 25, 2019 @12:34AM (#59232802) Homepage Journal

            Unless I'm missing something pretty significant, I'm pretty sure pretty much everything you just said is incorrect. Certifying the driver with a given card is typically the job of the company building the NVIDIA-based card, not NVIDIA, and not Apple. The card maker is responsible for asking Apple to grant kext signing permission on their Developer ID certificate, after which they can sign their own kexts. Apple doesn't sign any kernel extensions except for the ones that they ship as part of the OS, and NVIDIA probably doesn't, either, because each card is likely to want its own kext with a specific version of the driver and an appropriate plist for matching against the card.

            Now to be fair, what a lot of folks do is hack one of the stock NVIDIA drivers to point it at a different, potentially unsupported card by changing the matching dictionary. But the right way to do that is with a codeless kext that merely forces the stock driver to match against different hardware, NOT by modifying the built-in Apple driver directly. And by doing it that way, there is no need to turn off SIP.

            Unfortunately, Apple, in their infinite wisdom, does not allow even codeless kexts to be unsigned, which is kind of a pain if you're hacking the driver yourself. That said, you don't have to disable SIP just to use unsigned kexts. All you have to do is set "kext-dev-mode=1" as part of your boot args.

            Like I said, there is no reason why ANY end user should EVER be disabling SIP. Ever. Ever. Ever.

            • by dgatwood ( 11270 ) on Wednesday September 25, 2019 @12:39AM (#59232808) Homepage Journal

              Actually, it looks like I'm a little out of date. Apple, in their infinite wisdom, recently removed the ability to load unsigned kexts, even for development. That's pretty awful.

              Either way, the point remains that the board vendors should be signing and shipping codeless kexts. There's nothing inherently preventing them from doing so.

              • You should not have to disable major features to install an unsigned driver. I decide what i want to run on my computer. Unsigned drivers should simply require an additional verification step, in which the system signs the driver at install time. That still prevents clandestine installs without forcing the user to bend over for the vendor. This scheme is pure and simple a way to exert undue control over the market for peripherals. And yes, i know Microsoft does the same thing, but "Microsoft was doing it" i

                • Unsigned drivers should simply require an additional verification step, in which the system signs the driver at install time

                  Verification step authorized by who? The user presumably.

                  This is really the ultimate problem that SIP and other protections are trying to solve, which is that "ask the user to grant X" is not super meaningful anymore. I get asked to elevate to root/admin routinely across Linux/Mac/Windows machines, and while the prompt is nice (and often declined), I don't actually know what the code t

                  • Saying "running an unsigned driver in the kernel should just require authorization" means that any of those mundane activities I authorized could actually be signing/loading a kernel deriver behind my back.

                    So make the authorization process different, and even more explicit. Make the user type "AUTHORIZE" or solve a little sudoku, or whatever makes you feel good about the process. Make it only available from within whatever tool your OS uses to manipulate driver settings. Just don't make the user disable protections that are in there for their benefit. That's ridiculous (which is why they are now being ridiculed.)

                    • by dgatwood ( 11270 )

                      I complained that codeless kexts shouldn't require signing way back when they first proposed this. It's an utterly silly design flaw that inevitably leads to problems like this.

                      That said, I disagree with you for drivers in general. Unsigned drivers with actual code are a special kind of risky, because they're running in the kernel, which means if they can't be trusted, then neither can your entire computer. I could pretty easily write a kext that would send every keystroke you type to a server in some t

                    • I guess this is why i run Linux when i want to get work done. Windows and Mac are for people who need someone to hold their dick for them while they piss. If you can't handle a UAC prompt, then maybe you should stick with an iPad. Or maybe just an abacus. The computer is there to serve me, not the other way around, and if i want to install a driver the OS shouldn't be making me do a little dance for its amusement. That you think such is acceptable is a sign of Stockholm syndrome. Beat me harder, ghost of St

        • >There are basically no legitimate reasons for an end user to turn off SIP

          Except, you know, if they need to use a 3rd party driver for hardware that is not signed by an apple developer id...
          Or do you think the end user should just, I dont know, write their own driver? Not use their hardware?

          The fault here would lie with the hardware developer not providing a signed driver - however with Apple there can be MANY reasons for that, because Apple will only 'bless' them with the required certificate if Apple d

          • by dgatwood ( 11270 )

            Or do you think the end user should just, I dont know, write their own driver? Not use their hardware?

            Scream at the hardware vendor until they spend the $99 for a developer program membership and sign the kext themselves?

            I mean, it's a pretty low bar.

          • by jythie ( 914043 )
            Well, you can blame the end user in that they probably should have given their vendor a hard time. "wait, the hardware you sold me requires disabling a critical part of the system? No, I'm not going to buy that". Vendors will do whatever they can get away with if it saves a few bucks.
        • by MeNeXT ( 200840 )

          Not sure why you think it's a good idea that you would need a manufacturer's permission to run a driver. Having to disable security because you still don't own the product you purchased tells me that there is more wrong here than blaming the user. Security of a product you own in the hands of another party is not security.

          • I think you're over-cooking a bit there.

            You don't need the manufacturer's (apple) permission to run a driver. What you do need, is to absolve them of supporting you if you choose to do something they don't support. You do indeed own the product, but the moment you want them to help you, or give you a (free) software update or whatever else, then you're obviously still in their pocket to some extent. If you don't want to be any part of Apple after you bought your mac, then turn off SIP and updates and suppor

        • by Wolfrider ( 856 )

          > There are basically no legitimate reasons for an end user to turn off SIP

          --Really? How unimaginative of you. Some of us like to dual-boot into Linux without having ReFind overwritten at random.

  • I need a new garbage can...
  • nvidia and non apple ati card lockout stage 1

    apple store says buy an new mac pro starting at 5999

  • "A lot of L.A. post shops and people out on shows having their Macs slowly crash,"

    Back when Apple used Motorola chips, they were able to crash astonishingly fast. We used to remark on how quickly they could shut down before [youtube.com].

  • NEVER! NEVER! allow automatic updating on production machines. They shouldn't even have Chrome on them. These aren't computers they are video editing workstations that are responsible for creating your companies product. You install your workflow on a base operating system only. Every update is tested in house on a non-production machine before being rolled out.

    • It's a workstation and should be reserved to that purpose. If the OS is multiple versions behind and requires kernel level functionality be disabled to let the hardware run then yeah, maybe don't install ANY NEW SOFTWARE on it.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...