Announcement

Collapse
No announcement yet.

A Backdoor In AMD's Catalyst OpenCL Library?

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    here's the asm dump http://pastebin.com/K1hRupTp

    Comment


    • #32
      This is weird

      I've been looking throught the code (disassembled with IDA) and there some very weird things.

      The osTestBackdoorATI function takes two arguments. The first is a value used in the main switch, the other is a pointer.
      Depending on the first argument osTestBackdoorATI will call different functions.

      Now the weird part is that a lot of this code seems to be doing ... nothing at all.

      For example at the very start a global object's address is fetched from the GOT and placed into ebx. And then functions are called and ebx is overwritten before even being used.

      There's one function that does NOTHING AT ALL.
      It takes the value in ebx, does nothing with it, changes ebp, zeroes eax even if eax isn't used after this point, then restores ebp, canceling the changes, and returns.



      This definitely looks like handwritten assembly. A compiler would never generate empty functions like that. Not unless you disabled ~every optimisations.

      I'm still trying to understand what it's doing.

      Comment


      • #33
        Originally posted by FLHerne View Post
        Put my bet down for 'not actually a backdoor; humorously-named test function'.

        If you were going to put a top-secret NSA backdoor into your driver, why would you give it such an obvious name? You'd call it osDefinitelyNotABackdoor instead, right?!
        Never forget Microsoft and their NSAkey.

        Comment


        • #34
          Originally posted by FLHerne View Post
          Put my bet down for 'not actually a backdoor; humorously-named test function'.

          If you were going to put a top-secret NSA backdoor into your driver, why would you give it such an obvious name? You'd call it osDefinitelyNotABackdoor instead, right?!
          i would prefere:
          "osTrustMeThisIsNotABackDoor"

          Comment


          • #35
            Guys, seriously... I know with the recent NSA and Snowden stuff and all, but the word "backdoor" has a lot of other meanings besides something that can be used to invade your privacy and fetch your private information.

            As a software developer, if I had to put myself in the shoes of AMD devs, I guess it would make sense to use the name "osTestBackdoor" as the symbol for something like a function to be able to insert tests into a running driver to debug its behavior. That is my best guess about what it does, and if I were to write such a function, that would be a good thing to call it. I highly doubt it would be the type of backdoor you guys are thinking of with the NSA and everything, especially since the name is so obvious.

            Although, I guess it never hurts to be extra paranoid, just in case .

            Comment


            • #36
              Originally posted by Kemosabe View Post
              Let me summarize:
              1) Most likely you are Linux user.
              2) You considered buying a AMD GPU but not nVidia

              This implies:
              1) You do not need high end GPU performance
              2) You do not need bugfree OpenCL implementation (if you use it at all)

              Well, why the hell should you use catalyst then? I use radeon open source drivers every day (r600) and i am completely happy with it. Cities in Motions 2 runs great. :-P
              As an Nvidia owner moving to AMD Radeon they want a modern OpenCL stack that when fully matured will of course never be supported by NVidia, never mind a better combined LLVM/Clang experience working with the upcoming options in their OpenCL stack support of the R600 and new targets.

              Comment


              • #37
                Another backdoor funded by US tax money?

                Comment


                • #38
                  Originally posted by chuckula View Post
                  Jigga what?

                  Go look at the top contributors list to the Linux kernel sometime, you'll note that Intel consistently the largest contributing company that isn't a 100% Linux based organization like Redhat. You won't see AMD anywhere near the top of that list. I think that the fact that Intel is the first company to bring Android into the 64-bit world and that there are excellent Chromebooks running on Haswell parts speaks volumes about how important they think Linux is and where they are going with Linux.

                  Just remember that back in the 90's when Microsoft was on trial for anti-trust violations it was Jerry Sanders, CEO of AMD, who got up on the witness stand and testified in favor of Microsoft. I always remember that when their PR department starts up with the usual self-serving whining about how Intel is a "monopoly" or something.

                  Just remember that AMD branded its own CPUs as "Athlon XP" right around 2001 when Microsoft launched "Windows XP". You think that was a coincidence?

                  When thinking about Intel vs. AMD here's the easiest way to frame the question: "Would my machine even boot if I stripped out all the Linux code contributed by company X". If you strip out AMD's contributions, then even on an AMD box your machine would still boot fine (you might lose GPU drivers if you use open-source AMD drivers). If you strip out all the Intel-contributed code, your AMD box wouldn't even come close to completing a boot sequence.
                  Very good points.

                  Comment


                  • #39
                    maybe it is a cry for help and they wanted it to be found!!! XD
                    on the other hand i recently stumbled upon a case of pure ignorance in PR: #hasjustinelandedyet
                    maybe AMD is simply suffering from the same.. at least when it comes to linux...

                    Comment


                    • #40
                      https://twitter.com/grahamsellers/st...24033998995456 :

                      Originally posted by Graham Sellers
                      osTestBackdoorATI is a hook used by our automated tests to access memory usage statistics from the driver.

                      Comment


                      • #41
                        Great, now that everyone's finished tripping out over nothing (I'm especially impressed and inspired by the people who claim to change their buying behaviors in response to unsubstantiated garbage), we can get back to regular programming. I'm sure someone will reverse that portion of code anyway just to make sure.

                        Also, whoever claimed that a BIOS implementation was a firmware replacement, this is unfortunately not true on graphics cards. The "firmware" here is what needs to be loaded into various control units and microcontrollers inside the GPU core itself to allow all parts of the GPU to work properly, and has nothing to do with the video BIOS that the system BIOS calls to initialize the card for framebuffer/text mode.

                        A totally open firmware (or BIOS for that matter) would be nice, but I don't think there are many functional benefits to be had from doing that. Perhaps there could be a bug or two hidden in there, but other than that I think it is only a "feel good" thing that in the end makes no real difference. I think there would be far more functional benefits from implementing open firmware for flash memory controllers (eg, the tiny microcontroller inside SD cards or bigger controller in SSDs that manages sector relocation, error correction, and similar tasks to make dirt cheap and crap flash memory act like something that will hold data for you, and can hide any number of crazy bugs or failure modes that can eat your data whole!

                        Comment


                        • #42
                          Firmware is smaller, possibly less capable in terms of back doors

                          Originally posted by Annabel View Post
                          What if they have backdoors in the Firmware too? We need open devices, it's sad to see http://www.phoronix.com/scan.php?pag...tem&px=MTQ4MDU failed
                          Let's assume the worst-case scenario, and assume that online account passphrases are the target. Backdoors are presumed phone-home keyloggers until proven otherwise, though in this case both the name and nature of the software suggest to the contrary. Keyboard input is much more valuble than monitor output, mostly because it is far easier to move over the network.

                          Passphrases even in browser are not echoed to the screen. The question is this: How hard is it for the video code to capture keystrokes not echoed to screen? Next question and the big one is this: How hard is it to do this in a small firmware blob instead of a huge closed-source driver blob?

                          To implement a malicious backdoor in a firmware blob is made more difficult by the size of the blob. With my card, the 4 firmware blobs come out at 5.5 kB, 4.5 kb, 3.1 kb, and 24.4kb for the
                          smc (memory management?) blob. That's very little space for extras compared to 50+MB of binary driver, and looking for IP addresses and/or obfuscated IP addresses after decompilation might be possible, certainly would be possible for, say, nation-state resources in a country hostile to the US.

                          To send user passphrases of any kind out to a malicious server, the code would have to capture or log keystrokes, then send the take over the network to an IP addresss somewhere. What is the smallest code someone can write to do this? This behavior would be observable on Wireshark, and probably not obfuscated in any backdoor which is visibly named as a backdoor. Were the Catalyst symbol a law enforcement/ad tracking oriented backdoor and not a testing backdoor, surely a less suspicious name would be used.

                          Sometimes a binary can be treated as a black box, looking at inputs and outputs to determine its behavior, particularily the presence or absence of a single undesired behavior.

                          Someone with good Wireshark skills should run this test: Set up a network with one machine monitoring all network traffic, another as the test subject, and bridged to the Internet. On the test subject, run Radeon with no firmware and no acceleration, with firmware and acceleration, and then Catalyst. Mount encrypted devices at boot and from within X with no online applications running, looking for network activity-ANY network activity. Then compare network activity with a browser running and logging into something. That part will be the hard part and beyond my skills with Wireshark, as it requires detecting packets sent to anywhere other than the account server (and those related to it), the way Google Chrome was caught phoning home.

                          Short of all this we must look at defense. Open-source hardware is a long way off, if ever, For defenses today forget about it. For Snowden-level stuff you don't connect to a network, neutralizing phone-home shit anyway. For other machines a balancing test applies-will they risk a corporations's name in public to get your data and use it in court or to send ads?

                          The first defense is of course never echoing passphrases to screen. A "normal" video driver would see the length of the passphrase and simplify a brute-force attack, but little more.

                          The second defense applies to boot-time encryption passphrases: Catalyst is UMS, meaning it's not running when that passphrase is being handled. As of right now Catalyst users should not mount an important encrypted volume while X is running-but I've always assumed that on machines running blobs and networked. In fact, on Catalyst UMS also keeps the firmware out of the picture at boot time, at the expense of requiring that encrypted devices never be mounted while X is running and the network connected. Unfortunately current versions of Radeon cannot be run in UMS mode, even though they are otherwise considered more secure.

                          The third defense may require new code in DE's and in browsers: we know OpenGL keyboard functions exist. Is there any code in accelerated DE's or in browsers that could cause an OpenGL
                          keyboard command to be used while the browser is handling an online account passphrase or an SSL key?

                          A possible strong defense might be to run browsers only in a VM, with no access to hardware acceleration given to the VM, using something like IceWM within it or even having it just fullscreen the browser. Uploaded/downloaded files could move in and out of the VM image by mounting the image from the host environment with the network turned off.

                          Comment


                          • #43
                            Originally posted by chuckula View Post
                            Jigga what?

                            Go look at the top contributors list to the Linux kernel sometime, you'll note that Intel consistently the largest contributing company that isn't a 100% Linux based organization like Redhat. You won't see AMD anywhere near the top of that list. I think that the fact that Intel is the first company to bring Android into the 64-bit world and that there are excellent Chromebooks running on Haswell parts speaks volumes about how important they think Linux is and where they are going with Linux.

                            Just remember that back in the 90's when Microsoft was on trial for anti-trust violations it was Jerry Sanders, CEO of AMD, who got up on the witness stand and testified in favor of Microsoft. I always remember that when their PR department starts up with the usual self-serving whining about how Intel is a "monopoly" or something.

                            Just remember that AMD branded its own CPUs as "Athlon XP" right around 2001 when Microsoft launched "Windows XP". You think that was a coincidence?

                            When thinking about Intel vs. AMD here's the easiest way to frame the question: "Would my machine even boot if I stripped out all the Linux code contributed by company X". If you strip out AMD's contributions, then even on an AMD box your machine would still boot fine (you might lose GPU drivers if you use open-source AMD drivers). If you strip out all the Intel-contributed code, your AMD box wouldn't even come close to completing a boot sequence.
                            Intel did rape AMD by playing dirty, just cause AMD stuck up for M$ who it needed doesn't make them unvictimized. Intel does do things for Linux users, but so doesn't IBM, Google, Samsung and it's all very self serving. If AMD had more cash I would expect more but they're hurting thanks to Intel and bulldozer being very floppy. Remember that Michael the next time you complain about AMD not sending you things, They're a company that if something farts sideways could go bye bye quickly so cut them a break until things look better.

                            Comment


                            • #44
                              Disassembly

                              Originally posted by nightmarex View Post
                              here's the asm dump http://pastebin.com/K1hRupTp
                              Here, as well as in PasteBin http://pastebin.com/iaFnmDNW, is my decompilation of that 32-bit x86 assembler code.

                              Code:
                              /*
                              ebp+0x10: arg1
                              ebp+0xC:  alignmentPadding?
                              ebp+0x8:  arg0
                              ebp+0x4:  __return_address
                              ebp+0x0:  __old_base_pointer
                              ebp-0x4:  
                              */
                              
                              
                              
                              int osTestBackdoorATI(int arg0, DWORD* arg1){
                                  //prologue
                                  //push ebx
                                  //esp -= 0x74
                                  
                                  //load arg0 into edx
                                  //do damage to ebx with __i686.get_pc_thunk.bx
                                  //load arg1 into ecx
                                  
                                  if(arg0 == 1){//goto osTestBackdoorATI+96;
                                      return (unsigned)(unsigned char)
                                          osMemStateDifferent(arg1[0], arg1[1]);
                                  }else if(arg0 == 2){//goto osTestBackdoorATI+72;
                                      return (unsigned)(unsigned char)
                                          osMemStateDumpAllObjectsSince(arg1[0]);
                                  }else if(arg0 == 0){//goto osTestBackdoorATI+48;
                                      return (unsigned)(unsigned char)
                                          osMemStateCheckPoint(arg1[0]);
                                  }else{
                                      return 0;
                                  }
                                  
                                  //esp += 0x74
                                  //pop ebx           REPLICATED BEFORE EACH RETURN STATEMENT
                                  //epilogue
                              }
                              Where DWORD is with high likelyhood a pointer type.

                              I remain thoroughly unconvinced by the hyperventilation about backdoor spying here. This looks like a legitimate multiplex API to debug and checkpoint the state of the implementation.

                              Comment


                              • #45
                                Originally posted by oleid View Post
                                I can confirm the existence:
                                Code:
                                $ nm /usr/lib/libamdocl64.so | grep -i backdoor
                                000000000074dcf0 t osTestBackdoorATI
                                Yet, who would lable a symbol for some backdoor "backdor"? This makes it to my list of the dumbest accusations I heard so far
                                Didn't Microsoft have a NSABackdoorKey in their strings at one point?

                                Comment

                                Working...
                                X