Announcement

Collapse
No announcement yet.

A Backdoor In AMD's Catalyst OpenCL Library?

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

  • #41
    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


    • #42
      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


      • #43
        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


        • #44
          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


          • #45
            Doesn't look much like a keylogger or a phone home

            Originally posted by Idonotexist View Post
            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.
            I don't see anything in this that looks like an IP address or a URL, the sort of thing the kind of backdoor I worry about would have to include. If there was one in Catalyst, it wouold have to be be elsewhere-but AMD would be nuts to risk such a thing existing and being discovered. They are not Intel and cannot tell their customers to put up or shut up.

            Comment


            • #46
              Originally posted by svanheulen
              And now, for those who prefer a less sensationalist news source...

              Note how you haven't seen such outrageous claims by known and reputable sources. I don't doubt MS has a lot of cooperation with government agencies, and like any sane person I'm not going to justify that, but to be fair it's not like they have much of a choice. Look at what happened to Lavabit and others.

              Comment


              • #47
                Complete decompilation

                It's confirmed; Under the light assumption of no self-modifying code, there is no back door.

                Here is the disassembly of all machine code reachable from the function "osTestBackdoorATI", for the latest Linux Catalyst 13.12 x86-64 bit version from here (http://www2.ati.com/drivers/linux/am...x86.x86_64.zip).

                Code:
                libamdocl64.so:     file format elf64-x86-64
                
                
                Disassembly of section .text:
                
                000000000074f270 <osTestBackdoorATI>:
                  74f270:       48 83 ec 38             sub    $0x38,%rsp
                  74f274:       83 ff 01                cmp    $0x1,%edi
                  74f277:       74 47                   je     74f2c0 <osTestBackdoorATI+0x50>
                  74f279:       83 ff 02                cmp    $0x2,%edi
                  74f27c:       74 2a                   je     74f2a8 <osTestBackdoorATI+0x38>
                  74f27e:       31 c0                   xor    %eax,%eax
                  74f280:       85 ff                   test   %edi,%edi
                  74f282:       74 0c                   je     74f290 <osTestBackdoorATI+0x20>
                  74f284:       48 83 c4 38             add    $0x38,%rsp
                  74f288:       c3                      retq   
                  74f289:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
                  
                  74f290:       48 8b 3a                mov    (%rdx),%rdi
                  74f293:       e8 08 39 00 00          callq  752ba0 <osMemStateCheckPoint>
                  74f298:       48 83 c4 38             add    $0x38,%rsp
                  74f29c:       0f b6 c0                movzbl %al,%eax
                  74f29f:       90                      nop
                  74f2a0:       c3                      retq   
                  74f2a1:       0f 1f 80 00 00 00 00    nopl   0x0(%rax)
                  
                  74f2a8:       48 8b 3a                mov    (%rdx),%rdi
                  74f2ab:       e8 10 39 00 00          callq  752bc0 <osMemStateDumpAllObjectsSince>
                  74f2b0:       48 83 c4 38             add    $0x38,%rsp
                  74f2b4:       0f b6 c0                movzbl %al,%eax
                  74f2b7:       c3                      retq   
                  74f2b8:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
                  74f2bf:       00 
                  
                  74f2c0:       48 8b 72 08             mov    0x8(%rdx),%rsi
                  74f2c4:       48 8b 3a                mov    (%rdx),%rdi
                  74f2c7:       e8 e4 38 00 00          callq  752bb0 <osMemStateDifferent>
                  74f2cc:       48 83 c4 38             add    $0x38,%rsp
                  74f2d0:       0f b6 c0                movzbl %al,%eax
                  74f2d3:       c3                      retq   
                  74f2d4:       66 66 66 2e 0f 1f 84    data32 data32 nopw %cs:0x0(%rax,%rax,1)
                  74f2db:       00 00 00 00 00
                
                ...
                
                0000000000752ba0 <osMemStateCheckPoint>:
                  752ba0:       31 c0                   xor    %eax,%eax
                  752ba2:       c3                      retq   
                  752ba3:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
                  752baa:       84 00 00 00 00 00 
                
                0000000000752bb0 <osMemStateDifferent>:
                  752bb0:       31 c0                   xor    %eax,%eax
                  752bb2:       c3                      retq   
                  752bb3:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
                  752bba:       84 00 00 00 00 00 
                
                0000000000752bc0 <osMemStateDumpAllObjectsSince>:
                  752bc0:       31 c0                   xor    %eax,%eax
                  752bc2:       c3                      retq   
                  752bc3:       66 66 66 66 2e 0f 1f    data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
                  752bca:       84 00 00 00 00 00


                And here is the corresponding hand-decompiled C, which was a joke to obtain.


                Code:
                typedef void* DWORD;// Guessing the arguments are void* pointers.
                
                int osTestBackdoorATI(int arg0, void* arg1, DWORD* arg2){
                    (void)arg1;
                    switch(arg0){
                    	case 1:  return osMemStateDifferent          (arg2[0], arg2[1]);
                    	case 2:  return osMemStateDumpAllObjectsSince(arg2[0]);
                    	case 0:  return osMemStateCheckPoint         (arg2[0]);
                    	default: return 0;
                    }
                }
                
                unsigned char osMemStateDifferent(DWORD* a, DWORD* b){
                	return 0;
                }
                
                unsigned char osMemStateDumpAllObjectsSince(DWORD* p){
                	return 0;
                }
                
                unsigned char osMemStateCheckPoint(DWORD* p){
                	return 0;
                }
                In all likelyhood the "osMemState*" functions have a body that is protected by an #ifdef DEBUG of some kind, and for release builds a "return 0" statement is substituted. This may explain the unused argument arg1.

                Comment


                • #48
                  Originally posted by chuckula View Post
                  ...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.
                  AMD is apparently a Gold Member in the Linux Foundation. Intel is higher by being Platinum though, but don't give the illusion that AMD contributes barely nothing at all.

                  Comment


                  • #49
                    Originally posted by mlkj
                    A compiler would never generate empty functions like that. Not unless you disabled ~every optimisations.
                    So what you're saying is it may have been compiled with Delphi?

                    Comment


                    • #50
                      Originally posted by Espionage724 View Post
                      AMD is apparently a Gold Member in the Linux Foundation. Intel is higher by being Platinum though, but don't give the illusion that AMD contributes barely nothing at all.
                      Platinum looks more like a "We just want a huge logo above everybody else"-club anyway, and upon first glance I see ARM and Canonical (and Nvidia teehee) as only Silver members, but to be completely honest I don't think that page is a rank of how much they contribute (in things other than money) or anything like that.

                      Intel and Nvidia fanboys can bash AMD as much as they want, but I'd love to see what they'd think if AMD actually didn't exist. That'd result in Intel having a monopoly on the CPU market and Nvidia having a monopoly on the GPU market: Intel and Nvidia NEED AMD to be successful, and without AMD even if there weren't any legal problems with holding a monopoly, there'd be consumer problems: i3 CPUs costing $1000, GTX x50 model number GPUs costing $1000, motherboards costing $2000, and no work being done to improve any products since there's no need.


                      Michael, you can't honestly tell me that had this been for Nvidia you wouldn't have waited for a response from them before opening your mouth. If you want AMD to send you shit, show you can be an objective and unbiased person...

                      Comment

                      Working...
                      X