Firmware is smaller, possibly less capable in terms of back doors
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.
Originally posted by Annabel
View Post
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