Page 5 of 6 FirstFirst ... 3456 LastLast
Results 41 to 50 of 59

Thread: A Backdoor In AMD's Catalyst OpenCL Library?

  1. #41
    Join Date
    May 2013
    Posts
    7

    Default

    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!

  2. #42
    Join Date
    May 2013
    Posts
    344

    Default Firmware is smaller, possibly less capable in terms of back doors

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

  3. #43
    Join Date
    Mar 2011
    Posts
    322

    Default

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

  4. #44
    Join Date
    Jan 2014
    Posts
    2

    Default Disassembly

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

  5. #45
    Join Date
    Nov 2012
    Posts
    112

    Default

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

  6. #46
    Join Date
    May 2013
    Posts
    344

    Default Doesn't look much like a keylogger or a phone home

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

  7. #47
    Join Date
    Aug 2012
    Posts
    28

    Default

    Quote Originally Posted by svanheulen View Post
    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.

  8. #48
    Join Date
    Jan 2014
    Posts
    2

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

  9. #49
    Join Date
    Sep 2013
    Posts
    95

    Default

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

  10. #50
    Join Date
    Sep 2011
    Posts
    62

    Wink

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •